Lazyweb, what is the current state of entropy properties for Linux AT_RANDOM? Is it junk at early boot?
Conversation
Replying to
Same as /dev/urandom. AT_RANDOM cannot prevent an executable from being loaded in early boot ...
1
1
Replying to
So would you agree it should be classified as "suitable entropy for hardening mitigations - canary, address randomization, pointer obfuscation, etc. - but not for cryptographic entropy source?
2
1
Replying to
I'm not a cryptographer, but here's one advice, it *must not* be used except for some hardening, first, because it's only 128bits, second, because it can be read at any time by the process, it's not a secret (I'm slowly working on a patch that implements backtracking in glibc)
2
2
Replying to
Re: your second reason, *if* it were sufficient for csprng seed, I would consume it at process init time and rewrite it with the initial output of the csprng, so that wouldn't apply.
2
If you control the whole system, which unfortunately you can't guarantee, the best approach is to read a byte from getrandom in init after setting up hw_random, etc. The Linux kernel now supports using jitter entropy to force CSPRNG seeding in response to a blocking getrandom.
So, most systems will force seeding via jitter entropy if they aren't initialized at that point. Systems without a cycle counter need proper hardware support for generating entropy. The kernel handles this badly. It should be forcing initialization in early init of the KERNEL.
1
1
It should be taking advantage of hardware CSPRNGs automatically, saving / restoring entropy via pstore and using entropy passed from the previous boot stage. Unfortunately, if you aren't using the EFI boot stub, the kernel skips using the EFI random protocol as an early seed.
1
Show replies