Conversation

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
Replying to and
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
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
Show replies