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.
Metadata Update from @chrismurphy: - Issue tagged with: meeting-request
I've resummarized and posted future of dual booting Windows and Fedora, redux to the Fedora devel mailing list.
This needs more visibility though, somehow. It affects Fedora downstreams, any distribution targeting Windows users with explicit dual boot support, and any desktop environment. But I'm not sure how to go about getting it that visibility. What about bringing it to the attention to lwn and see if a staff writer wants to take this on?
My take with RH bootloader folks is they would be happy to cede this to user space, e.g. efibootmgr, and optionally a GUI wrapper for it. In this case, we don't need a bootloader specific developer, but UI/UX eval and a proper home for it. Discoverability might be the hardest part. Maybe it should go in the restart/shutdown menu rather than expecting the user to find a g-c-c panel?
There's minimum requirements and scope to figure out. efibootmgr lists many things that don't need to be exposed to the user, because this isn't a replacement for the firmware's boot options menu. It just tries to make it easier to boot some other OS. The question is whether it should be limited to to Windows (and possibly macOS), or extended to any Linux distro.
efibootmgr
Note: Make sure to (re)consider the role of the normally hidden "Boot Options" in the restart/shutdown menu, revealed when holding down the Alt key. This currently causes the "hidden GRUB menu" to appear on the next boot.
How confusing is it when some boot options are in the GRUB menu and other boot options are in a g-c-c panel? Could they all go in a new g-c-c boot options panel?
Just unlocking bitlocker and resizing the Windows volume will still break the TPM measurement and lead to the recovery page next boot.
Instead, you would need to suspend bitlocker and resize the Windows volume from within Windows, install Fedora in the free space, then boot back to Windows and reenable bitlocker. That will update the boot measurement to include GRUB. Things will work ok until grub is updated.
Would it help if I write up a full gist or video on the topic? I’d also be happy to collaborate on testing a grub-less option. I dual boot Fedora 36 on multiple machines with bitlocker and secure boot enabled.
In the latest workstation wg meeting notes i saw “ ACTION: Allan to set up a separate call with interested parties (brainycmurf, 01:12:46)” - where could I get more info on the followup? I could join if I’m available
Metadata Update from @catanzaro: - Issue untagged with: meeting-request
Sorry @patricklang , I only just noticed this comment. I'm going to organise this conversation soon. If you want to make contact on Matrix (#workstation:fedoraproject.org) , I'll add you to the invite.
#workstation:fedoraproject.org
@aday did this call happen? Any status update?
@aday did this call happen?
I'm currently in the process of organising it. Hopefully it will happen in the next couple of weeks.
The call is happening at 15:00 UTC on Friday 20 January. If anyone wants to participate, just let me know.
If someone has a dual boot system and they want to switch to the other OS, having to dig into the settings each time is going to be rather frustrating.
It might be better to list the available boot targets in gnome-shell's reboot dialog.
We should be able to identify boot targets at startup for desktops to populate in their various system action menus/dialogs, right?
What we discussed in the call was filtering the output of efibootmgr to identify valid boot targets - basically any entries starting with HD. We'll also need to eliminate any entries that don't exist on disk.
HD
Hmm, so the issue here might be that elevated privileges are required to set bootnext...
I've got to a reasonable stage with the designs now, and have filed a couple of tickets against gnome-shell to have them implemented:
As far as I'm aware, no one is lined up to work on this.
gnome-shell requires a d-bus api that it can use to set next boot. @feborges requested this from systemd in systemd#26397 , which has been marked as a duplicate of systemd#11221 .
Login to comment on this ticket.