Messages in this thread | | | Date | Mon, 14 Aug 2017 21:31:24 -0400 | From | Theodore Ts'o <> | Subject | Re: early x86 unseeded randomness |
| |
On Mon, Aug 14, 2017 at 09:00:13PM +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 11:17:37AM -0700, Linus Torvalds wrote: > > Ok, guys, you ALL need to learn that blindly just trying to get rid of > > warnings IS A HORRIBLE IDEA. > > Not blindly - I was actually suggesting/asking whether falling back to > the TSC that early during boot might make more sense than using unseeded > randomness. Especially add the least significant 32 bits to the most > significant i.e., that thing: > > tsc + (tsc << 32UL) > > as they're more unpredictable.
Part of the initialization step of the entropy pools and the crng mixes in the jiffies, ktime_get_real() and the TSC. So if you are one of those people who believe in the magic of jitter-rng, we do something somewhat similar to that a part of the initialization. We just don't credit any entropy to that step.
> > > But maybe those places that currently trigger the warning should just > > use "get_random_u32()" instead. That at least gets rid of the warning > > if there's a fast architected hardware random thing (ie modern x86). > > Right, that is better, at least for the RDRAND machines.
Also note that the CRNG will use RDRAND if it is there; it just doesn't depend on it. The main thing about get_random_u32() is that it has a policy decision embedded into it which is that we believe that RDRAND, or whatever implements arch_get_random_{seed_}{long,int} is trusted. (e.g., that we trust that Intel, Qualcomm, etc., didn't put a back door into CPU-based random number generator, which we basically have to take on faith because there is no way to audit it).
I tend to be a bit of pragmatist on these things, which is that I believe it is *unlikely* that the NSA managed to pay off or blackmail Intel into subverting RDRAND. I can't prove it, of course, but if we can get away with not trusting Intel, it's better if we can avoid investing all of our trust in Intel. On the flip side, for very early boot, unless we can do what OpenBSD does and actually embed into the boot loader reading a cryptographic seed from trusted store, it's pretty much hopeless to think we can gather entropy, and we might as well just use RDRAND, and hope for the best. Realistically speaking, the harm done from a bogus stack canary or even a subverted KASLR is very small compared with introducing a wekaness into the keygen of long-term public/private key.
And yes, spraying warning around just annoys users and if it inspires them to do dumb(tm) things, it really doesn't help. So suppressing warnings during early boot is probably a good thing, since hopefully people in early boot won't be stupid enough to generate high-value keypairs. :-)
> We'd still need a proper fix for the older ones. And I don't see an > easy way to change the init ordering for the stack canary as it gets > setup very very early in start_kernel() vs crng_initialize() being > an early_initcall()... Need to sleep on it.
The real fix is to do what OpenBSD does, which is to teach the bootloader (e.g., grub) to read from some file such as /var/lib/urandom/random-seed, and then to have the init scripts overwrite it with a new set of entropy generated from getrandom(2) as early as possible.
It won't solve the CD-ROM install problem (although there is enough entropy during the install process that after the install is done, we should be fine, and again, *hopefully* the distro people won't be stupid enough to generate high-value keys during the installation process, or certainly not early in the installation process). But it does solve most of the problem.
- Ted
| |