Bug 2049849 - Windows with bitlocker enabled can't be booted, needs to use bootnext instead of chainloader
Summary: Windows with bitlocker enabled can't be booted, needs to use bootnext instead...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Javier Martinez Canillas
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker https://ask.fedorapro...
Depends On:
Blocks: F37FinalBlocker, FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2022-02-02 19:27 UTC by Chris Murphy
Modified: 2022-06-16 16:34 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)

Description Chris Murphy 2022-02-02 19:27:24 UTC
Description of problem:

Currently grub.cfg contains:
	chainloader /EFI/Microsoft/Boot/bootmgfw.efi

This won't work with recent Windows 10 systems with TPM 2.0, which now default to Bitlocker being enabled out of the box with the disk encryption key sealed in the TPM. As a result of shim->grub->chainloader, the TPM measurements have changed and therefore the bitlocker key won't be unsealed by the TPM, resulting in a Windows recovery boot asking for the bitlocker encryption passcode.


Version-Release number of selected component (if applicable):
grub2-2.06-14.fc36


How reproducible:
Always


Steps to Reproduce:
1. Computer with TPM 2.0 and a default clean installation of Windows 10 or 11 (I did this on a Lenovo ThinkPad X1 Carbon Gen 7 laptop; blkdiscard the entire NVMe drive; clean installed Windows from an ISO downloaded from microsoft.com about 9 months ago, and it enabled bitlocker encryption by default)
2. Do a default Fedora installation (resize Windows partition to create enough free space for Fedora)
3. In the GRUB menu, select Windows Boot Manager

Actual results:

I see a Bitlocker Recovery screen requesting entry of a recovery key. Boot will not proceed without it.


Expected results:

Instead of chainloading the Windows bootloader from GRUB, GRUB needs to set BootNext in NVRAM followed by system reset. That way the firmware does a one time boot of the Windows bootloader directly (without shim or grub), resulting in valid TPM measurements unsealing the bitlocker key, and a seamless boot of Windows.


Additional info:


See also bug 1700397 and bug 1426328.

Comment 1 Fedora Blocker Bugs Application 2022-02-02 19:38:56 UTC
Proposed as a Blocker for 36-final by Fedora user chrismurphy using the blocker tracking app because:

 https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Windows_dual_boot

"and install a bootloader which can boot into ... Windows"

The intent of the criterion is that Windows is bootable, which it isn't. In that sense, the bug is a blocker.

However, this isn't a bug per se, nor is it a regression in GRUB. TPM measured boot is working as designed. This is in effect a request for enhancement for GRUB. From this point of view, it's maybe not a blocker because the criterion itself is prescribing a solution that won't work.

The current work around is to use the firmware's boot manager to choose to boot Windows.

This is probably a good candidate for common bugs documentation, and as a prioritized bug though.

Comment 2 Geoffrey Marr 2022-02-07 21:03:00 UTC
Discussed during the 2022-02-07 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:

"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" in the case of Windows being installed with Bitlocker enabled (as is increasingly common).

We recognize this is technically difficult to fix and may change or defer.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-02-07/f36-blocker-review.2022-02-07-17.00.txt

Comment 3 Robbie Harwood 2022-02-07 21:50:23 UTC
> The current work around is to use the firmware's boot manager to choose to boot Windows.

One can manipulate this from Linux using efibootmgr to set BootNext to the Windows entry as well.

I recommend either changing the criteria or deferring.

Comment 5 Ben Cotton 2022-02-08 20:07:12 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

Comment 6 Zbigniew Jędrzejewski-Szmek 2022-02-10 07:46:26 UTC
For sd-boot we solved it by using BootNext [1]. That code will be available in rawhide
after the next release (~one or two weeks). It's reported to work, though I haven't
tried it myself due to lack of appropriate wall fixtures.

[1] https://github.com/systemd/systemd/pull/22043/commits/661615a0afacee3545cde0a48286c0fef983f8fe

Comment 7 Adam Williamson 2022-03-29 19:01:40 UTC
At the 2022-03-28 blocker review meeting, we agreed to waive this bug to Fedora 37 according to the process:

https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases
https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-03-28/f36-blocker-review.2022-03-28-16.00.html
https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-03-28/f36-blocker-review.2022-03-28-16.00.log.html

This is considered a "difficult to fix" bug - as indicated by Robbie above, there is no realistic prospect of it being fixed during the Fedora 36 timeframe.

Accordingly, it is waived to Fedora 37. If upstream still doesn't consider this addressable during that timeframe, we'll consider amending the release criteria to not require dual-boot to work with BitLocker-enabled Windows installs.


Note You need to log in before you can comment on or make changes to this bug.