Secure Boot Guide

Issues & Assistance Unsupported hardware | Dual boot
,
1

I thought this handy information should be included in the Garuda doc/wiki to make it easier for folks to find and setup Secure Boot. Arch Linux which Garuda is based on, supports Secure Boot, but is disabled by default and is installed with shim (generic) certificates.

= /\ = This is for a standard Garuda installation with GRUB = /\ =

To dual boot with Secure Boot enabled, follow the instructions outlined to install Microsoft’s signed keys and sign your kernel image(s). The ‘esp’ directory should point to your system’s EFI’s folder and in a standard Garuda installation, this would be /boot/efi.

Enter UEFI and place your Secure Boot to setup mode. This is commonly done by clearing the installed keys in your system.

–Replace shim with Microsoft’s CA certificates using self-signed keys to sign all images with:
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=garuda --modules="tpm" --disable-shim-lock

–Install sbctl using pacman and verify that it is in setup mode:
sbctl status

–Regenerate your grub configuration:
sudo grub-mkconfig -o /boot/grub/grub.cfg

–Create your custom secure boot keys:
sudo sbctl create-keys

–Enroll your custom keys (-m is required to include Microsoft’s CA certificates, -f will retain firmware builtins):
sudo sbctl enroll-keys -m -f

–Verify that your keys have successfully been enrolled:
sbctl status

–Check which files need to be signed for secure boot to work:
sudo sbctl verify

–Sign all unsigned files (this string will search for all images installed and sign the relevant images):
sbctl verify | sed 's/✗ /sbctl sign -s /e'

–sbctl can miss Linux images due to their install location, to ensure these images aren’t skipped:
find /boot/vmlinuz-* | xargs -n1 sbctl sign -s

–You may get an error because of an issue with certain files being immutable. To make those files mutable, run the following command for each file then re-sign afterwards:
sudo chattr -i /sys/firmware/efi/efivars/<filename>

–Verify that everything has been signed:
sudo sbctl verify

–To automate resigning of keys after a system update if using systemd-boot, add this pacman hook:
sudo sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

–Reboot, in some cases you may need to manually re-enable Secure Boot, to verify that you are in Secure Boot after booting:
sbctl status

Credits

2 Likes
2

One point of clarification you don’t use Microsoft’s key to sign your images you
create your own key, install it in your system and sign all the images with it.

The bootloader id on Garuda is “garuda” thus the command should be:

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

Make sure the Linux images are also signed here. sbctl can miss those since they are not located on the boot partition /boot/efi but in /boot:

find /boot/vmlinuz-* | xargs -n1 sbctl sign -s

I also recommend adding the -f flag to keep all firmware builtins:

sudo sbctl enroll-keys -m -f

sbctl automatically adds the pacman hook to resign all boot images on update. This additional step is only required with systemd-boot, while Garuda uses GRUB by default.

6 Likes
3

A post was split to a new topic: Can I have problems with Windows Updates

4

thank you for your response, I’d edit my post to reflect your suggestions but seem locked out from editing anymore.

5

Try again :slight_smile:

1 Like
6

thank you, edited for clarification

7

Is there a simplified procedure to secure boots on single-boot Garuda systems?

I even was running hardened LTS Garuda but it looks like the machine (bios) got hijacked by a variant of bootkitty exploit. That machine was already half battered so I didn’t even bother trying to recover it, but I would like to do better to prevent it happening again.

8

What are the symptoms or actions you have taken that make you believe that? Just curious what it could look like in the wild.

1 Like
9

I was using the machine (very old Lenovo laptop) as usual as had been done for many years all running Garuda Dragonized with KDE - the only variation somewhat atypical is that i had a second screen attached via VGA.

Then I was trying to reply to a post by a certain shadow banned news group on Twitter, so I had to click on the post and reply, and got a memory freeze that could not back out of with Ctrl-C etc. So then trying to power off-on, boot loading was gone, and a splash screen for a different fake recovery bios that was like from 1990 or such with only two menu options looking for an OS source appeared. So then I knew that the boot loader got infected.

I could have gotten further into it but that laptop already had a burned out keyboard, and my DDR had arrived for running my other old laptops so I decided not to even waste any time trying to recover it. And also because that laptop was used only for social media and similar so I never had anything too serious on it that could not be lost with any great regrets.

I did pull the hdd out so I may be able to get into it and see further details at some point. But what is curious is that i was running protonvpn-CLI on it w kill switch on even though that is only community listed now with no official support anymore. And the Twitter was running in Brave browser also which is pretty secure. So not sure how it got through. I did have a wireless mouse & keyboard on which I normally did not use either so the usb radio for that could have been hacked too. But it was fast enough that it must have been a bot.

1 Like
10

Not really, sbctl already makes it as easy as possible. Apart of the distro providing it per default like Ubuntu. But Arch Linux which Garuda Linux is based on does not.

1 Like
11

Garuda is not targeted towards a corporate audience. To the best of my knowledge the only distro’s currently shipping with secure boot pre-configured are all from for profit Linux corporations targeting business sector sales.

Garuda has no intention of moving towards a corporate model, so unless Arch heads in that direction I find it very doubtful that Garuda will be implementing secure boot. It’s simply not a priority for a distro that is intended for performance and gaming enthusiasts, (not the suit and tie business world).

5 Likes
12

Yes I don’t need it for stealth. I was just looking for a simple way to give maximum protection against boot-loader BIOS hijacking like bootkitty.

I love Garuda with its organic (grifter-proof?) business/operational model as it is and thrilled to hear the commitment to it!

Ho Ho Ho ! :santa: :mrs_claus: :mx_claus:

1 Like
13

Yikes, scarry stuff. How up-to-date was that Brave installation? Sounds like it could be any number of known or unknown exploits, possibly even a MitM or MitB situation, since you are confident you were on Twitter, or :heavy_multiplication_x:

2 Likes
14

It also interferes with Bitlocker on the Windows side because of the way Windows is chainloaded in bootloader, so it’s really not worthwhile in the long term convenience-wise.

Most simple way is to simply turn secure boot on or off via UEFI depending on if u need to use win with bitlocker enabled or linux

1 Like
15

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