On Sun, May 03, 2020 at 12:05:22AM -0400, Thor Lancelot Simon wrote: > On Sat, May 02, 2020 at 06:07:54PM +0200, Kurt Roeckx wrote: > > > > It's my understanding that it never blocks because the bootloader > > provides entropy. Be time time the first user can call genentropy, > > it has already been seeded. > > Horsepuckey. You can't know the bootloader always has entropy to > provide.
So I found this presentation: https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00019.html They seem to use RDRAND when it's available in the bootloader, or something else when it's not. It's still my understanding that the bootloader is responisble for providing the entropy. You can argue that it might not contain as much entropy as you would like in all cases. This is at least what is in their manpages: >From https://man.openbsd.org/getentropy getentropy() fills a buffer with high-quality entropy [...] The high-quality entropy data is provided by the random(4) subsystem. >From https://man.openbsd.org/random.4: The urandom device produces high quality pseudo-random output data without ever blocking. Entropy data stored previously is provided to the kernel during the boot sequence and used as inner-state of a stream cipher. High quality data is available immediately upon kernel startup. System activity (such as disk, network, and clock device interrupts), and hardware random generator output is collected [...] For portability reasons, never use /dev/random. On OpenBSD, it is an alias for /dev/urandom, but on many other systems misbehaves by blocking because their random number generators lack a robust boot-time initialization sequence. Various of their drivers have support for RNGs that are available on hardware, which seems to include: amdpm, glxsb, pchb, hifn, safe, ccp, tpm, amlrng, bcmirng, bcmrng, mvrng, octrng, omrng, rkrng, urng, uonerng. It's unclear to me if any of them are used in the bootloader. Kurt
