rEFInd 0.14 vs BitLocker on Windows 11

[Kaz Wolfe]

I recently made the jump from Fedora 37's built-in GRUB (version 2.06-88.fc37) to rEFInd, and everything appears to be mostly working, save for the exception of booting into Windows.

While using the normal Fedora-installed GRUB, BitLocker will prompt (as we expect) for the recovery key after a GRUB update or any (notable) part of the boot chain is changed, and Windows updates the key protector to use PCRs 0, 2, 4, and 11, as described in this article. All future boots will work directly, and will not require the recovery key to be re-entered.

Enter, however, a boot through rEFInd. As we expect, switching the bootloader to rEFInd will cause the PCRs to become invalidated and the recovery key to be needed again. However, all subsequent boots will also prompt for a recovery key, even though no apparent values are changing. Following Microsoft's guide to logging PCR changes and building my own version of PCPTool.exe, two back-to-back boots from rEFInd show that the relevant PCRs are still matching exactly yet BitLocker still complains about PCR mismatches (although, frustratingly, it doesn't tell me which PCRs mismatch).

While I suspect this is very much a Windows problem (although I have no idea where to even ask about such a problem, much less do I think Microsoft would care to issue a fix), it seems curious that the default GRUB bootloader works without any issue and that this problem only manifests when using rEFInd.

I'm aware of the bootnext stanza, although I'm a bit wary on engaging that due to the potential limitations of NVRAM storage. Is there any other guidance that may be relevant here or possible explanations for this behavior? Ideally, I'd like to get the best of all the worlds, but so far it doesn't look like that's possible.

[Roderick W. Smith]

I have essentially no experience with BitLocker, so I can't offer anything more than speculative advice. That said, my questions and thoughts are these:

• What happens if you boot from rEFInd to a Linux kernel, vs. rEFInd to GRUB to a Linux kernel? I wouldn't expect there to be a difference, but if there is, that would be informative.
• Does booting Windows through rEFInd, and then rebooting Windows again through rEFInd, without booting Fedora, cause the recovery key to be needed?
• In normal operation with its default settings, rEFInd alters the ESP whenever it boots. This is because it stores data in its vars subdirectory, to hold the previous boot, if nothing else. It's conceivable that Windows is detecting this and getting paranoid about it. If so, you could set use_nvram true to cause rEFInd to log this data to NVRAM variables instead of disk variables. (This will increase NVRAM wear and tear, but rEFInd actually writes data only if it changes, so if you reboot to the same OS a dozen times, there will be no writes beyond the first one.) Similarly, if you've uncommented the log_level line, rEFInd will write log files to disk.
• rEFInd does not normally touch NVRAM when it boots; however, if you set use_nvram true or if you set write_systemd_vars true, then rEFInd will write to NVRAM whenever it boots. It's conceivable that Windows is noticing such changes and becoming paranoid about them. If so, then setting both these options to false might work around the problem -- unless of course BitLocker is also checking for changes to the ESP, as in the previous point.
• It's conceivable that Windows recognizes GRUB and/or major Linux distributions as a semi-trusted component in the EFI boot options list. If so, then renaming the refind directory to, say, ubuntu, and creating a new EFI boot variable to match (named ubuntu and pointing to the Shim binary that launches rEFInd in the ubuntu directory), might pacify Windows. Even if this works, it would have the drawback that you'd need to handle rEFInd updates manually.
• It's worth trying the option to reboot through the firmware to Windows. I understand your reluctance to write too much to the NVRAM, but if nothing else, it's worth doing this once as a test.
• Are you loading any EFI filesystem drivers in rEFInd? When rEFInd loads drivers, it patches them into the firmware in a way that Windows might conceivably notice. You can try temporarily removing the drivers from the drivers_x64 subdirectory and seeing if that helps. (You'll either be unable to boot Fedora or will have to boot through GRUB.) If this helps, then you can either permanently use a rEFInd-to-GRUB boot path or put your Linux kernels on a FAT partition. One way to do the latter is to use a FAT /boot partition, so that rEFInd doesn't need to load drivers; but some distributions don't work well like this, since they rely on symbolic links or other Unix/Linux features in /boot. I don't know offhand how much trouble a FAT /boot partition would cause Fedora. Another way to do this would be to copy your kernels to a FAT partition after Fedora installs them. You could do this in a custom shutdown script or in some other way. (Remember that deleting old kernels is equally important.)

[Kaz Wolfe]

All of my tests so far have been rebooting from Windows into Windows. Everything else about rEFInd (except for the shim link) should be stock.

For posterity, the specific BitLocker error is:

Bootmgr failed to obtain the BitLocker volume master key from the TPM because the PCRs did not match. (Error Code 0xc0280018, Event ID 24635)

This is, frustratingly, all I have.

Otherwise as requested though:

• Using firmware_bootnum does work exactly as intended, and restores use of PCRs 07 and 11 now that Windows is satisfied with the boot integrity chain.
• The only driver being loaded is the ext4 driver that comes shipped with rEFInd's RPM. That being said, however it's loading shouldn't matter as the PCR values are consistent.
• Booting from Windows -> Windows (through rEFInd's discovered entry) will trigger recovery every time.
• I'll try naming things in different ways, but I'd be very surprised if this would be the cause. It'd definitely be a rotten state of affairs inside Windows if this were the case...

Another thing to note is that my Windows and Linux installs are on completely separate drives with their own individual ESPs. I'm not sure this makes any particular difference, but it may be worth mentioning for consistency's sake.

Lastly, digging a bit into the diagnostic data and comparing PCRs led to a bit of an interesting pattern:
1. Switch to GRUB, boot Windows. Get recovery prompt.
2. Boot Windows from Grub again, no recovery prompt. Record PCR values.
3. Boot Windows from grub yet again, no recovery prompt. Record PCR values.
4. Switch to rEFInd, boot Windows. As expected, get recovery prompt.
5. Boot Windows from rEFInd again, get recovery prompt. Record PCR values.
6. Boot Windows from rEFInd yet again, get recovery prompt. Record PCR values.

In both steps 2/3 and 5/6, the only change (according to Windows' MeasuredBoot) to PCR values was the boot counter; all other registers stayed the same. As far as I can tell though, GRUB does one extra thing that rEFInd doesn't appear to do: it loads data into PCR 08 and 09 from the tpm module. I'm not sure if this is part of the problem (and it really shouldn't be, given Windows is supposed to ignore these PCRs), but it seems worth mentioning.

[npg_]

I'm not sure if this helps at all, but I got BitLocker to run with Win11 + rEFInd 14.0.2 by editing group policy.

Specifically, going from Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives > Configure TPM platform validation profile for native UEFI firmware configurations via gpedit and only checking "PCR 07" and "PCR 11" so that way 0/2/4/others aren't checked on boot.

I'm not sure if this harms security at all, but it appears as though windows is supposed to do this by default as per this article, under "About PCR 7".

edit: Should probably add that I'm also booting F38 SB beta.
Win: RH shim -> rEFInd -> bootmgfw.efi
FSB: RH shim -> rEFInd -> grub(x64).efi

[Dana Goyette]

One thing you could try is to formally suspend BitLocker, then reboot, then resume BitLocker, then reboot again. If it's Windows Home, there's no UI to do that, but you can do it with PowerShell. Perhaps that would make it actually rewrite its expectations of the PCRs?