Mmap /dev/random

devicesmmap

Why is it that I cannot mmap /dev/random or /dev/urandom on Linux?

I get errno 19 which is ENODEV.

When I try the same code with /dev/zero it works.

    int fd = open(path, O_RDONLY);
    assert (fd > 0);

    void* random = mmap(NULL, size, PROT_READ, MAP_PRIVATE | MAP_FILE, fd, 0);
    int err = errno;

    assert (random != MAP_FAILED);

Best Answer

You cannot mmap() /dev/random or /dev/urandom. Nor can you seek() them for that matter. And as a general rule, you cannot mmap() unseekable things. Pipes are another example of things you cannot mmap() because they are not seekable.

/dev/random and /dev/urandom are fundamentally stream-based, sequential access, devices. They produce bytes on demand when you read them. Random access to these devices has no meaning. mmap() implies random access.

TL;DR

Use /dev/urandom for most practical purposes.

The longer answer depends on the flavour of Unix that you're running.

Linux

Historically, /dev/random and /dev/urandom were introduced at the same time.

As @DavidSchwartz pointed out in a comment, using /dev/urandom is preferred in the vast majority of cases. He and others also provided a link to the excellent Myths about /dev/urandom article which I recommend for further reading.

In summary:

The manpage is misleading.
Both are fed by the same CSPRNG to generate randomness (diagrams 2 and 3)
/dev/random blocks when it runs out of entropy, so reading from /dev/random can halt process execution.
The amount of entropy is conservatively estimated, but not counted
/dev/urandom will never block.
In rare cases very shortly after boot, the CSPRNG may not have had enough entropy to be properly seeded and /dev/urandom may not produce high-quality randomness.
Entropy running low is not a problem if the CSPRNG was initially seeded properly.
The CSPRNG is being constantly re-seeded.
In Linux 4.8 and onward, /dev/urandom does not deplete the entropy pool (used by /dev/random) but uses the CSPRNG output from upstream.
Use /dev/urandom.

Exceptions to the rule

In the Cryptography Stack Exchange's When to use /dev/random over /dev/urandom in Linux @otus gives two use cases:

Shortly after boot on a low entropy device, if enough entropy has not yet been generated to properly seed /dev/urandom.
Generating a one-time pad with information theoretic security

If you're worried about (1), you can check the entropy available in /dev/random.

If you're doing (2) you'll know it already :)

Note: You can check if reading from /dev/random will block, but beware of possible race conditions.

Alternative: use neither!

@otus also pointed out that the getrandom() system will read from /dev/urandom and only block if the initial seed entropy is unavailable.

There are issues with changing /dev/urandom to use getrandom(), but it is conceivable that a new /dev/xrandom device is created based upon getrandom().

macOS

It doesn't matter, as Wikipedia says:

macOS uses 160-bit Yarrow based on SHA1. There is no difference between /dev/random and /dev/urandom; both behave identically. Apple's iOS also uses Yarrow.

FreeBSD

It doesn't matter, as Wikipedia says:

/dev/urandom is just a link to /dev/random and only blocks until properly seeded.

This means that after boot, FreeBSD is smart enough to wait until enough seed entropy has been gathered before delivering a never-ending stream of random goodness.

NetBSD

Use /dev/urandom, assuming your system has read at least once from /dev/random to ensure proper initial seeding.

The rnd(4) manpage says:

/dev/urandom never blocks.

/dev/random sometimes blocks. Will block early at boot if the system's state is known to be predictable.

Applications should read from /dev/urandom when they need randomly generated data, e.g. cryptographic keys or seeds for simulations.

Systems should be engineered to judiciously read at least once from /dev/random at boot before running any services that talk to the internet or otherwise require cryptography, in order to avoid generating keys predictably.

Understanding mmap in Memory Management

Answering things in order:

It returns a pointer to the location in virtual memory, and Virtual memory address space is allocated, but the file is not locked in any way unless you explicitly lock it (also note that locking the memory is not the same as locking the region in the file). An efficient implementation of mmap() is actually only possible from a practical perspective because of paging and virtual memory (otherwise, it would require reading the whole region into memory before the call completes).
Not exactly, this ties into the next answer though, so I'll cover it there.
Kind of. What's actually happening in most cases is that mmap() is providing copy-on-write access to that file's data in the page cache. As a result, the usual cache restrictions on data lifetime apply (if the system needs space, pages can be dropped (or flushed to disk if they're dirty) from the cache and need to be faulted in again.
No, because of how virtual memory works. Each process has it's own virtual address space, with it's own virtual mappings. Every program that wants to communicate data will have to call mmap() on the same file (or shared memory segment), and they all have to use the MAP_SHARED flag.

It's worth noting that mmap() doesn't just work on files, you can also do other things with it such as:

Directly mapping device memory (if you have sufficient privileges). This is actually used on many embedded systems to avoid the need to write kernel mode drivers for new hardware.
Map shared memory segments.
Explicitly map huge pages.
Allocate memory that you can then call madvise(2) on (which in turn lets you do useful things like prevent data from being copied to a child process on fork(2), or mark data for KSM (Linux's memory deduplication feature)).