Re: How to boot Windows when Bitlocker enabled with key sealed in TPM
On Fri, Mar 25, 2022 at 5:00 PM Chris Murphy wrote: > > On Fri, Mar 25, 2022 at 2:32 PM Vladimir 'phcoder' Serbinenko > wrote: > > > > On Fri, Mar 25, 2022 at 9:14 PM Chris Murphy > > 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
Re: How to boot Windows when Bitlocker enabled with key sealed in TPM
On Fri, Mar 25, 2022 at 2:32 PM Vladimir 'phcoder' Serbinenko wrote: > > On Fri, Mar 25, 2022 at 9:14 PM Chris Murphy 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". -- Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to boot Windows when Bitlocker enabled with key sealed in TPM
On Fri, Mar 25, 2022 at 9:14 PM Chris Murphy 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 > > -- > Chris Murphy > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to boot Windows when Bitlocker enabled with key sealed in TPM
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? -- Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to boot Windows when Bitlocker enabled with key sealed in TPM
On Thu, Feb 10, 2022 at 02:13:43PM -0700, Chris Murphy wrote: > If you boot windows once a day, it's changing what, 1-4 bytes, per > day? The entry for Windows is already in NVRAM, it doesn't need to be > written each time. You're only changing the BootNext value that points > to the Windows entry (and then the firmware removes it). Well the fact you are only rewriting nextboot with a few bytes is probably still a potential problem since from what I have seen, these simple SPI flash chips that seem to often be used tend not to have wear leveling. They don't expect a lot of writes. Ideally the UEFI NVRAM should be battery back ram, but that doesn't seem to be how a lot of systems actually implement it. If they expect you to install windows and run it, they don't need to support rewriting a lot. > This is not Secure Boot. It's measured boot. They're using the TPM to > measure the bootchain and make sure it hasn't been tampered with > before revealing the encryption key. If the user has written down the > recovery key, they can still boot from the BitLocker recovery window, > but that's an untenable default user experience following the > installation of a Linux distro. It's a 48 digit key. Oh right for bitlocker. Even more picky than secureboot. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to boot Windows when Bitlocker enabled with key sealed in TPM
On Thu, Feb 10, 2022 at 12:29 PM Lennart Sorensen wrote: > > On Thu, Feb 10, 2022 at 11:46:33AM -0700, Chris Murphy wrote: > > On Thu, Feb 10, 2022 at 10:18 AM Lennart Sorensen > > wrote: > > > > > > On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote: > > > > One idea I've heard floated is, having GRUB alter efivars such that > > > > BootNext is changed to do a one time boot of Windows, instead of using > > > > chainloader. If BIOS, use chainloader as now. If UEFI, set BootNext > > > > efi variable? This has the benefit of working even on UEFI systems > > > > which aren't BitLocker encrypted. > > > > > > > > Can GRUB modify efivars now? If not, what work would be needed to > > > > enable GRUB to modify efivars? Alternatives? > > > > > > I am pretty sure I have read of cases where systems used such low quality > > > flash for their UEFI variables that they broke after being written too > > > many times. I think Ubuntu had a bug that caused it to rewrite some > > > UEFI variable ever boot that initially spotted the problem or something > > > like that. Cheap flash is often 1 writes or even less in some cases. > > > > > > But rewriting the variable each time you boot sounds like a "Don't do > > > that" thing. > > > > Not every boot. Just when the user picks the Windows entry in the > > menu. Anyway, the death of NVRAM is orthogonal to the issue, which is > > that the current paradigm isn't working for newer systems. Eventually > > it'll be the common case. So is the idea to just leave it broken, or > > fix it? At a certain point it makes more sense to stop creating > > Windows boot entries if they're not going to work. > > > > Also, systemd-boot is going to support BootNext. > > https://github.com/systemd/systemd/pull/22043/commits/661615a0afacee3545cde0a48286c0fef983f8fe > > Well every time you boot windows counts as every boot. Perhaps not > every boot of the system. Still seems like way too often at least. If you boot windows once a day, it's changing what, 1-4 bytes, per day? The entry for Windows is already in NVRAM, it doesn't need to be written each time. You're only changing the BootNext value that points to the Windows entry (and then the firmware removes it). > Secureboot combined with dual (or more) booting sure does seem like a > huge mess. This is not Secure Boot. It's measured boot. They're using the TPM to measure the bootchain and make sure it hasn't been tampered with before revealing the encryption key. If the user has written down the recovery key, they can still boot from the BitLocker recovery window, but that's an untenable default user experience following the installation of a Linux distro. It's a 48 digit key. -- Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to boot Windows when Bitlocker enabled with key sealed in TPM
On Thu, Feb 10, 2022 at 11:46:33AM -0700, Chris Murphy wrote: > On Thu, Feb 10, 2022 at 10:18 AM Lennart Sorensen > wrote: > > > > On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote: > > > One idea I've heard floated is, having GRUB alter efivars such that > > > BootNext is changed to do a one time boot of Windows, instead of using > > > chainloader. If BIOS, use chainloader as now. If UEFI, set BootNext > > > efi variable? This has the benefit of working even on UEFI systems > > > which aren't BitLocker encrypted. > > > > > > Can GRUB modify efivars now? If not, what work would be needed to > > > enable GRUB to modify efivars? Alternatives? > > > > I am pretty sure I have read of cases where systems used such low quality > > flash for their UEFI variables that they broke after being written too > > many times. I think Ubuntu had a bug that caused it to rewrite some > > UEFI variable ever boot that initially spotted the problem or something > > like that. Cheap flash is often 1 writes or even less in some cases. > > > > But rewriting the variable each time you boot sounds like a "Don't do > > that" thing. > > Not every boot. Just when the user picks the Windows entry in the > menu. Anyway, the death of NVRAM is orthogonal to the issue, which is > that the current paradigm isn't working for newer systems. Eventually > it'll be the common case. So is the idea to just leave it broken, or > fix it? At a certain point it makes more sense to stop creating > Windows boot entries if they're not going to work. > > Also, systemd-boot is going to support BootNext. > https://github.com/systemd/systemd/pull/22043/commits/661615a0afacee3545cde0a48286c0fef983f8fe Well every time you boot windows counts as every boot. Perhaps not every boot of the system. Still seems like way too often at least. Secureboot combined with dual (or more) booting sure does seem like a huge mess. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to boot Windows when Bitlocker enabled with key sealed in TPM
On Thu, Feb 10, 2022 at 10:18 AM Lennart Sorensen wrote: > > On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote: > > One idea I've heard floated is, having GRUB alter efivars such that > > BootNext is changed to do a one time boot of Windows, instead of using > > chainloader. If BIOS, use chainloader as now. If UEFI, set BootNext > > efi variable? This has the benefit of working even on UEFI systems > > which aren't BitLocker encrypted. > > > > Can GRUB modify efivars now? If not, what work would be needed to > > enable GRUB to modify efivars? Alternatives? > > I am pretty sure I have read of cases where systems used such low quality > flash for their UEFI variables that they broke after being written too > many times. I think Ubuntu had a bug that caused it to rewrite some > UEFI variable ever boot that initially spotted the problem or something > like that. Cheap flash is often 1 writes or even less in some cases. > > But rewriting the variable each time you boot sounds like a "Don't do > that" thing. Not every boot. Just when the user picks the Windows entry in the menu. Anyway, the death of NVRAM is orthogonal to the issue, which is that the current paradigm isn't working for newer systems. Eventually it'll be the common case. So is the idea to just leave it broken, or fix it? At a certain point it makes more sense to stop creating Windows boot entries if they're not going to work. Also, systemd-boot is going to support BootNext. https://github.com/systemd/systemd/pull/22043/commits/661615a0afacee3545cde0a48286c0fef983f8fe -- Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to boot Windows when Bitlocker enabled with key sealed in TPM
On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote: > One idea I've heard floated is, having GRUB alter efivars such that > BootNext is changed to do a one time boot of Windows, instead of using > chainloader. If BIOS, use chainloader as now. If UEFI, set BootNext > efi variable? This has the benefit of working even on UEFI systems > which aren't BitLocker encrypted. > > Can GRUB modify efivars now? If not, what work would be needed to > enable GRUB to modify efivars? Alternatives? I am pretty sure I have read of cases where systems used such low quality flash for their UEFI variables that they broke after being written too many times. I think Ubuntu had a bug that caused it to rewrite some UEFI variable ever boot that initially spotted the problem or something like that. Cheap flash is often 1 writes or even less in some cases. But rewriting the variable each time you boot sounds like a "Don't do that" thing. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to boot Windows when Bitlocker enabled with key sealed in TPM
Found this: [PATCH v1 2/2] core: commands: efi: add commands to get/set EFI vars https://lists.gnu.org/archive/html/grub-devel/2020-05/msg00027.html But I haven't seen any discussion on whether to support get/set EFI vars. Would it be possible to constrain the support to setting just "BootNext" for this use case? Or else I guess distros need to consider removing the creation of a Windows menu entry, as there's no point creating menu entries that don't work. -- Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
