For those potential “Motorola 68k powered IoT lightbulb that must boot to Dwarf Fortress in 69ms or a kitten dies” style situations FreeBSD just offers a tunable kern.random.initial_seeding.bypass_before_seeding that makes those super-early random calls return all zeroes (and emit a console warning) instead of blocking. Normal users who don’t try to do any of this just get the good behavior.
systemd is not “early boot”. On OpenBSD the Bootloader is reading /etc/random.seed and if available RDRAND/RDSEED values which it passes to the kernel. It has reasonable “good” random entropy even before the random subsystem initializes and mixes in more entropy.
But you can only do this if you make the bootloader, the kernel, and userland work together.
Systemd has its own bootloader and sticks the seed in EFI area, so it can pass it to the kernel before anything’s running. This is exactly the bootloader, kernel, and userland working together as you described.
It’s also important to not enable this until the second boot if you don’t have sufficient early entropy, or to seed it during device partitioning. I recall a vulnerability from a certain router manufacturer that didn’t have a real-time clock or a hardware RNG, so their only entropy source was the cycle time at which devices appeared on the bus and the MAC address. With an SoC, there was something on the order of 8 bits of entropy here, so each device generated private keys from a set of a couple of hundred. If you were able to get the MAC address (e.g. by being within WiFi range) then you could guess the private key in well under a second of CPU time.
For those potential “Motorola 68k powered IoT lightbulb that must boot to Dwarf Fortress in 69ms or a kitten dies” style situations FreeBSD just offers a tunable
kern.random.initial_seeding.bypass_before_seedingthat makes those super-early random calls return all zeroes (and emit a console warning) instead of blocking. Normal users who don’t try to do any of this just get the good behavior.That seems nice and clean.
OpenBSD writes a new random seed to disk for that initialization. Solves the same problem I think.
Many Linux distros also preserve some seed across reboots. See https://systemd.io/RANDOM_SEEDS/ and the “bootctl random-seed” part for example
systemd is not “early boot”. On OpenBSD the Bootloader is reading /etc/random.seed and if available RDRAND/RDSEED values which it passes to the kernel. It has reasonable “good” random entropy even before the random subsystem initializes and mixes in more entropy.
But you can only do this if you make the bootloader, the kernel, and userland work together.
Systemd has its own bootloader and sticks the seed in EFI area, so it can pass it to the kernel before anything’s running. This is exactly the bootloader, kernel, and userland working together as you described.
Very good, couldn’t tell from the text…
Yeah, that’s a thing too in the default FreeBSD installation, but that assumes persistent writable storage which might not be the case in embedded.
It’s also important to not enable this until the second boot if you don’t have sufficient early entropy, or to seed it during device partitioning. I recall a vulnerability from a certain router manufacturer that didn’t have a real-time clock or a hardware RNG, so their only entropy source was the cycle time at which devices appeared on the bus and the MAC address. With an SoC, there was something on the order of 8 bits of entropy here, so each device generated private keys from a set of a couple of hundred. If you were able to get the MAC address (e.g. by being within WiFi range) then you could guess the private key in well under a second of CPU time.