Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement

[Adam Williamson]

For background here, see:
https://bugzilla.redhat.com/show_bug.cgi?id=2049849

right now, when installing Fedora alongside a Windows install with
BitLocker enabled, trying to boot Windows from the Fedora boot menu
does not work.

We waived the bug as a blocker for Fedora 36 on the basis upstream did
not consider it fixable within the F36 timeframe. We agreed that if
upstream still couldn't get this fixed for F37, we'd consider revising
the criteria.

Well, we're approaching F37 Final and the bug is still open, and
there's no appreciable movement upstream, so I'm proposing the criteria
change. I propose we change this:

"The installer must be able to install into free space alongside an
existing clean Windows installation and install a bootloader which can
boot into both Windows and Fedora."

to say:

"The installer must be able to install into free space alongside an
existing clean Windows installation. As long as the Windows
installation does not have BitLocker enabled, the installer must also
install a bootloader which can boot into both Windows and Fedora."
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Robbie Harwood]

Adam Williamson <adamwill(a)fedoraproject.org&gt; writes:

>  For background here, see:
>  https://bugzilla.redhat.com/show_bug.cgi?id=2049849
>
>  right now, when installing Fedora alongside a Windows install with
>  BitLocker enabled, trying to boot Windows from the Fedora boot menu
>  does not work.
>
>  We waived the bug as a blocker for Fedora 36 on the basis upstream did
>  not consider it fixable within the F36 timeframe. We agreed that if
>  upstream still couldn't get this fixed for F37, we'd consider revising
>  the criteria.
>
>  Well, we're approaching F37 Final and the bug is still open, and
>  there's no appreciable movement upstream, so I'm proposing the criteria
>  change. I propose we change this:
>
>  "The installer must be able to install into free space alongside an
>  existing clean Windows installation and install a bootloader which can
>  boot into both Windows and Fedora."
>
>  to say:
>
>  "The installer must be able to install into free space alongside an
>  existing clean Windows installation. As long as the Windows
>  installation does not have BitLocker enabled, the installer must also
>  install a bootloader which can boot into both Windows and Fedora." 
(Fedora grub2 maintainer hat on)

I'm fine with the proposed change.  I'm also fine with the original
text.

During boot, certain actions are taken that are recorded in the TPM.
These include, for instance, any loaders that are run - like grub2.  The
result is that if you load Windows from grub2 rather than the EFI
firmware, the TPM state will be different.  Bitlocker cares about this
TPM state.

So: if you install Windows and set up Bitlocker booting through grub, it
will continue to work through grub.  If you install Windows outside grub
(or it's pre-provisioned), it will continue to work outside grub.  If
you want to move from not using grub to using grub, then Bitlocker needs
to be reestablished with the new TPM values.

It is the opinion of the grub2 maintainers that this constitutes being
able to boot both Windows and Fedora today.  However, we also understand
that not everyone agrees with this, as evidenced by the existence of the
bug and this thread about changing RC.

The only way to get the TPM state to match not using a particular loader
is to not use a loader - i.e., have grub2 (or efibootmgr in Fedora
userspace) set EFI BootNext and reboot the machine.  But generally, if
users want to be booting Windows through grub, we recommend they
configure Bitlocker against those PCR values instead.

Be well,
--Robbie

[Adam Williamson]

On Mon, 2022-09-19 at 16:45 -0400, Robbie Harwood wrote:
>  Adam Williamson <adamwill(a)fedoraproject.org&gt; writes:
>  
>  > For background here, see:
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2049849
>  > 
>  > right now, when installing Fedora alongside a Windows install with
>  > BitLocker enabled, trying to boot Windows from the Fedora boot menu
>  > does not work.
>  > 
>  > We waived the bug as a blocker for Fedora 36 on the basis upstream did
>  > not consider it fixable within the F36 timeframe. We agreed that if
>  > upstream still couldn't get this fixed for F37, we'd consider revising
>  > the criteria.
>  > 
>  > Well, we're approaching F37 Final and the bug is still open, and
>  > there's no appreciable movement upstream, so I'm proposing the criteria
>  > change. I propose we change this:
>  > 
>  > "The installer must be able to install into free space alongside an
>  > existing clean Windows installation and install a bootloader which can
>  > boot into both Windows and Fedora."
>  > 
>  > to say:
>  > 
>  > "The installer must be able to install into free space alongside an
>  > existing clean Windows installation. As long as the Windows
>  > installation does not have BitLocker enabled, the installer must also
>  > install a bootloader which can boot into both Windows and Fedora."
>  
>  (Fedora grub2 maintainer hat on)
>  
>  I'm fine with the proposed change.  I'm also fine with the original
>  text.
>  
>  During boot, certain actions are taken that are recorded in the TPM.
>  These include, for instance, any loaders that are run - like grub2.  The
>  result is that if you load Windows from grub2 rather than the EFI
>  firmware, the TPM state will be different.  Bitlocker cares about this
>  TPM state.
>  
>  So: if you install Windows and set up Bitlocker booting through grub, it
>  will continue to work through grub.  If you install Windows outside grub
>  (or it's pre-provisioned), it will continue to work outside grub.  If
>  you want to move from not using grub to using grub, then Bitlocker needs
>  to be reestablished with the new TPM values.
>  
>  It is the opinion of the grub2 maintainers that this constitutes being
>  able to boot both Windows and Fedora today.  However, we also understand
>  that not everyone agrees with this, as evidenced by the existence of the
>  bug and this thread about changing RC. 
Practically speaking, the way this is "expected" to work is, you get a
system with Windows pre-installed, then you install Fedora, and Fedora
makes it so you can boot both Fedora and Windows. This is the
expectation that's built up around how things ought to work, and it's
what the existing criterion is trying to express.

In general, people do not start out with Linux installed and then
install Windows, this just isn't really a thing that happens a lot.

The word 'you' in your text is kinda doing a lot of heavy lifting. I
would say that what we (we-as-in-Fedora) are concerned with here are
users who do not want to know or care about the details of grub or UEFI
or Windows or BitLocker. The user does not really "want" to "move from
not using grub to using grub". The user wants to move from only having
Windows to having both Windows and Linux. That's the high-level goal
here. grub is an implementation detail (chosen by "us", Fedora, not by
the user).

>  The only way to get the TPM state to match not using a particular
> loader
>  is to not use a loader - i.e., have grub2 (or efibootmgr in Fedora
>  userspace) set EFI BootNext and reboot the machine.  But generally, if
>  users want to be booting Windows through grub, we recommend they
>  configure Bitlocker against those PCR values instead. 
Is there a good place to point folks who are interested in the
technical details here for documentation?

Thanks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Demi Marie Obenour]

On 9/19/22 16:45, Robbie Harwood wrote:
>  Adam Williamson <adamwill(a)fedoraproject.org&gt; writes:
>  
> > For background here, see:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2049849
> >
> > right now, when installing Fedora alongside a Windows install with
> > BitLocker enabled, trying to boot Windows from the Fedora boot menu
> > does not work.
> >
> > We waived the bug as a blocker for Fedora 36 on the basis upstream did
> > not consider it fixable within the F36 timeframe. We agreed that if
> > upstream still couldn't get this fixed for F37, we'd consider revising
> > the criteria.
> >
> > Well, we're approaching F37 Final and the bug is still open, and
> > there's no appreciable movement upstream, so I'm proposing the criteria
> > change. I propose we change this:
> >
> > "The installer must be able to install into free space alongside an
> > existing clean Windows installation and install a bootloader which can
> > boot into both Windows and Fedora."
> >
> > to say:
> >
> > "The installer must be able to install into free space alongside an
> > existing clean Windows installation. As long as the Windows
> > installation does not have BitLocker enabled, the installer must also
> > install a bootloader which can boot into both Windows and Fedora."
>  
>  (Fedora grub2 maintainer hat on)
>  
>  I'm fine with the proposed change.  I'm also fine with the original
>  text.
>  
>  During boot, certain actions are taken that are recorded in the TPM.
>  These include, for instance, any loaders that are run - like grub2.  The
>  result is that if you load Windows from grub2 rather than the EFI
>  firmware, the TPM state will be different.  Bitlocker cares about this
>  TPM state.
>  
>  So: if you install Windows and set up Bitlocker booting through grub, it
>  will continue to work through grub.  If you install Windows outside grub
>  (or it's pre-provisioned), it will continue to work outside grub.  If
>  you want to move from not using grub to using grub, then Bitlocker needs
>  to be reestablished with the new TPM values.
>  
>  It is the opinion of the grub2 maintainers that this constitutes being
>  able to boot both Windows and Fedora today.  However, we also understand
>  that not everyone agrees with this, as evidenced by the existence of the
>  bug and this thread about changing RC.
>  
>  The only way to get the TPM state to match not using a particular loader
>  is to not use a loader - i.e., have grub2 (or efibootmgr in Fedora
>  userspace) set EFI BootNext and reboot the machine.  But generally, if
>  users want to be booting Windows through grub, we recommend they
>  configure Bitlocker against those PCR values instead. 
That is a terrible user experience.  Grub should support setting BootNext
and rebooting.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Chris Adams]

Once upon a time, Robbie Harwood <rharwood(a)redhat.com&gt; said:
>  So: if you install Windows and set up Bitlocker booting through grub,
> it
>  will continue to work through grub.  If you install Windows outside grub
>  (or it's pre-provisioned), it will continue to work outside grub.  If
>  you want to move from not using grub to using grub, then Bitlocker needs
>  to be reestablished with the new TPM values. 
Aside from this not covering what is likely the most common case of
installing Linux on a computer that had Windows pre-installed (as Adam
pointed out)... is there any documentation on how to fix a pre-existing
Windows install that is broken by booting grub?

Also: if I understand the TPM measured boot methodology correctly, this
exposes the Windows install to being lost when grub is updated, because
there's no way for the Linux system updating grub to update the Windows
stored hash.  Users would have to have their Bitlocker recovery key at
the ready (and know how to use it) BEFORE any potential grub update.

We really need grub to support setting the UEFI BootNext value; it's the
safest and sanest way to boot Windows with the least impact.  Is there a
technical reason grub should _not_ do this?

I guess an alternative if grub devs refuse to support this would be a
stand-alone UEFI executable that could set BootNext and reboot.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Chris Murphy]

On Mon, Sep 19, 2022, at 2:45 PM, Robbie Harwood wrote:

>  I'm fine with the proposed change.  I'm also fine with the
> original
>  text.
>
>  During boot, certain actions are taken that are recorded in the TPM.
>  These include, for instance, any loaders that are run - like grub2.  The
>  result is that if you load Windows from grub2 rather than the EFI
>  firmware, the TPM state will be different.  Bitlocker cares about this
>  TPM state.
>
>  So: if you install Windows and set up Bitlocker booting through grub, it
>  will continue to work through grub.   
The Windows installer drops a payload on the drive, and sets a bootnext for an entry that
points to the Windows bootloader, not via GRUB. 

And then, the instant we update either shim or grub, Windows boot will break. 

I think working around this is sufficiently tedious no users are likely to do it.

-- 
Chris Murphy

[Sandro]

On 20-09-2022 07:12, Chris Murphy wrote:
>  
>  
>  On Mon, Sep 19, 2022, at 2:45 PM, Robbie Harwood wrote:
>  
> > I'm fine with the proposed change.  I'm also fine with the
> > original text.
> > 
> > During boot, certain actions are taken that are recorded in the
> > TPM. These include, for instance, any loaders that are run - like
> > grub2.  The result is that if you load Windows from grub2 rather
> > than the EFI firmware, the TPM state will be different.  Bitlocker
> > cares about this TPM state.
> > 
> > So: if you install Windows and set up Bitlocker booting through
> > grub, it will continue to work through grub.
>  
>  The Windows installer drops a payload on the drive, and sets a
>  bootnext for an entry that points to the Windows bootloader, not via
>  GRUB.
>  
>  And then, the instant we update either shim or grub, Windows boot
>  will break. 
Does all this apply as well using sd-boot?

If not, since this is the install phase, switching from grub to sd-boot 
when installing alongside Windows should be viable.

Having said that, I am aware that sd-boot is currently not as well 
supported as grub2.

-- Sandro

[Chris Murphy]

On Mon, Sep 19, 2022, at 2:45 PM, Robbie Harwood wrote:

>  The only way to get the TPM state to match not using a particular
> loader
>  is to not use a loader - i.e., have grub2 (or efibootmgr in Fedora
>  userspace) set EFI BootNext and reboot the machine.   
I know systemd-boot does implement bootnext, can modify it in NVRAM. But last I checked
GRUB can't.

I've asked upstream GRUB about supporting bootnext and a reboot, but the discussion
didn't go anywhere. Is there any interest or work happening to make this possible?
Because if not, then it seems the only way forward is efibootmgr, and see if desktops want
to add a GUI wrapper around it.



-- 
Chris Murphy

[Kamil Paral]

On Mon, Sep 19, 2022 at 9:17 PM Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  "The installer must be able to install into free space alongside
> an
>  existing clean Windows installation. As long as the Windows
>  installation does not have BitLocker enabled, the installer must also
>  install a bootloader which can boot into both Windows and Fedora."
>  
The updated criterion sounds OK to me.

[Chris Murphy]

On Mon, Sep 19, 2022, at 1:16 PM, Adam Williamson wrote:

>  "The installer must be able to install into free space alongside an
>  existing clean Windows installation and install a bootloader which can
>  boot into both Windows and Fedora."
>
>  to say:
>
>  "The installer must be able to install into free space alongside an
>  existing clean Windows installation. As long as the Windows
>  installation does not have BitLocker enabled, the installer must also
>  install a bootloader which can boot into both Windows and Fedora." 
Workstation working group discussed it at today's meeting, and there were no
objections to the language change proposal.

-- 
Chris Murphy

[Brian C. Lane]

On Mon, Sep 19, 2022 at 12:16:33PM -0700, Adam Williamson wrote:
>  "The installer must be able to install into free space alongside
> an
>  existing clean Windows installation and install a bootloader which can
>  boot into both Windows and Fedora."
>  
>  to say:
>  
>  "The installer must be able to install into free space alongside an
>  existing clean Windows installation. As long as the Windows
>  installation does not have BitLocker enabled, the installer must also
>  install a bootloader which can boot into both Windows and Fedora." 
We have reached a point where boot security is important enough that
Windows is now only allowing their bootloader to be used. With bitlocker
enabled this is working exactly how it was designed so I'd change the
wording to require that grub2 doesn't prevent windows from continuing to
boot via their preferred method and leave it at that.

And while there may be a possible solution using BootNext, until someone
does the work and tests it there is no point in requiring grub2 to do
something it cannot do.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

[Chris Murphy]

On Tue, Sep 20, 2022, at 9:50 AM, Brian C. Lane wrote:
>  On Mon, Sep 19, 2022 at 12:16:33PM -0700, Adam Williamson wrote:
> > "The installer must be able to install into free space alongside an
> > existing clean Windows installation and install a bootloader which can
> > boot into both Windows and Fedora."
> > 
> > to say:
> > 
> > "The installer must be able to install into free space alongside an
> > existing clean Windows installation. As long as the Windows
> > installation does not have BitLocker enabled, the installer must also
> > install a bootloader which can boot into both Windows and Fedora."
>
>  We have reached a point where boot security is important enough that
>  Windows is now only allowing their bootloader to be used. With bitlocker
>  enabled this is working exactly how it was designed so I'd change the
>  wording to require that grub2 doesn't prevent windows from continuing to
>  boot via their preferred method and leave it at that.
>
>  And while there may be a possible solution using BootNext, until someone
>  does the work and tests it there is no point in requiring grub2 to do
>  something it cannot do. 
An additional topic is having boot entries for Windows (and macOS) that don't work in
the meantime. While we could just remove the scripts that create these entries to
chainload another bootloader, they're still needed for BIOS systems which don't
support bootnext.


-- 
Chris Murphy

[Chris Adams]

Once upon a time, Chris Murphy <lists(a)colorremedies.com&gt; said:
>  An additional topic is having boot entries for Windows (and macOS)
> that don't work in the meantime. While we could just remove the scripts that create
> these entries to chainload another bootloader, they're still needed for BIOS systems
> which don't support bootnext. 
But not all Windows chainload boots will fail.  It's not even all that
easy to tell which Windows installs will or won't work... the presence
of Bitlocker is not a 100% sign even (it could be an unlocked Bitlocker
install, which doesn't get the TPM measure and fail from grub).
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Adam Williamson]

On Tue, 2022-09-20 at 11:48 -0500, Chris Adams wrote:
>  Once upon a time, Chris Murphy <lists(a)colorremedies.com&gt; said:
>  > An additional topic is having boot entries for Windows (and macOS) that don't
> work in the meantime. While we could just remove the scripts that create these entries to
> chainload another bootloader, they're still needed for BIOS systems which don't
> support bootnext.
>  
>  But not all Windows chainload boots will fail.  It's not even all that
>  easy to tell which Windows installs will or won't work... the presence
>  of Bitlocker is not a 100% sign even (it could be an unlocked Bitlocker
>  install, which doesn't get the TPM measure and fail from grub). 
yeah, on the whole I'd prefer to leave it if we can't accurately decide
when to include it.

Note the rewritten criteria is OK with either.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Kevin Kofler]

Brian C. Lane wrote:
>  We have reached a point where boot security is important enough
LOL!

>  that Windows is now only allowing their bootloader to be used.
It is blatantly obvious that that is actually the goal, not the means.

This is clearly a vendor lock-in "feature", with "security" used as
the 
excuse (just like other similar vendor lock-in "features", e.g., the iOS App 
Store monopoly).

Incidentally, the "feature" not only prevents chainloading (which can be 
worked around by using BootNext), but also disabling Restricted Boot 
("Secure" Boot) altogether (which is a much worse restriction), because 
that, too, changes the TPM PCR measurements.

But the marketing as a "security" "feature" clearly works, because
there 
does not seem to be any noticeable public outrage about these absolutely 
unacceptable monopolistic restrictions.

        Kevin Kofler

[Adam Williamson]

On Mon, 2022-09-19 at 12:16 -0700, Adam Williamson wrote:
>  For background here, see:
>  https://bugzilla.redhat.com/show_bug.cgi?id=2049849
>  
>  right now, when installing Fedora alongside a Windows install with
>  BitLocker enabled, trying to boot Windows from the Fedora boot menu
>  does not work.
>  
>  We waived the bug as a blocker for Fedora 36 on the basis upstream did
>  not consider it fixable within the F36 timeframe. We agreed that if
>  upstream still couldn't get this fixed for F37, we'd consider revising
>  the criteria.
>  
>  Well, we're approaching F37 Final and the bug is still open, and
>  there's no appreciable movement upstream, so I'm proposing the criteria
>  change. I propose we change this:
>  
>  "The installer must be able to install into free space alongside an
>  existing clean Windows installation and install a bootloader which can
>  boot into both Windows and Fedora."
>  
>  to say:
>  
>  "The installer must be able to install into free space alongside an
>  existing clean Windows installation. As long as the Windows
>  installation does not have BitLocker enabled, the installer must also
>  install a bootloader which can boot into both Windows and Fedora." 
So since nobody objected to this proposal, I'm going to put it into
production today and kick the current accepted blocker bug back to
proposed (from where I'd expect it to get rejected).

Thanks folks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net