[solved] Secure Boot disabled: Asus Tuf Gaming motherboard

[kwesadilo]

I recently installed Gentoo on a new amd64 system. Since I apparently have nothing better to do, I've made a number of non-default choices, for fun.

• I have a Ryzen 5 7600X and an Asus AMD B650E motherboard. I'm not sure what hardware details will ultimately be relevant here.
• Profile default/linux/amd64/23.0/hardened/selinux
• Rootfs on ZFS, with a single pool spread across 2 SSDs in RAID-Z1
• Redundant EFI System Partitions on each of the SSDs. Within Linux, I mirror them using mdraid.
• I'm using the distribution kernel and creating a UKI using dracut. I have USE="secureboot modules-sign" enabled globally.

I went through the handbook with some ZFS side quests. At the moment, the things listed above appear to work or at least not interfere with booting. SELinux is disabled by default. I'm mounting my ZFS rootfs from initramfs, which I set up with dracut. When I install kernels to the mirrored ESP, I can boot into them.

I've been trying to get SecureBoot to work for the first time, off and on for a couple weeks.

• SecureBoot is enabled in my firmware and set to "other OS" mode. I can see the certs that I've installed from within Linux listed in the firmware UI.
• I initially installed gentoo-kernel-bin and followed the Secure Boot wiki page, somehow missing the pointer to sbctl and creating and installing a bunch of certificates manually. I've since switched to sbctl, but just so you know, I've been messing around for a while and may very well have broken something.
• Believing that I had done this correctly and still seeing "Secure Boot disabled" in dmesg, I thought that what I was missing was module signing. I went through a few iterations here before switching to gentoo-kernel and creating a key for this purpose roughly as described on the wiki. Having done this, I see that key loaded into /proc/keys and listed as the signer for each loaded module. I do not see unsigned modules as a taint reason in /proc/sys/kernel/tainted. I believe that module signature verification is working as intended.
• When this was insufficient, I kept looking around and discovered sbctl. I then walked through the sbctl process, which I think is substantially similar to what I was initially doing, hopefully with fewer mistakes. I can run sbctl verify, and it will show that BOOTX64.EFI and the kernel I'm going to boot are signed.
• That still didn't change the results. My SECUREBOOT_SIGN_KEY and SECUREBOOT_SIGN_CERT are pointed at the db key and cert generated by sbctl, so I expected that rerunning emerge --config gentoo-kernel would produce signed images. However, after running this command, sbctl verify says that the resulting .efi files are not signed.
• I have not tried to get Shim working yet, because I'd prefer not to install one more blob and because I didn't think what I've done so far would take this long. If installing my own keys proves intractable, I'm open to trying Shim.

Current status:

• ESP_PATH=/efi sbctl verify shows all files in /efi are signed.

• Code: Select all

  $ sbctl status
  Installed: sbctl is installed
  Owner GUID: ...
  Setup Mode: Disabled
  Secure Boot: Disabled
  Vendor Keys: microsoft

• dmesg and bootctl concur that Secure Boot is disabled.

I've now followed all of the instructions I'm aware of, and I'm not sure where to turn to debug this. I can see what I think is a log of the SecureBoot process in /sys/kernel/security/tpm0/binary_bios_measurements, but I haven't found enough documentation to be sure about that or tell where things went wrong. I can see that some of the events correspond to files in my boot chain.

Any idea what I'm doing wrong here? Is there a way to get more visibility into this process?

tl;dr: I followed the instructions to enable SecureBoot, but it's still disabled, and I can't tell why.

Solved: The firmware only enables Secure Boot when "OS Type" is set to "Windows UEFI Mode." To enable Secure Boot with custom keys, you need to

1. Set OS Type to Windows UEFI Mode and Secure Boot Mode to Custom
2. Clear the keys from the firmware UI to put Secure Boot in setup mode
3. Boot Linux and go through the sbctl setup process
4. Reboot

[pietinger]

What happens if you go into your UEFI (BIOS) settings and enable Secureboot there?

(I am using also SecureBoot for my manually configured kernel; I did all manually with "sbsign" => viewtopic-p-8492354.html#8492354 )

[kwesadilo]

That's an excellent question. The settings provided by my UEFI (PDF) are a bit unclear.

There is a "Secure Boot state" line that is not editable. It says either "User" or "Setup." Deleting the PK puts the Secure Boot state into Setup. After loading a PK, it returns to User.

The two main choices are "OS Type: Windows UEFI Mode/Other OS" and "Secure Boot Mode: Standard/Custom."

Setting Windows UEFI Mode will trigger an impassible SecureBoot failure at the firmware level, before entering Linux. This will also set Secure Boot Mode to Standard.

With Other OS set, I need to set Secure Boot Mode to Custom to open the Key Management menu, from which I can add or delete the PK/KEK/db/dbx.

Switching from Custom back to Standard just now appears to have replaced my enrolled keys with the default MS/Asus keys.

Based on the above, I think SecureBoot was enabled at the time of my first post, or at least as enabled as it can be for Linux on this firmware. I don't see an obvious way to disable it. After sbctl enroll-keys, the firmware lists the Secure Boot state as User, which I believe is the intended state. From what I can see, to set up SecureBoot the non-Shim way, I need to set Other OS/Custom.

I'll look through your guide and see if I missed anything. Thank you very much for your help.

[pietinger]

Hmm ... I have a Gigabyte Mobo ... and yes, I must set "Other OS" + "Custom" ... "setup mode" for deleting the old keys and adding my own ... then after a 2nd reboot it is is "user mode" (I dont know why I needed 2 reboots).

[...] Thank you very much for your help.

You are very Welcome!

[kwesadilo]

I got this working, and it was deceptively simple.

I found an FAQ from Asus that describes the firmware UI in more detail. The table at the bottom shows the SecureBoot state in each combination of OS Type and Secure Boot mode. Unintuitively, Secure Boot is only enabled when OS Type is set to Windows UEFI Mode. The UI says that Windows UEFI Mode can only boot Windows.

Setting Other OS disables Secure Boot, but when you select this, the UI says the Secure Boot state is User or Setup, depending on the PK cert.

Secure Boot Mode set to Standard Mode vs Custom just controls whether it uses the certs that were built in vs user-supplied certs. You have to set Custom to allow you to clear the PK cert, which will put Secure Boot in Setup until you set another PK somehow.

Therefore, the settings I needed were Windows UEFI Mode and Custom. I mentioned that this previously prevented me from booting anything. When I double-checked my setup, I noticed that my most recent kernel image was not signed with my db key. I haven't integrated signing with these keys into my kernel install yet. I suspect that I rebuilt my latest kernel image for some reason and then forgot to sign the new one.

Once I signed my latest kernel image with sbctl sign-all and rebooted with Windows UEFI Mode set in the firmware UI, I was able to see Secure Boot enabled in sbctl status and dmesg.

NB: While researching this, I found a pretty expansive guide to setting up measured boot on Gentoo, which requires Secure Boot as a prerequisite. An event based on this material is currently advertised at the top of the forum, but I had to dig a little to find it after the fact. It didn't help me much with this problem, but I suspect it will be useful down the road.

[pietinger]

kwesadilo,

thank you very much for your report; it will certainly help other ASUS users, and also users who are looking for @duxco's guide.

[kwesadilo]

I'll be pleased if this helps someone else get here in fewer steps.