On Mon, Nov 2, 2020 at 9:06 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > This is posted as an RFC since it is mostly an invitation to discuss how > we can fit this into a longer term strategy for arch-agnostic secure and > measured boot that does not hinge on the Shim+GRUB tandem, or on deep > knowledge on the part of the bootloader regarding device trees, bootparams > structs, allocation and placement policies of various artifacts etc etc My initial concern was that we'd potentially do double measurement if a separate bootloader loaded the initrd and then called the EFI entry point, but it looks like you'll only measure if the stub loaded the initrd itself, in which case this seems fine. > Open questions: > - Should we do this? I think so. The initramfs is clearly part of our initial TCB. > - Are Linux systems in the field using PCR value prediction when updating the > initrd? Does this approach interfere with that? I'm not aware of any distro that's tried to solve this problem. I do have an idea for how to (basically, build a generic initramfs and then allow the bootloader to override specific configuration files - grub has support for reading files and creating an additional cpio on the fly), but handwave. > - Which PCR and event type to use Grub is measuring the initramfs (and all binaries) into PCR 9 with EV_IPL. > - Is a separator event needed here, given that the initrd measurement is > recorded even if no initrd was loaded by the stub? I think probably, but we should probably have a longer discussion around when we should be logging separators (grub doesn't generate any at the moment, and I don't think shim does either, and that's definitely suboptimal for the PCR 7 case). We should probably look at what Windows is doing here.
