Re: random.c regression on arm64 EFI systems
On Sun, Apr 22, 2018 at 01:32:15PM +0200, Ard Biesheuvel wrote: > Hello all, > > Today's pull of random.c changes caused a regression on arm64 UEFI > systems that invoke EFI_RNG_PROTOCOL to obtain strong entropy from the > platform. (arm64 does not have an architected instruction a la RDRAND) So this isn't exactly a regression. Triggering these warning messages after "fast init done" and before "crng_init_done" is working as intended as far the changes are concerned: > random: fast init done > ... > random: get_random_bytes called from start_kernel+0xb4/0x48c with > crng_init=0 > random: systemd: uninitialized urandom read (16 bytes read) > ... > random: crng init done > The current EFI code uses add_device_randomness() to pass the firmware > provided strong random seed to the kernel, for lack of a more > appropriate interface (at the time, at least). The original philosophical design is that we don't trust *any* hardware-generated randomness. This includes RDRAND. The reason for this is that we didn't want to make any assertions that some hardware was definitely secure. If you're in the US, you might not trust hardware built in China --- maybe the MSS has inserted a backdoor into the SOC built in a manufacturing line in China. If you're in China, you might not trust RDRAND or a hardware RNG since you never know if the NSA has gotten to Intel or IBM or has had the Tailored Access Operations team intercept hardware being shipped from point A to point B to subvert the hardware in some way. This used to apply even to the hardware RNG's as well, for similar reasons. Users had to explicitly set rng_core's default_quality to a non-zero value, or explicitly set the actual hardware random number generator's quality field to a non-zero value. There has been _one_ example to this rule which is for virtio_rng. The assumption is that if the Host is not trustworthy, you're screwed anyway, and VM's badly need real entropy. > I tried to switch to add_hwgenerator_randomness(), which seems more > appropriate, but it appears to me that it is impossible to get the > kernel entropy pool into the fully initialized state (crng_init=2) > using that without some dodgy tricks. It's possible, but you have to set the quality to some non-zero value. See how it is done with drivers/char/hw_random/virtio-rng.c. The real question is the philosophical question. Are we really sure we want to assert that we *really* trust the UEFI RNG implementation, for all UEFI implemntations? I suppose you could make the claim that at least with Intel implemntations, and completely incompetent Intel Management Engine implementations, if you don't trust Intel (either in the competence of their firmware engineers or their ethics about adding NSA backdoors), you're toast anyway. :-) I was hoping though that ARM64 would be making a stronger statements the easy/likelihood of backdoors in the mangemnt engine, at least as far as the actual ARM64 *CPU*, and that the real risk would be come from a particular motherboard's UEFI implementation. So we could relax our standards, and make claims that we trust UEFI_RNG_PROTOCOL. Alternatively, maybe we should be pushing get the kernel and systemd to avoid trying to use random numbers, or at least strong random numbers super-early in the boot process. If systemd is just using getrandom() for something silly, like UUID's, perhaps we change it to use a userspace psuedo-random number, or maybe we add a flag to getrandom(2), GRND_BEST_EFFORTS or GRND_PSUEDORANDOM, which doesn't trigger the warning. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Kernel lockdown for secure boot
On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote: > Theodore Y. Ts'o wrote: > > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why > > isn't this a problem for people who are fearful that Linux could be > > used as part of a Windows boot virus in a Secure UEFI context? > > Lockdown mode restricts kexec to booting an authorised image (where the > authorisation may be by signature or by IMA). If that's true, then Matthew's assertion that lockdown w/o secure boot is insecure goes away, no? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Kernel lockdown for secure boot
On Wed, Apr 04, 2018 at 03:02:33PM +0200, Greg Kroah-Hartman wrote: > On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote: > > On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote: > > > What I'm afraid of is this turning into a "security" feature that ends up > > > being circumvented in most scenarios where it's currently deployed - eg, > > > module signatures are mostly worthless in the non-lockdown case because > > > you > > > can just grab the sig_enforce symbol address and then kexec a preamble > > > that > > > flips it back to N regardless of the kernel config. > > > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why > > isn't this a problem for people who are fearful that Linux could be > > used as part of a Windows boot virus in a Secure UEFI context? > > Because no one is afraid of that :) Well, this is the excuse used by Windows. Some more cynical people believe it's really an anti-competitvie thing, but we should acknowledge this is what is causing the fear that some distros have that their UEFI secure boot certs will be revoked by Microsoft if they don't have this crazy lockdown enforcement for UEFI Secure Boot. So how about this as a compromise. We can have a config option for the behavior that those distros (and Matthew) want, and we can have separate config options that turn things on in what others would say is a more rational way. And I would all be for having the Kconfig description says, "This config option is only needed by distros who are fearful of Microsoft revoking their UEFI secure boot certificate." - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Kernel lockdown for secure boot
On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote: > What I'm afraid of is this turning into a "security" feature that ends up > being circumvented in most scenarios where it's currently deployed - eg, > module signatures are mostly worthless in the non-lockdown case because you > can just grab the sig_enforce symbol address and then kexec a preamble that > flips it back to N regardless of the kernel config. Whoa. Why doesn't lockdown prevent kexec? Put another away, why isn't this a problem for people who are fearful that Linux could be used as part of a Windows boot virus in a Secure UEFI context? If lockdown simply included a requirement for a signed kernel for kexec --- and if kernel signing aren't available, to simply not alow kexec, wouldn't that take care of this case? This wouldn't even be all that much of a burden for non-distro users with lockdown enabled, since in my experience outside of enterprise and data center use cases, kexec isn't used --- and in fact, very often kexec doesn't even work outside of a very carefully selected and bug-fixed set of device drivers. (It often doesn't work in non-distro kernels because very few upstream developers really care about kexec.) - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
