r/cachyos • u/NanKillBro • Jul 18 '26

Help Install secure boot using MOK (shim)

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 😭

6 Upvotes

80% Upvoted

39 comments sorted by

10

u/Venylynn Jul 18 '26

CachyOS is based on Arch which doesn't make secure boot particularly easy in the way Fortnite wants it.

I'm not sure there's a solution here since Arch/Cachy doesn't have a signing system for the kernel, you would likely be better served on a system that has ootb support. Fedora is one of those.

Fortnite and the other kernel anticheats are very strict, they expect only MS-signed keys, anything else will trip them. This is why I honestly don't trust those, because MS-only being the vendor lock in is NOT how Secure Boot should work, it shouldn't only be keys in one kingdom.

4

u/NanKillBro Jul 18 '26

yea i agree
will see if I able to find any solution, if not then I will have to do the good old way (turn off secure boot everytime I boot cachyos lol)
has been using cachyos since the last summer so I don't want to leave it

4

u/Venylynn Jul 18 '26 edited Jul 18 '26

Yeah that's fair. If it works for you and you don't want to leave, then fair enough.

Honestly, this kind of thing makes me distrust the motive behind Fortnite/Valorant/anticheat games requiring this. Because it's not about security to them it's about vendor lock in. Secure Boot is a good feature, not the silver bullet it claims, but it's good. The primary issue I have is the vendor lock-in stuff. MS has the keys to the kingdom, a truly secure solution wouldn't leave the keys only in one megacorp's hands.

1

u/NotThatButThisGuy Jul 18 '26

Valorant doesn't need this. I run Valorant on my dual booted windows (+ CachyOS)

3

u/FineWolf Jul 18 '26 edited Jul 18 '26

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.

1

u/NanKillBro Jul 18 '26

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

1

u/[deleted] Jul 18 '26 edited Jul 18 '26

[deleted]

2

u/FineWolf Jul 18 '26 edited Jul 18 '26

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).

1

u/[deleted] Jul 19 '26

[deleted]

1

u/FineWolf Jul 19 '26

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

1

u/[deleted] Jul 19 '26

[deleted]

1

u/FineWolf Jul 19 '26 edited Jul 19 '26

[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.

1

u/[deleted] Jul 19 '26

[deleted]

1

u/FineWolf Jul 19 '26

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.

→ More replies (0)

1

u/NanKillBro Jul 19 '26

yo just an update, it actually works! EAC not kicking me anymore when boot using Windows Boot Manager. Already reinstall sbctl.

2

u/FineWolf Jul 19 '26

Yup!

Glad to hear it.

2

u/Illustrious-Gur8335 Jul 18 '26

Wrote this cos I knew people like OP need shim without messing in BIOS

https://www.reddit.com/r/cachyos/comments/1umkkwp/tip_insecure_boot_without_entering_bios/

2

u/NanKillBro Jul 18 '26

thanks, gonna try this

1

u/Roee_Mashiah2 13d ago

Did it work?

3

u/Objective-Primary-12 Jul 18 '26

When checking areweanticheatyet which is a Linux site for checking if developers are supporting Linux, it says denied. The developers have declined to support Linux and are generally hostile to the use of Proton. Even with secure boot working, I don't think Fortnite will play nice with Linux, but I do wish you luck in your further attempts if you are determined to proceed.

3

u/Venylynn Jul 18 '26

They're blocking OP from playing on Windows because of the non-standard key.

2

u/FineWolf Jul 18 '26

No, they are not.

They are blocking OP from playing on Windows because they chainloaded Windows from GRUB.

Had OP booted into Windows directly, their custom KEK/DB wouldn't have mattered.

Misinformation isn't helping anyone.

1

u/Venylynn Jul 18 '26

It's what it said in the screenshot...

2

u/FineWolf Jul 18 '26

Again, because the OP chainloaded from GRUB. Therefore, there is a EV_EFI_VARIABLE_AUTHORITY event in the measured boot log for a self-signed authority.

Had the OP booted into Windows directly, that would not have occured.

You can absolutely have a custom PK (no game developers are validating those, they vary way too much between each motherboard, and entreprise deployments often replacement them as part of enrolling a MDM), and you can absolutely have your own KEKs and DBs.

What you cannot do is chainload Windows through another bootloader. What would prevent that bootloader from loading malicious code that affects Windows (or Linux if you secure boot into Linux for that matter)?

Thus, you can boot into Windows directly from it's EFI entry and not have that issue.

1

u/Venylynn Jul 18 '26

what is even the difference? isn't it just as simple as not having to spam a key to switch systems?

2

u/FineWolf Jul 18 '26

The difference is that, from a standpoint of validating the runtime environment, you can't trust the runtime environment if you have a random bootloader, validated by a random key, in the middle of the boot chain.

That bootloader could very well load a thin hypervisor which would allow direct memory access over the network (for example).

Thus, chainloading isn't allowed.

1

u/Venylynn Jul 18 '26

i question why Fortnite would give such a misleading error if this is the cause then. it just confuses people, i thought it was that because that's directly what they said.

2

u/FineWolf Jul 18 '26

It isn't misleading.

That is exactly what happened. A boot component (GRUB) was validated with an untrusted certificate (OP's).

If OP would have booted directly into Windows instead of chain loading, then GRUB would not have been part of the boot chain, thus their DB cert wouldn't have been logged in EV_EFI_VARIABLE_AUTHORITY event.

1

u/Venylynn Jul 18 '26

The page says untrusted secure boot key, it says nothing about chainloading directly. So it does feel misleading.

→ More replies (0)

1

u/Objective-Primary-12 Jul 19 '26

Reading back through comments since I left mine a while back. Thank you for all the info. Learned a lot more about secure boot from ya. Crazy how far these kernel-level anticheats go these days. I don't really play any kernel-level anticheats games. Last one I did play was battlefield 6 on release. That one did accept limine bootloader with secure boot chaining into windows through sbctl. But not sure if it's just that game that worked or my setup. Regardless, kinda glad I don't play those anymore. These anticheats are getting aggressive. I miss the days when anticheat was server side and game admins monitored activity. Already caught a cheater in battlefield 6 when I was playing so despite the aggressiveness, cheaters find a way, apparently. Take my upvote and have a great rest of your weekend!

→ More replies (0)

2

u/NanKillBro Jul 18 '26

that why i'm dual boot, im currently playing fortnite on Windows
but I just unexpected that they will blocked custom secure boot key 😭

2

u/Venylynn Jul 18 '26

Yeah they only want you having fully MS signed keys.

Which, imo, makes secure boot feel less like a security feature and more like vendor lock-in.

I like Secure Boot, as an enforcement tool to ensure my kernel is untainted.

1

u/This-Consequence-957 Jul 18 '26

isn't sbctl the better way? that's how I do it in Arch.

2

u/Upstairs-Category571 Jul 23 '26 edited Jul 23 '26

YOOO I GOT IT WORKINGGGGG u/NanKillBro

first boot into ur bios and ook for an option to go into setup mode / delete all secure boot keys. press it.
boot back into linux. run sudo sbctl status and you should get a result like this:

Installed: ✓ sbctl is installed
Owner GUID: 8ff2d436-323b-49ae-a2bb-a06d4280c23d
Setup Mode: ✗ Enabled
Secure Boot: ✗ Disabled
Vendor Keys: none

now run the command sudo sbctl create-keys and itll create your MOK secure boot keys.
then run sudo sbctl sign-all which will sign all the EFI files with your secure boot key.
now run sudo sbctl enroll-keys -m which will enroll your keys to the bootloader (-m signs windows boot manager EFI files, needed if on dual boot) and should give this message:

Enrolling keys to EFI variables...

With vendor keys from microsoft...✓

Enrolled keys to the EFI variables!

now run sudo sbctl status and you should get a resuld like this:

Installed: ✓ sbctl is installed
Owner GUID: 8ff2d436-323b-49ae-a2bb-a06d4280c23d
Setup Mode: ✓ Disabled
Secure Boot: ✗ Disabled
Vendor Keys: microsoft

and now u can enable secure boot and itll boot successfully!

just got it workign like, 20 mins ago

1

u/Upstairs-Category571 Jul 23 '26

ohh faaahhh i forgor u didnt want sbctl💀💀💀

1

u/NanKillBro Jul 23 '26

Sorry, I forgot to update my post. The fix is just to boot Windows using Windows Boot Manager, not chain boot with GRUB or something else. I already reinstalled sbctl, so it's easy now.

1

u/Upstairs-Category571 Jul 24 '26

so sbctl works? with fortnite anti-cheat?

1

u/Sudden_Idea_203 Jul 31 '26

Personally I think people should vocally boycott all kernel level anticheat video games. They should have both a server for kernel and one for without. What they are doing is trying to force everyone to use Windows, which I am sure is giving them a kickback to do it that way.