Does rEFInd modify NVRAM when booting?

[Three Monkeys]

Hi,

I've been using Archlinux, Windows and rEFInd for a few years. I configured Secure Boot (with shim). I was perfectly happy with this configuration, until I decided to activate Bitlocker for Windows. As I have a TPM device on my motherboard, I decided to use PIN protection. Everything works fine except one thing : every time I boot WIndows through rEFInd, after the PIN, Windows asks for a recovery key because "something changed since the last use of Windows". I know the TPM checks if some PCR (Platform Configuration Registers) values changed since the last boot (ROM, hard drives, and so ever) before releasing the key with the PIN. What I don't understand is what is changing.

The root cause seems to be rEFInd:

• without rEFInd, when using UEFI boot menu directly, Bitlocker asks for the PIN and everything is fine, even when I switch from Linux to Windows and vice-versa;
• with rEFInd, even from Windows to Windows, Bitlocker asks for the PIN and for the recovery PIN (defeating the purpose of the PIN, of course);
• I tried to find which PCR is changing, it's easy with Linux, but I don't know how to do it with Windows ;
• no problem with Archlinux, through rEFINd or through UEFI boot menu.

I tried to disable hiddentags in rEFInd configuration, as it uses NVRAM to store some informations (and I think that TPM checks if NVRAM data changed), but no luck so far.

What could I try in order to solve this issue? I really like rEFInd, but eventually I'll replace it with systemd-boot if I don't find any solution.

[faginbagin]

Yes, it writes to a PreviousBoot NVRAM variable. Maybe BitLocker doesn't like that. See this thread for more info:
https://sourceforge.net/p/refind/discussion/general/thread/c76fee70/

[Three Monkeys]

Thanks for your answer! It is a first clue. I'll try to boot Windows three times in a row (PreviousBoot=Linux, then PreviousBoot=Windows, then PreviousBoot=Windows). If it is the only value changed by rEFInd, the third time, Bitlocker shouldn't ask for the recovery key.

[Ethan Peters]

I'm experiencing the exact same problem, did you ever find a solution to this?

[Robert K.]

I get the same problem. I have BitLocker encryption on my Windows 10 partition. Whenever I try to boot Windows 10 from rEFInd I'm getting BitLocker blue screen informing me that secure boot process has been modified and I need to unlock my drive with BitLocker security key.

When I boot Windows Boot Manager from UEFI directly (not using rEFInd) Windows boots perfectly fine, without BitLocker complaining on anything. So it seems rEFInd is causing the issue.

I'm not sure if NVRAM modification is at fault here. In my refind.conf I have use_nvram false , which in my understanding disables modification of NVRAM, but I'm still getting the problem.

My only clue so far is the UEFI boot entry for Windows, which lists some additional parameters including BCDOBJECT:

$ efibootmgr -v
(...)
Boot0000* Windows Boot Manager  HD(1,GPT,50e6f6b2-2bf2-41e5-9fd2-26adaf4dfd4e,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...4................
(...)

On the other hand my Windows boot stanza in refind.conf doesn't include those parameters:

menuentry "Windows 10" {
  loader \EFI\Microsoft\Boot\bootmgfw.efi
}

Maybe lack of those parameters is causing the problem? I still don't know how to properly add them though.

Update

No, it's a matter of those additional parameters. Maybe the problem is not even unique to rEFInd. I created some additional UEFI boot entries:

Boot0000* Windows Boot Manager  HD(1,GPT,50e6f6b2-2bf2-41e5-9fd2-26adaf4dfd4e,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...4................
Boot0001  rEFInd Boot Manager (direct)  HD(1,GPT,50e6f6b2-2bf2-41e5-9fd2-26adaf4dfd4e,0x800,0x82000)/File(\EFI\refind\grubx64.efi)
Boot0002* rEFInd Boot Manager   HD(1,GPT,50e6f6b2-2bf2-41e5-9fd2-26adaf4dfd4e,0x800,0x82000)/File(\EFI\refind\shimx64.efi)
Boot0004* Windows (parameterless)   HD(1,GPT,50e6f6b2-2bf2-41e5-9fd2-26adaf4dfd4e,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0005* Windows (PreLoader)   HD(1,GPT,50e6f6b2-2bf2-41e5-9fd2-26adaf4dfd4e,0x800,0x82000)/File(\EFI\Microsoft\Boot\PreLoader.efi)
Boot0006* Windows (Shim)    HD(1,GPT,50e6f6b2-2bf2-41e5-9fd2-26adaf4dfd4e,0x800,0x82000)/File(\EFI\Microsoft\Boot\shimx64.efi)

Both 0000 and 0004 entries boot Windows successfully. That shows it's not about the additional parameters, as 0004 doesn't have them, yet boots Windows without problems.

Then 0005 and 0006 run Windows UEFI executable (bootmgfw.efi) directly (without running rEFInd) but using PreLoader and Shim. Neither of those work - they result in blue recovery screen for BitLocker exactly the same as booting from rEFInd. That seems to show that it's not rEFInd that does something that Windows doesn't like, but that running bootmgfw.efi in any way other than running it directly by UEFI is illegal from perspective of Windows.

I also tried booting Windows using systemd-boot and it resulted in the same BItLocker violation error. So the problem is not in any way unique to rEFInd, but to booting BitLocker encypted Windows partition from any boot loader in general.

[Roderick W. Smith]

You might try activating the option to boot via a firmware boot entry, as described here:

https://www.rodsbooks.com/refind/configfile.html#bootnext

With that option enabled, you'll see new boot option(s) corresponding to the Boot#### entries shown by efibootmgr, or you can define just the option(s) you need via a manual boot stanza. Either way, when you select one, rEFInd will configure the EFI to boot using the one you pick and then reboot. If BitLocker is, as you suspect, freaking out because another program ran prior to the Windows boot loader, then this should work around that issue. It has the drawback that it will increase boot time, though.

[Robert K.]

Thanks for that workaround. But ideally I'd like to have dual-boot working without any workarounds, booting both Arch and Windows straight from rEFInd. I'm still not sure if it's possible, but neither I'm sure it's impossible.

[Robert K.]

I was able to discover that the root of the problem is that Windows cannot establish PCR7 binding when booting from rEFInd or other non-Windows boot loader. It has something to do with Trusted Platform Module (TPM). That lack of PCR7 binding causes BitLocker encryption features to be disabled. I'm still working on how to fix that.

Does anyone here know how to make PCR7/TPM work on Windows when booting Windows from rEFInd?

EDIT: This StackOverflow answer describes the problem in-detail. Unfortunately it seems it might be impossible to make BitLocker work with rEFInd, or with any other boot manager. The suggestion @srs5694 mentioned on using firmware boot entry might be the only solution here. I've eventually decided to use that solution and it works well for me.

[Roderick W. Smith]

Thanks for tracking down the cause of this. I've added information on it to the rEFInd documentation. It's not "live" yet on the main rEFInd page, but is in the git repository:

https://sourceforge.net/p/refind/code/ci/master/tree/docs/refind/configfile.html

[Robert K.]

And thank you for all your help.