Increased Use Of Windows BitLocker Is Causing Headaches For Linux Dual Booting

Written by Michael Larabel in Microsoft on 27 July 2022 at 06:00 AM EDT. 78 Comments
MICROSOFT --
Increase use of Windows BitLocker for full-disk encryption on Windows 10 and Windows 11 is causing more challenges by Linux distributions for supporting convenient dual boot functionality for those wishing to keep both Windows and Linux on the same systems.

Fedora / Red Hat engineers are ringing the alarm bells over dual booting Windows and Linux becoming more challenging to support. In particular, Windows' BitLocker for full-disk encryption where the encryption key is sealed using the TPM hardware.

When engaging BitLocker, Fedora's Anaconda installer (and other known Linux distribution installers) can't resize BitLocker volumes. But it's possible to resize BitLocker volumes within Windows, so it's more of a documentation matter for informing users planning to dual boot that they should first ensure they have enough free space on their system by resizing any encrypted volumes.


Windows 11 increased promoting BitLocker disk encryption is good for security but poses more challenges for co-existing nicely with Linux distributions on the same hardware.


The other more pressing manner is that the BitLocker encryption key is unsealed only if the boot chain measurement by the TPM matches the expected values in a TPM PCR. When using the shim and GRUB in the boot chain as used by Fedora by default for dual boot setups, the measurement values are wrong and the BitLocker encryption key can't be properly unsealed. Users trying to dual boot with the current Fedora Linux release will get dropped to a BitLocker recovery screen when trying to boot Windows 10/11 with this full-disk encryption method.

These Windows BitLocker challenges have been known for months and originally a Fedora 36 blocker bug until diverted to Fedora 37 due to the challenging obstacles. Among the avenues being pursued are modifying GRUB to set the UEFI NVRAM "boot next" value so rather than chainloading will set the next system boot directly to the Windows bootloader. But upstream GRUB isn't particularly interested in this feature while systemd-boot has already implemented support for it. Or there is also the possibility of creating a user-space utility to modify the system NVRAM to modify the next boot setting to directly boot into the Windows bootloader. In turn the dual boot options for the latter route might be dropped from GRUB with users instead from the booted Fedora Linux OS having an option if they want to reboot into Windows rather than deciding at boot loader time.

These BitLocker headaches are currently being discussed on the Fedora mailing list but ultimately is a broader problem for Linux distributions in dealing with BitLocker encrypted volumes and other distributions relying on GRUB.
Related News
About The Author
Author picture

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via MichaelLarabel.com.

Popular News This Week