On Fri, Mar 25, 2022 at 5:00 PM Chris Murphy <li...@colorremedies.com> wrote: > > On Fri, Mar 25, 2022 at 2:32 PM Vladimir 'phcoder' Serbinenko > <phco...@gmail.com> wrote: > > > > On Fri, Mar 25, 2022 at 9:14 PM Chris Murphy <li...@colorremedies.com> > > wrote: > > > > > > For all practical purposes, this is functionally the end to dual boot > > > in GRUB, if there is no work around, e.g. bootnext. Is that the > > > direction GRUB maintainers want to go in? > > Why don't you just update TPM with new values? Then it will get > > unsealed when booted through GRUB > > How? > > The key is sealed in the TPM so first we need to get the key in order > to (re)seal it with new PCR values. Correct? So we somehow need a way > to boot only the Windows bootloader in order for measured boot to > unseal the key, and then we'd need to somehow measure > shim+grub+windows bootloaders together in order to seal the key with > the new values for those three bootloaders used in that sequence. I > have no idea if that's practical at all. > > The recovery key is not the one sealed in the TPM, they are separate > keys in separate "keyslots".
The next problem is that when there's a Linux system update the updates either shim or grub, the shim+grub+windows bootloader measurements have changed and will again fail to unseal the key. It's indistinguishable from the system having been compromised. And now you get to do a clean install of Windows and Linux to get back to functional. Further, should the user need to reinstall Linux, or even boot Windows directly from the firmware's boot manager - they wouldn't be able to. This all sounds quite a lot more difficult than GRUB having the ability to set a bootnext efi variable, and just reboot - let the Windows bootloader handle all of this, and not involve Linux bootloaders. -- Chris Murphy _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel