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.
1
1
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
They use pstore to store kernel panics but for some reason no one has ever realized that they could be regularly storing CSPRNG output and then using that as an additional source of entropy on boot rather than leaving this up to init. Init should be dealing with this too though.
1
It doesn't credit EFI or hardware CSPRNGs for generating entropy so a system with a cycle counter ends up handling this via jitter entropy when there's finally a blocking call to getrandom and an embedded system without one won't have an initialized CSPRNG state for a long time.
Unless they use a hardware CSPRNG themselves during the init process and credit it for the entropy. The kernel won't automatically bring up hardware CSPRNGs and it leaves the decision of whether to credit them for any entropy to userspace when userspace brings them up.
Yes. I think AT_RANDOM is fine for hardening only but useless in my context (need to support arbitrary old/bad kernels) for arc4random, getentropy fallback, etc.
1
I'm actually thinking about trying to implement a fallback in userspace with a chaotic feedback loop of timing memory accesses at addresses controlled by output of previous iterations (something like jitter).
1
Show replies