On Tue, 2018-04-17 at 11:16 -0400, Theodore Y. Ts'o wrote: > On Tue, Apr 17, 2018 at 12:57:12PM +0100, James Bottomley wrote: > > > > You don't have to compromise the bootloader to influence this, you > > merely have to trick it into providing the random number you > > wanted. The bigger you make the attack surface (the more inputs) > > the more likelihood of finding a trick that works. > > There is a large class of devices where the bootloader can be > considered trusted. For example, all modern Chrome and Android > devices have signed bootloaders by default. And if you are using an > Amazon or Chrome VM, you are generally started it with a known, > trusted boot image. Depends how the parameter is passed. If it can be influenced from the command line then a large class of "trusted boot" systems actually don't verify the command line, so you can boot a trusted system and still inject bogus command line parameters. This is definitely true of PC class secure boot. Not saying it will always be so, just illustrating why you don't necessarily want to expand the attack surface. > The reason why it's useful to have the bootloader get the entropy is > because it may device-specific access and be able to leverage > whatever infrastructure was used to load the kernel and/or > intialramfs to also load the equivalent of /var/lib/systemd/random- > seed (or /var/lib/urandom, et. al) --- and do this early enough that > we can have truely secure randomness for those kernel faciliteis that > need access to real randomness to initialize the stack canary, or > initializing the slab cache. OK, in the UEFI ideal world where every component is a perfectly written OS, perhaps you're right. In the more real world, do you trust the people who wrote the bootloader to understand and correctly implement the cryptographically secure process of obtaining a random input? > There are other ways that this could be done, of course. If the UEFI > boot services are still available, you might be able to ask the UEFI > services to give you randomness. And yes, the hardware might be > backdoored to the fare-the-well by the MSS (for devices manufactured > in China) or by an NSA Tailored Access Operations intercepting a > computer shipment in transit. But my vision was that this wouldn't > necessarily bump the entropy accounting or mark the CRNG as fully > intialized. (If you work for the NSA and you're sure you won't do an > own-goal, you could enable a kernel boot option which marks the CRNG > initialized from entropy coming from UEFI or RDRAND or a TPM. But I > don't think it should be the default.) > > The only goal was to get enough uncertainty so we can secure early > kernel users of entropy for security features such as kernel ASLR, > the kernel stack canary, SLAB freelist randomization, etc. > > And by the way --- if you think it is easy / possible to get secure > random numbers easily from either a TPMv1 or TPMv2 w/o any early boot > services (e.g., no interrupts, no DMA, no page tables, no memory > allocation) that would be really good to know. Well, as I said, I was planning to use the EFI driver (actually for IMA, but it works here too) which should be present to the kernel on boot. We also don't have quite the severe restrictions you say. The bootmem interface is usable for allocations (even ones that persist beyond init discard) and, although most TPMs are actually polled devices, it is possible to use interrupt drivers that do DMA via UEFI in early boot provided you know what you're doing. James