Linux Devices – Meaning of ‘u’ in /dev/urandom

deviceshistorylinuxrandom

I understand that reads to /dev/random may block, while reading /dev/urandom is guaranteed not to block.

Where does the letter u come into this? What does it signify?

Userspace? Unblocking? Micro?

Update:

Based on the initial wording of the question, there has been some debate over the usefulness of /dev/random vs /dev/urandom. The link Myths about /dev/urandom has been posted three times below, and is summarised in this answer to the question When to use /dev/random vs /dev/urandom.

Best Answer

Unlimited.

In Linux, comparing the kernel functions named random_read and random_read_unlimited indicates that the etymology of the letter u in urandom isunlimited.

This is confirmed by line 114:

The /dev/urandom device does not have this limit [...]

Update:

Regarding which came first for Linux, /dev/random or /dev/urandom, @Stéphane Chazelas gave the post with the original patch and @StephenKitt showed they were both introduced simultaneously.

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.

What does “w” do with urandom

As explained in other answers and comments the reason for what you observe is the way Bash handles pipes. In order to filter what you really want in similar situations you can try to enclose the first letter of the grep argument in [] like this:

$ strace w 2>&1 | grep random
read(4, "grep\0random\0", 2047)         = 12
$ strace w 2>&1 | grep '[r]andom'
$ strace w 2>&1 | grep '[c]lose'
close(3)                                = 0
close(3)                                = 0
close(3)                                = 0
close(3)                                = 0
close(3)                                = 0
close(3)                                = 0
(...)

EDIT:

As correctly noted by R. in the comment below in fact strace does not see the other side of the pipe. Similarly to ps aux | grep grep which also shows grep grep in its output w is is walking through /proc directory and finds grep process there.