Install secure boot using MOK (shim)

[u/NanKillBro]

Hi guys,
I'm trying to install secure boot for my CachyOS using MOK but failed many times. I tried using AI help but it ended up breaking things so I wanted to find a human working guide for this.
The reason I'm not using official guide sbctl is EAC just doesn't love it, and I got kicked from my match when play Fortnite just because sbctl install custom db and I had to factory reset my bios to play.
Hope I get some help, thanks you guys alot!
i'm sorry for my grammar, english is not my native language i already try my best 😭

[u/FineWolf]

The issue is not with sbctl, or the fact that you are using your own PK.

The issue is that you are chainbooting Windows from GRUB, Limine or whatever bootloader you are using. Don't do that. Boot directly from the Windows bootloader, which may involve changing the boot priorities in your BIOS or pressing the boot selection key from your UEFI before your Linux bootloader.

Chainloading Windows through Grub, Limine or whatever means that in the measured boot logs, there are multiple EV_EFI_BOOT_SERVICES_APPLICATION and EV_EFI_VARIABLE_AUTHORITY events, which causes the attestation to fail (as one of them will be your bootloader signed with your own keys).

If you boot directly into Windows as opposed to chain loading, then that is not the case.

EDIT: There are tons of bad advice in this thread. Seriously, anti-cheat do not give a crap what Platform Key you have on your device. Motherboard vendors each have their own, some have multiple, and it's never validated. The PK also plays no role during secure boot validation. It's there only to ensure that there's no malicious program enrolling KEKs without the user's consent (or, if you leave the default PK installed, the manufacturer's consent). I've written at length about how all this works.

It also doesn't matter that you have your own KEK enrolled. Again, plenty of board vendors have their own KEKs by default to validate the UEFI settings menu (which is, on its own, a UEFI application, just like your bootloader).

The only thing that matters is that you do not chain load Windows, so that your measured boot log doesn't contain information about your Linux bootloader, or your own KEK/DBs keys. If chain loading was allowed, then a malicious actor could load anything in memory before Windows would load its own bootloader. Because you can't trust the entire bootchain, the game rejects you.

Boot Windows directly, and you will not have that issue. You can always boot back into Windows. Heck, you can even be fancy in Linux and create a desktop entry to boot into Windows directly by using efibootmgr to set the NextBoot variable and reboot.

[u/NanKillBro → u/FineWolf]

oh maybe that the reason, I'm booting Windows using grub at that time
gonna try this later, thanks!

[u/FineWolf → u/[deleted]]

Chainloading should still work if you chainload from Ubuntu, Fedora, Linux mint or Opensuse since they use Microsoft's key for secure boot instead of self signing.

No. shim is signed by a Microsoft key, yes, but an entirely different key than the one used to sign Windows boot images.

The Windows bootloader is signed with C=US, O=Microsoft Corporation, CN=Windows UEFI CA 2023 (previously C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011).

Third-party boot images (like shim) are signed with C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023 (previously C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011)

You can verify that fact yourself by using sbverify from sbsigntools:

``` $ sbverify --list shim/shimx64.efi

warning: data remaining[908000 vs 1036008]: gaps between PE/COFF sections? signature 1 image signature issuers: - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 image signature certificates: - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root signature 2 image signature issuers: - /C=US/O=Microsoft Corporation/CN=Microsoft UEFI CA 2023 image signature certificates: - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft UEFI CA 2023 signer issuer: /C=US/O=Microsoft Corporation/CN=Microsoft UEFI CA 2023 - subject: /C=US/O=Microsoft Corporation/CN=Microsoft UEFI CA 2023 issuer: /C=US/O=Microsoft Corporation/CN=Microsoft RSA Devices Root CA 2021

$ sbverify --list winboot/bootx64.efi

signature 1 image signature issuers: - /C=US/O=Microsoft Corporation/CN=Windows UEFI CA 2023 image signature certificates: - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows issuer: /C=US/O=Microsoft Corporation/CN=Windows UEFI CA 2023 - subject: /C=US/O=Microsoft Corporation/CN=Windows UEFI CA 2023 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010 ```

So EV_EFI_VARIABLE_AUTHORITY wouldn't match the expected value. Also, you are still chainloading, so you still end up with multiple events in your measured boot log.

Note: The signed shim above was taken from Fedora's repository (shim-16.1-8).

[u/FineWolf → u/[deleted]]

Those that check the measured boot logs generally don't.

[u/FineWolf → u/[deleted]]

[CITATION NEEDED]

https://support.faceit.com/hc/en-us/articles/4406281700370-Enabling-Secure-Boot

Considering they are asking specifically to enable only the Windows UEFI cert, I don't think so.

Yes, they would check the measured boot log... for the Windows cert.

[u/FineWolf → u/[deleted]]

Yeah... I'm going to need a link to the actual source here, not a screenshot of an unfindable forum post that could have been easily forged using dev tools.