How to enable secure boot?

Issues & Assistance
1

Hi all, I really like the look and feel of Garuda so a big thanks to the maintainer team.

I am hoping someone can help me with getting secure boot setup with a single boot setup with only Garuda linux. I am not wanting to make it work for windows, but because of something I came across on the arch-wiki saying that evil maid attacks are possible even with a full disk encryption (dm-crypt/Encrypting an entire system - ArchWiki) since the /boot/efi partition cannot be encrypted.

I tried looking into existing guides and the wiki to get secure boot going with grub (GRUB - ArchWiki), but I cannot get it to work and I suspect it is because I am not loading in the correct modules (other than tpm). I tried the following command:

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=garuda --modules=“tpm” --disable-shim-lock

Eventually I gave up and went with a fresh install of plain Arch and was able to get it working with systemd-boot instead of grub. I would not mind giving up the snap shot functionality, because I have my own backups, so if I can change the bootloader on Garuda to use systemd-boot that would be great too.

Overall, it would be great if someone can help me with any one of the following setups:

  • Changing Garuda’s bootloader to systemd-boot (and sacrificing the benefits of a grub bootloader).
  • Enabling secure boot on Garuda with a grub bootloader (finding what other modules must be passed to grub-install).
  • Applying Garuda’s look and feel to a plain arch install (if all else fails).

Anyways, thank you for your time.

by the way, here is a few other resources I tried:
It is posible to use Secure Boot in dual boot out of the box? - Issues & Assistance / Unsupported hardware | Dual boot - Garuda Linux Forum
Secure Boot Setup | CachyOS
Secureboot - Issues & Assistance - Garuda Linux Forum

2

That looks right, but this command is only one part of it.

Are you using sbctl? It makes the process much easier. Just follow the instructions from this post: Secureboot - #3 by stefanwimmer128

Don’t forget to boot into your BIOS and put the device in setup mode before you start the enrollment process.

1 Like
3

Thanks for your quick reply. Yes, I followed the same guide too but could not link more than five sources unfortunately. I used sbctlto generate and enroll the keys, and sign and verify the files, but when I re-enable the secure boot option in the BIOS, the system drops to grub rescue. Do you have any other suggestions to overcome that?

The only way I was able to enable the secure boot fully was with a plain arch install and systemd-boot, systemd-sbsign, and bootctl.

Oh also, if I recall right, on the Garuda install, bootctl would still show /efi/boot/... under the Available Boot Loaders on ESP: section instead of the newly installed /efi/garuda/... with the grub-install command. Could that be the issue?

4

It is easier with systemd-boot because the kernels are stored on the EFI partition where sbctl is able to automatically find them. When the kernels are stored on a separate partition (as they are with Garuda Linux), you need to identify the kernels and explicitly sign them.

That’s where this command comes in to play:

Alternately, you can sign the kernels one by one with sbctl sign /path/to/kernel.

After signing the kernels, when you run sbctl list-files it should show both the bootable .efi files on the ESP (which sbctl is able to find automatically), and the kernels in /boot (which you just explicitly signed).

No, that is not an issue. Probably you are looking at something like this:

Available Boot Loaders on ESP:
          ESP: /boot/efi (/dev/disk/by-partuuid/cae9a5da-1c50-4f20-99f2-63f46ec756c9)
         File: └─/EFI/BOOT/bootx64.efi

That is the fallback UEFI bootloader path. Your UEFI firmware will attempt to use that bootloader if no other bootable options are configured. It is not related to your GRUB installation.

1 Like
5

Okay some good news for me and for whoever else might stumble on this thread. But first:

Yes, I did try signing everything like that but unfortunately grub still failed.

That is good to know, thank you for your explanation.

Now the good news. I ditched grub and switched to systemd-boot. I took a look around the Garuda GitLab repos and was happy to find this option is available to make a custom iso. I cloned the Garuda Linux :eagle: / Tools / buildiso-docker · GitLab repo, then ran the run command (customize first as desired). Once dropped in the container shell, using another terminal edit the file found at REPO//iso-profiles/garuda/mokka/profile.conf and change line 13 to efi_boot_loader=“systemd-boot”. Then in the container bash terminal, run buildiso -p mokka and wait for the magic to happen. Then install the output iso normally.

Once the install is complete, it is very trivial to set up secure boot using the steps found at Unified Extensible Firmware Interface/Secure Boot - ArchWiki.

As a side note, the hibernation now works flawlessly since there is no password prompt and grub boot loader to mess with (in the past I could not get the thing to work as seamlessly as windows would, but no more).

Hope this helps anyone else in the same boat as me.

Though I still have a question about this setup. It appears that the luks password was automagically enrolled with TPM during the installation phase so I am not even prompted for it upon system boot. I did verify that the drive was in fact encrypted in a live boot media. Is my understanding correct that TPM now only releases the decryption key if secure boot passes? Or did I introduce a big security flaw somewhere somehow?

6

Most likely the kernels were not signed, however we won’t be able to help figure out what went wrong without seeing the terminal output from your enrollment effort.

I’m not sure that is good news; it sounds like you have lost the trail a bit. It is definitely not necessary for enabling secure boot, and now you have lost the ability to boot to Btrfs snapshots which is considered a cornerstone feature of Garuda Linux. But all the same, if you are happy with that then it’s all good.

There is a keyfile embedded in the initramfs, to prevent having to enter your passphrase twice. dm-crypt/Encrypting an entire system - ArchWiki

When you are using GRUB with FDE, the initramfs is stored on an encrypted partition and you unlock it from GRUB, then the initramfs uses the keyfile to unlock the disk. Now that you have moved the initrds to an unencrypted partition (the ESP), the keyfile can be accessed without taking any action.

No, TPM is not related to this in any way. Nor is secure boot.

Yes, there is a keyfile for unlocking your LUKS device stored on an unencrypted partition. This is a major security flaw. Anyone with access to the disk can unlock the LUKS device with the keyfile. You have essentially locked the front door to your home but left the key in the doorknob.

If you want to use systemd-boot and unlock the device manually during the initramfs stage, you should remove the keyfile from your dracut config and regenerate the initrds, then delete the keyfile altogether.

2 Likes
7

Ugh that was a true :person_facepalming:moment there and I though I was onto something… Learning a lot though so that’s good at least. I will defer to your judgement if you feel it is better to delete my earlier post as to not have incorrect info here.

I did a fresh install of Garuda Mokka (latest iso dated 250801) and here is what I did

Commands and terminal outputs

Fresh Garuda Mokka install:

 ╭─root@arch in /home/user as 🧙
 ╰─λ bootctl
systemd-boot not installed in ESP.
System:
      Firmware: n/a (n/a)
 Firmware Arch: x64
   Secure Boot: disabled (setup)
  TPM2 Support: yes
  Measured UKI: no
  Boot into FW: supported

Current Boot Loader:
      Product: GRUB 2.13
     Features: âś— Boot counting
               âś— Menu timeout control
               âś— One-shot menu timeout control
               âś— Default entry control
               âś— One-shot entry control
               âś— Support for XBOOTLDR partition
               âś— Support for passing random seed to OS
               âś— Load drop-in drivers
               âś— Support Type #1 sort-key field
               âś— Support @saved pseudo-entry
               âś— Support Type #1 devicetree field
               âś— Enroll SecureBoot keys
               âś— Retain SHIM protocols
               âś— Menu can be disabled
               âś— Multi-Profile UKIs are supported
               âś“ Boot loader set partition information
    Partition: /dev/disk/by-partuuid/007d8b81-1986-4730-baf4-99b7b2ab4c59

Random Seed:
 System Token: set
       Exists: no

Available Boot Loaders on ESP:
          ESP: /boot/efi (/dev/disk/by-partuuid/007d8b81-1986-4730-baf4-99b7b2ab4c59)
         File: └─/EFI/BOOT/bootx64.efi

Boot Loaders Listed in EFI Variables:
        Title: UEFI OS
           ID: 0x0006
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/007d8b81-1986-4730-baf4-99b7b2ab4c59
         File: └─/EFI/BOOT/BOOTX64.EFI

        Title: Garuda
           ID: 0x0000
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/007d8b81-1986-4730-baf4-99b7b2ab4c59
         File: └─/EFI/GARUDA/GRUBX64.EFI

Boot Loader Entries:
        $BOOT: /boot/efi (/dev/disk/by-partuuid/007d8b81-1986-4730-baf4-99b7b2ab4c59)
        token: garuda

0 entries, no entry could be determined as default.
 
 ╭─root@arch in /home/user as 🧙 took 0s
 ╰─λ sudo grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/catppuccin-mocha/theme.txt
Found linux image: /boot/vmlinuz-linux-zen
Found initrd image: /boot/initramfs-linux-zen.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Adding boot menu entry for UEFI Firmware Settings ...
Detecting snapshots ...
Found snapshot: [DELETED]
Found snapshot: [DELETED]
Found 2 snapshot(s)
Unmount /tmp/grub-btrfs.d86UoxsPsY .. Success
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done

 ╭─root@arch in /home/user as 🧙 took 17s
 ╰─λ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=garuda --modules="tpm" --disable-shim-lock
Installing for x86_64-efi platform.
Installation finished. No error reported.

 ╭─root@arch in /home/user as 🧙 took 0s
 ╰─λ sbctl create-keys
Created Owner UUID 4d985054-41c4-40d3-bd7e-80b74ab2b8c4
Creating secure boot keys...âś“
Secure boot keys created!

 ╭─root@arch in /home/user as 🧙 took 4s
 ╰─λ sbctl enroll-keys -m -f

Enrolling keys to EFI variables...
With vendor keys from microsoft...
With vendor certificates built into the firmware...âś“
Enrolled keys to the EFI variables!

 ╭─root@arch in /home/user as 🧙 took 0s
 ╰─λ sbctl verify
Verifying file database and EFI images in /boot/efi...
âś— /boot/efi/EFI/Garuda/grubx64.efi is not signed
âś— /boot/efi/EFI/boot/bootx64.efi is not signed

 ╭─root@arch in /home/user as 🧙 took 0s
 ╰─λ sbctl verify | sed 's/^✗ \(.*\) is not signed$/sbctl sign -s \1/e'

Verifying file database and EFI images in /boot/efi...
âś“ Signed /boot/efi/EFI/Garuda/grubx64.efi
âś“ Signed /boot/efi/EFI/boot/bootx64.efi

 ╭─root@arch in /home/user as 🧙 took 0s
 ╰─λ find /boot/vmlinuz-*
/boot/vmlinuz-linux-zen

 ╭─root@arch in /home/user as 🧙 took 0s
 ╰─λ find /boot/vmlinuz-* | xargs -n1 sbctl sign -s

âś“ Signed /boot/vmlinuz-linux-zen

After reboot

 user@arch in ~ as 🧙
 󰛓 ❯ sudo sbctl status
Installed:      âś“ sbctl is installed
Owner GUID:     4d985054-41c4-40d3-bd7e-80b74ab2b8c4
Setup Mode:     âś“ Disabled
Secure Boot:    âś— Disabled
Vendor Keys:    microsoft builtin-KEK
Firmware:       ‼ Your firmware has known quirks
                - FQ0001: Defaults to executing on Secure Boot policy violation (CRITICAL)
                  https://github.com/Foxboron/sbctl/wiki/FQ0001

After another reboot and enabling secure boot:

Detected ATA/ATAP1 Devices...

error: prohibited by secure boot policy.
Entering rescue mode...
grub rescue>

Does anything stand out as wrong to you?

8

The commands look good, and I can confirm that secure boot works for me with grub using those commands.

The only thing I noticed is, that your fallback bootloader (/EFI/BOOT/bootx64.efi) is listed in the EFI Variables section as well, where for me it is only listed in the on-ESP section. So can you make sure, that you’re booting with the actual garuda bootloader (/EFI/GARUDA/GRUBX64.EFI) not the fallback one. This can most likely be done by looking at the boot order in UEFI and changing it if required.

1 Like
9

The only mistake I see is the GRUB commands are in the wrong order. You should first install GRUB, then update the GRUB configuration file. But I don’t think that is the cause of your issue.

It’s possible this is the smoking gun:

I read through some of the related discussion here: MSI has very insecure Secure Boot defaults · Foxboron/sbctl · Discussion #322 · GitHub. I think “known quirks” is a very diplomatic way of putting it; the truth of the matter is the secure boot implementation for this firmware is kind of broken.


dawidpotocki
 Jan 20, 2023

Author

[…]

They have made this change to bypass Windows 11 requirements of having Secure Boot enabled during install, not to make Linux users happy as this setting actually breaks GRUB.

I would recommend configuring your firmware secure boot settings according to the sbctl wiki page to see if you get a different result: FQ0001 · Foxboron/sbctl Wiki · GitHub

Solution

Go to firmware setup by using systemctl reboot --firmware-setup or by pressing an appropriate key for your device (e.g. Delete) during boot.

Depending on your motherboard, Secure Boot settings can be in one of these places:

  • Settings\Advanced\Windows OS Configuration\Secure Boot
  • Security\Secure Boot

Change “Secure Boot Mode” to “Custom”.

Depending on your firmware version, you might see an option called either “Image Execution Policy” or “Secure Boot Preset”.

If you see “Image Execution Policy”, open it and change “Option ROM”, “Removable Media” and “Fixed Media” from “Always Execute” to “Deny Execute”.

If you see “Secure Boot Preset”, change it to “Maximum Security”.

1 Like
10

I suspected that could be the culprit, but unfortunately I moved on and did not get a chance to test it. Maybe someone else can do so and share their findings with us here.

I saw that too and essentially the default config of the motherboard renders secure boot useless. I changed the settings accordingly and the issue persisted. I tried the same install process on another motherboard that did not have that warning but the secure boot remained dysfunctional.

Now for round two. I did a bit more research and decided to switch over to systemd-boot because of my personal use case not requiring the btrfs snap shots. The upshot is that Luks2 can be used now (because I saw some references that mentioned issues with grub), and I managed to get secure boot, and tpm to work. Below is a summary of what I did. If anyone sees any glaring flaws in the approach, please let me know. Thanks for your time.

Install Process

Useful Commands

  • Test opening the root partition with TPM
sudo cryptsetup open --test-passphrase /dev/nvme0n1p2

Preparation

  • Custom iso build with systemd-boot instead of grub
  • Disable secure boot

Calamares

  • Enable swap
  • Enable full disk encryption
  • Default username/password awaiting ansible

Reboot to Live USB

  • Bump luks to luks2
sudo cryptsetup convert --type luks2 /dev/nvme0n1p2 

sudo cryptsetup convert --type luks2 /dev/nvme0n1p3

Reboot to Arch

  • Enable sshd
  • Run system ansible role
  • enable secure boot
sudo sbctl create-keys

sudo sbctl enroll-keys # -m

sudo sbctl verify | sudo sed -E 's|^.* (/.+) is not signed$|sbctl sign -s "\1"|e'

sudo sbctl status
  • Recreate initramfs
sudo dracut --regenerate-all -f

Reboot to UEFI

  • Enable secure boot, set boot order
sudo systemctl reboot --firmware-setup

Reboot

  • verify secure boot is enabled
sudo sbctl status
  • generate new key file
sudo openssl genrsa -out /crypt_key 4096
  • Add new luks key
sudo cryptsetup luksAddKey -d /crypto_keyfile.bin --new-key-slot 7 /dev/nvme0n1p2 /crypt_key

sudo cryptsetup luksAddKey -d /crypto_keyfile.bin --new-key-slot 7 /dev/nvme0n1p3 /crypt_key
  • kill old key file slot
sudo cryptsetup luksKillSlot /dev/nvme0n1p2 1 --key-file /crypt_key

sudo cryptsetup luksKillSlot /dev/nvme0n1p3 1 --key-file /crypt_key

sudo rm /crypto_keyfile.bin
  • Modify /etc/crypttab
sudo nvim /etc/crypttab
  • Replace last two arguments with
none tpm2-device=auto,tpm2-measure-pcr=yes
  • enroll file with TPM
sudo systemd-cryptenroll --wipe-slot tpm2 --tpm2-device=auto --tpm2-pcrs=1+3+5+7+11+12+14+15:sha256=0000000000000000000000000000000000000000000000000000000000000000 --unlock-key-file=/crypt_key /dev/nvme0n1p2

sudo systemd-cryptenroll --wipe-slot tpm2 --tpm2-device=auto --tpm2-pcrs=1+3+5+7+11+12+14+15:sha256=0000000000000000000000000000000000000000000000000000000000000000 --unlock-key-file=/crypt_key /dev/nvme0n1p3
  • make crypttab.initramfs
sudo cp /etc/crypttab /etc/crypttab.initramfs
  • remove last line (hibernate) - keep only root partition
sudo nvim /etc/crypttab.initramfs
  • Recreate initramfs
sudo dracut --regenerate-all -f
11

Hey @BluishHumility, any thoughts/input?

12

I’m not sure what you mean; I believe I have already shared my thoughts and input.

To summarize, I would say changing the bootloader is definitely not necessary for enabling secure boot. I would not recommend anyone change the bootloader unless they have other compelling reasons for doing it.

Here is an example of setting up secure boot on Garuda Linux I did just now on a test machine with a fresh installation:

❯ sbctl status
Installed:	âś— sbctl is not installed
Setup Mode:	âś— Enabled
Secure Boot:	âś— Disabled
Vendor Keys:	none

❯ grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=garuda --modules="tpm" --disable-shim-lock
Installing for x86_64-efi platform.
Installation finished. No error reported.

❯ update-grub
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/garuda/theme.txt
Found linux image: /boot/vmlinuz-linux-zen
Found initrd image: /boot/initramfs-linux-zen.img
Found fallback initrd image(s) in /boot:  initramfs-linux-zen-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Adding boot menu entry for UEFI Firmware Settings ...
Detecting snapshots ...
Found snapshot: 2025-08-23 21:35:52 | @/.snapshots/4/snapshot | post | sbctl                                                                    |
Found snapshot: 2025-08-23 21:35:51 | @/.snapshots/3/snapshot | pre  | pacman -S sbctl                                                          |
Found snapshot: 2025-08-23 21:33:37 | @/.snapshots/2/snapshot | post | 7zip aalib amd-ucode appstream at-spi2-core avahi bash bind binutils bot |
Found snapshot: 2025-08-23 21:32:26 | @/.snapshots/1/snapshot | pre  | pacman -Su                                                               |
Found 4 snapshot(s)
Unmount /tmp/grub-btrfs.j3r2oWGL7d .. Success
Found memtest86+ image: /boot/memtest86+/memtest.bin
done

❯ sbctl create-keys
Created Owner UUID 0f669aa1-b892-491a-99f7-85a41b66ee43
Creating secure boot keys...âś“ 
Secure boot keys created!

❯ sbctl enroll-keys -m -f
Enrolling keys to EFI variables...
With vendor keys from microsoft...
With vendor certificates built into the firmware...âś“ 
Enrolled keys to the EFI variables!

❯ sbctl verify | sed 's/^✗ \(.*\) is not signed$/sbctl sign -s \1/e'
Verifying file database and EFI images in /boot/efi...
âś“ Signed /boot/efi/EFI/Garuda/grubx64.efi
âś“ Signed /boot/efi/EFI/boot/bootx64.efi

❯ find /boot/vmlinuz-* | xargs -n1 sbctl sign -s
âś“ Signed /boot/vmlinuz-linux-zen

❯ reboot

After rebooting:

❯ sbctl status
Installed:	âś“ sbctl is installed
Owner GUID:	0f669aa1-b892-491a-99f7-85a41b66ee43
Setup Mode:	âś“ Disabled
Secure Boot:	âś“ Enabled
Vendor Keys:	microsoft builtin-db builtin-KEK

That’s all there is to it.

If it’s not working for you, double-check you are not booting an old/incorrect EFI variable (check efibootmgr), or making a mistake in the setup process somewhere.

1 Like
13

I was deferring to your expertise in case you spot another fundamental security flaw in my approach as you did earlier. Thank you for taking the time to review, and also do a test.

14

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.