On Mon, 2 Nov 2020 at 20:39, Matthew Garrett <mjg59@xxxxxxxxxx> wrote: > > 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. Does Shim use PCR 7 for the MOK key database? Are there any specific requirements from MS on which PCRs Shim must touch?
