[stingraycharles]

Seems like a no-brainer to me; as I understand, this effectively make urandom “always secure”, which is a very good thing; makes for an even more convincing argument when some colleague insists on using /dev/random “because it’s more secure”.

Do I understand correctly that with this patch, the only drawback is for weird architectures that do not have an instruction counter or another instruction to gather random data? And in those cases, the old behavior (“urandom may be insecure shortly after boot”) may even be worse than the new behavior (“may block while waiting for entropy”) ?

[zx2c4]

Right, it unifies /dev/urandom, /dev/random, and getrandom(flags=0) to all do exactly the same thing.

Most modern userspaces already use getrandom(flags=0). Nothing changes for them. They already count on the rng being seeded in one way or another.

Rather, this changes /dev/urandom, which previously would give insecure randomness before being seeded. With this change, this doesn't happen any more, because it makes /dev/urandom wait until it has been seeded.

In practice, the RNG get seeded by a large variety of things. As a last ditch effort, the Linus Jitter Dance will seed it.

Taken together, what all the above amounts to is that the regression potential is limited to systems where: (A) /dev/urandom is still being used, rather than getrandom(flags=0), (B) the boot sequence, due to some bug, hard-depends on unseeded reads from /dev/urandom, (C) no ordinary sources of entropy, such as interrupts and input devices and disk drives, are available, (D) the CPU is so ancient as to be missing a cycle counter, defeating the last ditch Linus Jitter Dance, and (E) a new kernel will be installed on this old system.

I argue that the set of machines where (A), (B), (C), (D), and (E) all hold is minuscule.

[oshiar53-0]

Doesn't this mean that non-blocking reads from /dev/urandom can now potentially return -EAGAIN (at e.g. very early boot time)? I think that's enough to subtly (nondeterministically) break userspace, in the short time window the entropy pool is not seeded enough, even if (C) and (D) do not hold.

[vlovich123]

Wasn't there many cases where they tried to make /dev/urandom wait until entropy & it broke many distros on certain machines? What's different this time around?

[jcranmer]

I believe that was fixed by the last-ditch Linus Jitter Dance.

[lixtra]

Since I wanted to learn more about Linus Jitter Dance, here is the patch: https://github.com/torvalds/linux/commit/50ee7529ec45

And here is discussion of the concept: https://news.ycombinator.com/item?id=9512718