#278 Future of dual booting Windows and Fedora
Opened 5 months ago by chrismurphy. Modified 3 months ago

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:

  • Bitlocker volume can't be resized in Linux {INSTALL/RESIZE}[2]
  • Bitlocker volume can't be unlocked when booting from GRUB {BOOT} [3]

Potential Solutions

  • Shrink using Window's Disk Management {INSTALL/RESIZE}
    • poor UI/UX
    • Should a new Windows resize tool be commissioned? At the March 15, 2022 meeting, the group decided it's worth investigating, dual boot is an important use case
  • UEFI firmware provide a built-in boot manager {BOOT}
    • No standard Fn key to bring it up
    • Highly variable UI/UX - difficult to generically document
  • FOSS bootloader {BOOT}
    • systemd-boot recently supports setting BootNextEFI variable, followed by a reboot. This works around the issue, and the UI/UX is the same as today.
    • Upstream GRUB are thus far unresponsive to implementing the same thing as sd-boot, or providing alternatives, see grub-devel thread
  • User-space boot selection {BOOT}
    • A graphical tool could use efibootmgr --bootnext to set Windows as the next booted OS following a reboot.

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

5 months ago

Metadata Update from @chrismurphy:
- Issue untagged with: meeting-request

4 months ago

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.

Metadata
Boards 1
Installing Status: Backlog