Re: How to boot Windows when Bitlocker enabled with key sealed in TPM

[Chris Murphy <lists@colorremedies.com>]

On Thu, Feb 10, 2022 at 10:18 AM Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> 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 10000 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