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 adamwill@fedoraproject.org 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
On Mon, 2022-09-19 at 16:45 -0400, Robbie Harwood wrote:
Adam Williamson adamwill@fedoraproject.org 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!
On 9/19/22 16:45, Robbie Harwood wrote:
Adam Williamson adamwill@fedoraproject.org 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.
Once upon a time, Robbie Harwood rharwood@redhat.com 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.
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.
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
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.
On Mon, Sep 19, 2022 at 9:17 PM Adam Williamson adamwill@fedoraproject.org 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.
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.
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
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.
Once upon a time, Chris Murphy lists@colorremedies.com 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).
On Tue, 2022-09-20 at 11:48 -0500, Chris Adams wrote:
Once upon a time, Chris Murphy lists@colorremedies.com 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.
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
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!