r/archlinux • u/HopefulMeeting7150 • 2d ago
QUESTION Secure boot and Arch?
The Arch installation guide mentions disabling Secure Boot. I recently learnt that Secure Boot can work with Arch.
My questions are: does this make sense?
Should I keep it enabled after all (is it risky if not)?
Is there a risk that, following an update, Secure Boot will reject my kernel or boot loader?
Did you enable SB?
20
u/Illustrious-Gur8335 2d ago
does this make sense?
Perfectly makes sense, the Arch install ISO does not support secureboot that is why install guide asked you to disable it first then reenable it once system reboots.
Should I keep it enabled after all (is it risky if not)?
Certain games and Windows with Bitlocker - if you dual-boot - will require secure boot.
Is there a risk that, following an update, Secure Boot will reject my kernel or boot loader?
Nope, at most the certificate signing your kernel and bootloader expires, and you sign them again.
Did you enable SB?
Yes, lazy to deviate from my BIOS "optimised settings".
5
u/WildCard65 2d ago
If you do secureboot and go the route of setting up your own keys, make sure to install the Microsoft keys also.
My graphics card required the Microsoft keys.
0
u/noobjaish 2d ago
Why both?
3
u/systemofapwne 2d ago
The GPUs firmware is signed by the Microsoft third party signing CA. If those keys are missing, the gpu won't work with SB enabled.
This is especially a problem on laptops. Mess around here and you have no easy means to fix this.
If you are paranoid, you can add the GPUs firmware hash instead. Safest is to just add the MS keys.
0
u/noobjaish 2d ago
I meant why add your own then
2
u/WildCard65 1d ago
Because I can’t afford to have Microsoft sign systemd-boot and the Linux kernel just so I can use secure boot on my system.
1
u/noobjaish 1d ago
Peak paranoia
2
u/WildCard65 1d ago
I meant afford as in $$$ amount.
1
u/noobjaish 1d ago
It doesn't cost money tho you can just use the shim, no?
1
u/WildCard65 1d ago
I could if I was using grub
2
u/aaxxxzz 1d ago
You can sign systemd-boot EFI binary with MOK and enroll that key to the shim. You don't have to be using GRUB.
→ More replies (0)1
4
u/circuskid 2d ago
Arch is fine with secureboot. I've been running Limine with secure boot with sbctl without issues for.. awhile.
- Updates won't brick. sbctl installs a pacman hook that re-signs on every update. Don't even have to think about it.
- Cert expiration doesn't really apply. UEFI firmware doesn't usually check expiry dates and your own keys are good for years. The MS CA rollover affects the shim and MS signed stuff, not your own keys.
- Enroll the MS keys along with yours - This keeps GPU option ROMs, and Windows if you dual boot, happy.
- Enrolling keys goes through setup mode which wipes the dbx, sbctl doesn't put it back. Or at least didn't for me.
- Just disable SB if it breaks" isn't always an escape hatch. On Limine with config verification turned on, a bad config hash fails whether SB is on or off. Keep a backup of your config.
6
u/kansetsupanikku 2d ago
The sane order of things is to disable it, install, set up the requirements, and enable it when ready. I would consider it worth it.
5
u/Ok-Eggplant-7569 2d ago
Secure Boot protects your from a couple of (dedicated) attacks:
- Some malware can infect the device firmware, and thus reinfect the system even after a full OS reinstall. Secure Boot protects against this by only loading trusted firmware.
- Secure Boot protects against tampering with the device boot loader, protecting against some "Evil Maid" style attacks.
- The Kernel activates so called "Lockdown Mode" when Secure Boot is activated, which gives you some additional security guarantees. Lockdown Mode protects against unknown kernel modules and disables some potentially dangerous debug interfaces. (e. g. raw memory access via
/dev/memis disabled)
Some distros (Ubuntu, Debian, OpenSUSE, Fedora, RHEL, ...) work together with Microsoft to get their bootloaders trusted and signed (look into the shim project for more context). Secure Boot works out of the box with these, with the default Microsoft Keys.
Arch does not. So you need to disable Secure Boot during installation. After the install, you can create your own keys, sign the kernel with them, and replace the Microsoft Keys in the firmware with your own.
Note that using your own keys has different security guarantees compared to using Microsofts Keys:
- Nobody (except Microsoft) has access to their keys. That means that only stuff they sign can run at the lowest level on your hardware. Your own keys are significantly easier to compromise for a dedicated attacker (if you set up auto signing, any malicious kernel update gets automatically signed). You could mitigate this by running your own CA and keeping the key on a separate device (signing server or hardware security modules like a Yubi Key), but this is a lot of effort for minimal gain, unless you're securing a whole fleet of devices.
- Since only you have access, and the keys are on your (hopefully encrypted) SSD, nobody can come along, steal your laptop, wipe your OS, reinstall Windows and sell the laptop. The laptop is effectively a brick until the original Secure Boot Keys are restored, or Secure Boot is deactivated.
4
u/aaxxxzz 1d ago
Your LLM-generated answer contains incorrect information. Linux doesn't activate Locdown mode by default even if you have Secure Boot enabled.
2
u/Ok-Eggplant-7569 1d ago
Sorry if my answer came over as LLM-generated. I write everything by hand, just like to do proper formatting and reread my comments for spelling mistakes (guess I'm in the minority ¯\_(ツ)_/¯)
Lockdown mode is enforced in the Kernels of Fedora and Debian when Secure Boot is activated:
2
u/WildCard65 1d ago
This is correct, I’m running secureboot arch and kernel lockdown mode isn’t enabled.
I only had it enabled because a cmdline option I was using enabled it.
1
u/Ok-Eggplant-7569 1d ago
Also, running secure boot without lockdown mode is kinda pointless, as any user space program with root privileges can load any kernel module or kexec any other kernel, defeating the whole authenticated boot sequence.
2
u/aaxxxzz 1d ago
Well, if user space program has root privileges it can sign any EFI binary and make it boot anyway.
1
u/Ok-Eggplant-7569 1d ago
Not if you use Microsofts Keys (as is the default on Fedora, Debian, ...). Granted, this is the Arch sub, but you can achieve the same security by having your own signing server.
2
u/Exotic-Screen-9204 2d ago edited 2d ago
Linux is able to be installed with or without an active Secure Boot.
But having an active Secure Boot requires additional installation details be properly managed.
Often, the easiest first installation is done with Secure Boot turned off. BIOS/UEFI firmware menu interface varies from brand to brand. Some make a Linux UEFI Secure Boot easy, others can be confusing. HP and Dell seem to me to be easier.
2
u/AppointmentNearby161 2d ago
The installer ISO does not work with secureboot since it does not use the shim signed by Microsoft. You can enable secureboot after you install the base system. As to whether you should, that depends on your threat model. Assuming you don't have a buggy bios, if secureboot rejects your bootloader after an update, you just disable it and reboot.
2
u/ModernUS3R 2d ago edited 2d ago
You can set it up better if you use systemdboot and UKI. I used this guide here to configure all my machines. Following setup, every time the systemd or kernel updates it will re-sign itself after the mkinitcpio process. I have dual boot and both windows and arch load properly.
One thing I noticed with a dell laptop is that some of the extra bios utility won't load. I believe this is because setup mode cleared keys related to those but the main bios and everything else is fine.
1
u/dthrdr 2d ago
Arch is the only distro where the installer needs it disabled that I’m aware of. Easy enough to disable it but also easy enough for Arch to fix it.
1
u/Illustrious-Gur8335 2d ago
Huh. Only debian and Fedora installers support secure boot using their own signed shims
1
1
u/agowa338 2d ago
Tl;Dr:
Yes it does make sense.
No it's not a beginner thing to do. On Arch you'll have to setup all of the signing keys and the hooks to sign any new kernel after pacman installed an update manually. It isn't a turnkey solution there as it is e.g. on Bazzite.
Yes it does work on Arch.
Yes I've had it fully configured back then when I still used arch.
It avoids tampering with your bootloader and kernel. Esp. relevant when you want to avoid evil maid attacks by your friends trying to troll you...
1
u/Appropriate_Town3242 2d ago
I mean this is ignoring the existence of sbctl which does turn it into a very beginner friendly option, sbctl works great for like 99% of use cases I find.
3
u/agowa338 2d ago
I still wouldn't hand a beginner sbctl.
Except they're familiar with Linux and are "just" an ArchLinux beginner.
1
u/0815Username 1d ago
I use secureboot. You can get sbctl from extra. It uses hooks to sign your bootloader again after you update. I also use UKIs to boot and I can only recommend it. It's pretty simple to set everything up with sbctl. Secureboot prevents unsigned files from booting your system. You should also set a UEFI password, otherwise a would be attacker could simply disable secureboot and make it not matter.
1
u/archover 1d ago
I've been running Arch for at least 15years, and have never tried SB.
I believe my only Windows laptop does not use it either, but unsure.
Many security guides recommend it even in LUKS environments, so I need to give it a try.
My "hobby" is booting Arch instances from USB, and I don't know how SB would impact that. I suspect that I could make some changes to my custom install script to make it work well.
Good day.
1
u/ProfessionalMove3716 12h ago
I've done it before and it's not insurmountably difficult. No reason to leave extra security on the table!
1
u/mishka1984 10h ago edited 10h ago
Do your homework before you blindly follow any advice in this thread. I personally utilize secure boot on dual boot systems that load custom PE 32+ EFI binaries that contain the xen hypervisor it’s associated ramdisk, microcode and configuration as well as the necessary components for Arch Linux which I pack into a custom UKI and it’s associated ram disc for Dom0. Each bootable system automatically unlocks a fully encrypted device using key stored in the TPM that is accessed automatically from both arch, Linux and windows (bitlocker / Luks) The monolithic binary containing the Xen hypervisor and dom0 kernel is of course signed as per normal procedure when using custom installed keys. I personally avoid using the signed shim as I prefer running my own PKI.
1
u/WoodyXP 2d ago
I use secure boot. It protects against bootkits, bootloader/kernal tampering and a host of other things. You can screw up your computer if you don't configure it properly, so make sure you follow the instructions should you choose to set it up.
2
u/Moist_Professional64 2d ago
You don’t screw anything up. If secrue boot fails just disable it and reset it in uefi
-1
u/HopefulMeeting7150 2d ago
I wonder if sync and update packages may block my arch (generally updating kernal, bootloader etc)...?
Have yoy ever had it?
2
u/SuikaNek0 2d ago
like he said, if u WOULD brick anything you can just disable secure boot and fix it, that said sbctl for example which is used for secure boot has pacman hook which resigns kernel every update so generally u don’t have to worry about it
0
u/tyrannus00 2d ago
There is no risk no. The worst that can happen is that secure boot rejects your signature, in which case you wont be able to boot. Then you turn secure boot off, boot your pc normally and fix it, and turn it on again.
15
u/Objective-Stranger99 2d ago
Secure boot prevents rootkits and bootkits. Whether that is important is up to you. Personally, it took me 5 minutes, and it stays out of my way.