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

[Chris Murphy]

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