[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: getrandom and getentropy
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
So I found this presentation:
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:
getentropy() fills a buffer with high-quality entropy
The high-quality entropy data is provided by the random(4) subsystem.
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.
Main Index |
Thread Index |