LWN: Comments on "Problems emerge for a unified /dev/*random"

Problems emerge for a unified /dev/*random

flussence — Mon, 11 Apr 2022 14:53:56 +0000

Surprised to find out you're right. I assumed those device nodes would be only writable by root for this exact reason.

Problems emerge for a unified /dev/*random

cypherpunks2 — Thu, 07 Apr 2022 23:55:20 +0000

> A more insidious problem, perhaps, is that a seed written to the RNG before it initializes will not actually be used until after the pool is initialized properly; "you might write in a perfectly good seed to /dev/urandom, but what you read out for the subsequent seed may be complete deterministic crap"

This has been noticed on StackExchange it seems https://security.stackexchange.com/questions/183506/rando...

Problems emerge for a unified /dev/*random

wtarreau — Fri, 01 Apr 2022 12:07:02 +0000

Yes U-Boot definitely is the best place here, since it often embeds the SPL code that's used to train the DDR memory. Typically the training is a good way to produce entropy since it tries timings for reliable transfers.

For the PC world, grub might be too late due to the BIOS often doing most of the cleanup. However on PCs there's often a video card whose memory is not reset and which contains garbage. I think it already happened to all of us to power-cycle a PC, then discover a fantom image of previous session for a fraction of a second when typing "startx" because that memory wasn't completely lost yet. And most PCs have hardware RNGs and jitter entropy anyway ;-)

Problems emerge for a unified /dev/*random

nickleverton — Fri, 01 Apr 2022 10:06:23 +0000

U-Boot, which I would guess is probably used by most embedded devices that boot into Linux, is GPL2.0+. It's ideally placed to extract the early boot hardware-based randomness that Willy Tarreau mentions, running after any SoC ROM loader but before the Linux kernel. I am sure Grub could do similar things for bigger SoCs that boot from disk.

Problems emerge for a unified /dev/*random

wsy — Fri, 01 Apr 2022 09:07:52 +0000

I would never trust a boot loader unless it's open source. And I don't think SOC vendors will do that.

Problems emerge for a unified /dev/*random

wtarreau — Fri, 01 Apr 2022 04:14:28 +0000

I remember having discussed this problem with Jason a few years ago, saying that until we instrument boot loaders to feed entropy on embedded devices, it's a dead end. Indeed, the only source of entropy you can have on small devices are:
- pre-init device contents (uninitialized RAM usually contains noise, except in VMs);
output GPIOs may also read noise before they're configured as outputs. UARTs
often read a first crappy byte. Many chips also include a "reset cause" register
that indicates power-on, reset, exception, etc

- device reset timings (slow devices such as UARTs do not always take an integral
number of cycles to reset; RTC's second transition also solely depends on when
the device was booted, relative to the current second.

- the device's configuration: very often you'll find a MAC or some device-specific
WiFi calibration data stored in a special area on the flash, that may differ from
device to device. When running in a VM, some arguments may come from other
means.

- other external persistent info (e.g. any RTC time value that varies between boots)

But often all these data are lost after the boot loader finishes initialization and transfers execution to the kernel. We'll *need* to standardize a solution for this, that boot loaders will have to use for future kernels if we want to improve the situation for such embedded devices. Otherwise they're too deterministic. I do remember that the SSH key I used to have on my old NSLU2 existed on at least 89 other devices connected to the net... This definitely shows that without early entropy there's little hope to collect more later and whatever we'll try to do can result in frustration. And while VMs are terrible for this, at least they can benefit from entropy being spoon-fed at boot by the hypervisor.

Problems emerge for a unified /dev/*random

zx2c4 — Fri, 01 Apr 2022 00:50:33 +0000

From this commit message:

Additionally, the plugin can pre-initialize arrays with build-time random contents, so that two different kernel builds running on identical hardware will not have the same starting values.

Problems emerge for a unified /dev/*random

gerdesj — Thu, 31 Mar 2022 23:05:12 +0000

I love the idea of random == urandom but the snags all seem to be about the boot process. Does this not indicate that there still a need for (at least) two randoms. Another one could be random_boot or brandom or whatever.

A booting system is obviously not in the same state as it will be when it's fully initialised and running, so why insist on pseudo devices like random being a "one size fits all"?

VPNs and webservers for example are huge consumers of randomness and can happily wait until the system is up and running and firing on all four. They could really benefit from a relatively simple random that "knows" that suitable sources of entropy are available and cryptographic researchers aren't going to get sarcastic! They tend to be bloody complicated and any simplification would be a good thing: eg an assumption about the quality of random.

The things that need early random can use brandom and accept its limitations and work with them and then switch to random when it's available if they need to.

Another option might be to have one random device that describes how useful it thinks it is and leave the consumer to take action based on that. "Hi I'm Mike and here's a stream of gibberish-ish(3)". The road to Hell is paved with odd interfaces ...

Problems emerge for a unified /dev/*random

jhhaller — Thu, 31 Mar 2022 20:14:49 +0000

My random issue was a number of years back, when I would build new systems frequently. The login would take forever to accept a connection. Eventually, I discovered that it was openssh building the host key and it required random numbers, and there was no source of entropy other than network packets, and not many of them. It may have gotten changed, I rarely build new machines anymore.

Problems emerge for a unified /dev/*random

mathstuf — Thu, 31 Mar 2022 15:48:57 +0000

That sounds dangerous as long as the `nobody` user can perform `</dev/zero >/dev/random`.

Problems emerge for a unified /dev/*random

pj — Thu, 31 Mar 2022 13:39:43 +0000

Maybe have writes to /dev/random credit the entropy pool but writes to /dev/urandom do not? It's approximately symmetrical to their read semantics.

Problems emerge for a unified /dev/*random

nix — Thu, 31 Mar 2022 10:51:52 +0000

... and the whole problem here is that on some platforms there *is* no varying "MAC, whatever" to mix in, and those are the same platforms which are having trouble now. So this would add complexity to... not solve the problem at all :)

Problems emerge for a unified /dev/*random

mb — Wed, 30 Mar 2022 21:46:54 +0000

Except that it would be the same on every early boot.
And it would even be the same for every distro kernel (minus the mac, whatever mixing).

Problems emerge for a unified /dev/*random

istenrot — Wed, 30 Mar 2022 21:22:31 +0000

Why don't we generate during a kernel build a sufficiently large kernel embedded binary blob to be used as good quality pre-boot stage random seed? Then mixed with hardware unique identifiers like network interface MAC addresses, SMBIOS data, hardware sensors, RTC time, etc we should have quite nice pre-boot random source. Right?

Problems emerge for a unified /dev/*random

willmo — Wed, 30 Mar 2022 19:34:43 +0000

Maybe bananas idea, and maybe this is what jhoblitt is suggesting above, but what about making a new character device like "/dev/entropypool" whose writes are always credited as entropy?

Problems emerge for a unified /dev/*random

jhoblitt — Wed, 30 Mar 2022 17:35:25 +0000

An interface consisting of writing to a procfs file and then having to call an ioctl on it makes me reach for my unix barf bag.

Is there any hope of a sane reboot under sysfs?

Problems emerge for a unified /dev/*random

Hello71 — Wed, 30 Mar 2022 13:41:46 +0000

Ah, you're right.

Problems emerge for a unified /dev/*random

ncm — Wed, 30 Mar 2022 12:39:11 +0000

Nowadays most devices come with a hardware random number generating device attached, typically a camera, radio, or microphone. The low bits of analog-to-digital converters provide a copious supply of entropy that the upper bits, howsoever predictable, cannot steal away.

Such devices might be more trustworthy than the "hardware RNG" instructions provided on processor cores, which we have seen demonstrated (in a recent AMD erratum) may be reliably turned off from microcode, and, we may presume, from an appropriate not-publicly-documented instruction sequence. Whether to try to defend against such an attack depends on your threat model, of course; if so, an unreliable source of random numbers might be the least of your problems. But defense in depth has rarely been a mistake.

Problems emerge for a unified /dev/*random

jake — Wed, 30 Mar 2022 01:54:20 +0000

> the correct method to add entropy is to use the RNDADDENTROPY ioctl.

the article doesn't ignore that, but it perhaps takes a while to get there; it talks about it starting around here:

> The RNDADDENTROPY command combines the write and the credit in the same call, which
> allows the kernel to make a better decision on what do with it, he said.

jake

Problems emerge for a unified /dev/*random

Hello71 — Tue, 29 Mar 2022 23:50:09 +0000

The article's claim that RNDADDTOENTCNT must be used to add entropy is incorrect, or at least incomplete. As explained in the mailing list thread, use of RNDADDTOENTCNT is highly discouraged, and the correct method to add entropy is to use the RNDADDENTROPY ioctl.

Problems emerge for a unified /dev/*random

jepler — Tue, 29 Mar 2022 22:02:45 +0000

Ages ago I made a random number generating device and a daemon for adding its entropy into the system. So I had to check out today how I did it back then (circa 2013): https://emergent.unpythonic.net/01257868826

It appears that I (A) asked the kernel how much entropy was available via /proc/sys/kernel/random/entropy_avail, (B) if it was at least 3072, slept (max entropy was/is 4096?) (C) otherwise, read enough data from my device, wrote it to /dev/random (not urandom!), and credited it with ioctl RNDADDTOENTCNT

So in this case, it looks like big gulps of data were added by my random daemon. Hooray for good luck in a long ago decision.

In any case, I don't use the device anymore.