On So, 15.09.19 09:27, Ahmed S. Darwish (darwish.07@xxxxxxxxx) wrote: > On Sun, Sep 15, 2019 at 08:51:42AM +0200, Lennart Poettering wrote: > > On Sa, 14.09.19 09:30, Linus Torvalds (torvalds@xxxxxxxxxxxxxxxxxxxx) wrote: > [...] > > > > And please don't break /dev/urandom again. The above code is the ony > > way I see how we can make /dev/urandom-derived swap encryption safe, > > and the only way I can see how we can sanely write a valid random seed > > to disk after boot. > > > > Any hope in making systemd-random-seed(8) credit that "random seed > from previous boot" file, through RNDADDENTROPY, *by default*? No. For two reasons: a) It's way too late. We shouldn't credit entropy from the disk seed if we cannot update the disk seed with a new one at the same time, otherwise we might end up crediting the same seed twice on subsequent reboots (think: user hard powers off a system after we credited but before we updated), in which case there would not be a point in doing that at all. Hence, we have to wait until /var is writable, but that's relatively late during boot. Long afer the initrd ran, long after iscsi and what not ran. Long after the network stack is up and so on. In a time where people load root images from the initrd via HTTPS thats's generally too late to be useful. b) Golden images are a problem. There are probably more systems running off golden images in the wild, than those not running off them. This means: a random seed on disk is only safe to credit if it gets purged when the image is distributed to the systems it's supposed to be used on, because otherwise these systems will all come up with the very same seed, which makes it useless. So, by requesting people to explicitly acknowledge that they are aware of this problem (and either don't use golden images, or safely wipe the seed off the image before shipping it), by setting the env var, we protect ourselves from this. Last time I looked at it most popular distro's live images didn't wipe the random seed properly before distributing it to users... This is all documented btw: https://systemd.io/RANDOM_SEEDS#systemds-support-for-filling-the-kernel-entropy-pool See point #2. > I know that by v243, just released 12 days ago, this can be optionally > done through SYSTEMD_RANDOM_SEED_CREDIT=1. I wonder though if it can > ever be done by default, just like what the BSDs does... This would > solve a big part of the current problem. I think the best approach would be to do this in the boot loader. In fact systemd does this in its own boot loader (sd-boot): it reads a seed off the ESP, updates it (via a SHA256 hashed from the old one) and passes that to the OS. PID 1 very early on then credits this to the kernel's pool (ideally the kernel would just do this on its own btw). The trick we employ to make this generally safe is that we persistently store a "system token" as EFI var too, and include it in the SHA sum. The "system token" is a per-system random blob. It is created the first time it's needed and a good random source exists, and then stays on the system, for all future live images to use. This makes sure that even if sloppily put together live images are used (which do not reset any random seed) every system will use a different series of RNG seeds. This then solves both problems: the golden image problem, and the early-on problem. But of course only on ESP. Other systems should be able to provide similar mechanisms though, it's not rocket science. This is also documented here: https://systemd.io/RANDOM_SEEDS#systemds-support-for-filling-the-kernel-entropy-pool See point #3... Ideally other boot loaders (grub, …) would support the same scheme, but I am not sure the problem set is known to them. Lennart -- Lennart Poettering, Berlin
