Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uniting the Linux random-number devices

lwn.net

Post reply on HN
Print view View original

1–10 of 63 posts

Re: Uniting the Linux random-number devices

#4

Post by tinalumfoil »

The decision doesn't really make sense to me, and maybe I'm misunderstanding. So please correct me if I'm wrong. If the kernel aims to have 2 ways to get randomness: blocked until initialized (default) and best effort (ie GRND_INSECURE), and there's two device files why not map one to one and one to the other?

It's easy to say why not: backwards compatibility and compatibility on systems without a good entropy source.

Backwards compatibility because now any application that depended on non-blocking randomness in early boot is SOL, and just because it's hard to find an example doesn't mean no system will be affected by this.

Systems without entropy because, because you have no guarantee from the hardware that (1) this jitter technique will work or (2) it will be secure. Putting (2) aside as "theoretical concerns", does this mean if I run Linux on a fully deterministic emulator the ext4 bug will lock up my system? That seems bad, why does my OS need to have entropy in the first place?

Re: Uniting the Linux random-number devices

#5

Post by leeter »

Dork1234 wrote: post #3

Can Linux use Hardware RNG devices? Are these devices able to generate enough bits of randomness to work for boot?

Appears so?

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

not sure that's used for /dev/random/ but I thought it was, but the question is when because early in the boot process that may not be loaded. There was also a general distrust of vendor specific hardware randoms in the past IIRC.

Re: Uniting the Linux random-number devices

#7

Post by Someone »

Dork1234 wrote: post #3

Can Linux use Hardware RNG devices? Are these devices able to generate enough bits of randomness to work for boot?

FTA: That entropy comes from sources like interrupt timing for various kinds of devices (e.g. disk, keyboard, network) and hardware RNGs if they are available.

So yes, Linux can use hardware RNGs. Your second question probably is better stated as whether those can generate random bits at a sufficient rate. I would expect hardware RNGs of being capable of that for typical use cases.

Re: Uniting the Linux random-number devices

#9

Post by majewsky »

tinalumfoil wrote: post #4

The decision doesn't really make sense to me, and maybe I'm misunderstanding. So please correct me if I'm wrong. If the kernel aims to have 2 ways to get randomness: blocked until initialized (default) and best effort (ie GRND_INSECURE), and there's two device files why not map one to one and one to the other? It's easy to say why not: backwards compatibility and compatibility on systems without a good entropy source…

> If the kernel aims to have 2 ways to get randomness [...] and there's two device files why not map one to one and one to the other?

Because both these files come with preconceived notions from various stages in the life of Unix regarding what guarantees they provide, and "best effort" works for neither of those.

If this change had come in, say, 2005, they maybe could have gotten away with /dev/random = blocked until initialized and /dev/urandom = best effort, since that was the common wisdom at the time. But for the last 10 years, more and more people have switched to using /dev/urandom for everything since it is actually good enough for everything once initialized (and most application devs only care about the "once initialized" phase since they don't work on early-boot stuff). Switching /dev/urandom to GRND_INSECURE now would therefore be a potentially bad idea.

Post reply on HN