Problem Laptops with TPM 2.0 and Modern Standby and Windows 10 or 11 preinstalled [1] have Bitlocker disk encryption enabled by default, and the key is sealed in the TPM. Two problems result:
Potential Solutions
BootNext
efibootmgr --bootnext
Notes [1] The scope of the issue is confusing due to Microsoft's policy changing within the Windows 10 lifecycle. Most computers with Windows 10 Pro preinstalled in the last ~2 years have it enabled, e.g. ThinkPad X1 Carbon Gen 7 Laptop. Windows 10 Home often doesn't have it enabled. Users with Windows 11 Home are reporting it is enabled.
[2] Anaconda uses cryptsetup to unlock encrypted volumes. Cryptsetup supports the Bitlocker metadata format, and can unlock these volumes, but not modify the metadata. Upstream cryptsetup thread expresses uncertainty over resizing. Anaconda/blivet doesn't support BitLocker yet, an RFE has been filed.
[3] Bitlocker seals the encryption key in the TPM. Measured Boot uses the TPM to cryptographically verify the boot chain, and only unseal the Bitlocker encryption key if the boot chain is intact. The usage of either shim or GRUB results in unexpected measured boot values and thus boot failure, as it's indistinguishable from the boot chain being tampered with. The end user sees a blue Bitlocker Recovery Key page, and if they enter their ~48 character recovery key, the system boots.
Metadata Update from @chrismurphy: - Issue assigned to chrismurphy - Issue set to the milestone: Future Release - Issue tagged with: experience, installation, meeting-request
Metadata Update from @chrismurphy: - Issue untagged with: meeting-request
I've simplified the issue. Two things I forgot to mention at the meeting that are relevant:
Related Bug 2049849 is a conditional blocker for Fedora 36. The final release criterion says our bootloader needs to boot Windows, and right now it doesn't. It's conditional because while it affects many users, it's not yet the vast majority (or so far as we know).
User-space boot selection tool. It could be as simple as a "Reboot to Windows" checkbox in the reboot dialog.
Windows with bitlocker enabled can't be booted, needs to use bootnext instead of chainloader https://bugzilla.redhat.com/show_bug.cgi?id=2049849
This release blocking bug has been waived as "difficult to fix" for Fedora 36. If it's not addressable for Fedora 37, good chance the release criterion that requires the bootloader being capable of booting both Fedora and Windows will be dropped.
We're at risk for Fedora 37's GRUB menu entry being unable to boot Windows for recent hardware.
Login to comment on this ticket.