Ga naar inhoud

Secure Boot

Om CachyOS te installeren moet Secure Boot eerst uit. Anders dan Ubuntu of Fedora gebruikt CachyOS geen shim, een door Microsoft ondertekende bootloader waarmee distributies van derden kunnen opstarten onder Secure Boot. Zonder shim blokkeert Secure Boot de CachyOS-bootloader bij het opstarten, waardoor het voor de installatie uitgeschakeld moet worden (CachyOS installatiedocumentatie).

Na de installatie kun je Secure Boot opnieuw inschakelen met eigen ondertekeningssleutels via sbctl. Zo heb ik dat gedaan. De sectie hieronder is het lezen waard voordat je eraan begint, want op Linux met een NVIDIA GPU kun je je afvragen of het de moeite echt waard is.

Resultaat: UEFI Secure Boot gaat van Fail naar Pass na het voltooien van deze handleiding. De algehele HSI-score blijft HSI:3! (de Encrypted RAM-check op HSI-4 wordt niet ondersteund op deze hardware, waardoor HSI:4 niet haalbaar is).

Is het de moeite waard?

Secure Boot dekt alleen de opstartcyclus: firmware, bootloader, kernel. Op deze hardware eindigt die keten met de NVIDIA-driver die als niet-ondertekende DKMS-module laadt, waardoor de kernel permanent tainted is. Je hebt de voordeur beveiligd en het raam opengezet.

Dan is er nog het Microsoft-aspect. Stap 3 vereist de --microsoft-vlag, want zonder de UEFI CA-certificaten van Microsoft laadt de GPU-firmware niet. Je schrijft dus de sleutels van Microsoft in op je eigen machine, ook al gebruik je “eigen” sleutels. Dat is een beetje tegenstrijdig voor iets wat als jouw eigen vertrouwensketen wordt verkocht.

Waar Secure Boot eigenlijk tegen beschermt is het scenario waarbij iemand met fysieke toegang je bootloader vervangt terwijl je er niet bij bent. Als dat een echte zorg is, is volledige schijfversleuteling een veel directere oplossing, en CachyOS stelt dat al in tijdens de installatie.

In de praktijk zorgt Secure Boot inschakelen ervoor dat fwupdmgr security en het GNOME-beveiligingspaneel er netjes uitzien en de HSI-score van 2 naar 3 gaat. Dat is zo’n beetje de winst. Ik heb het toch ingesteld omdat ik wilde begrijpen hoe het werkt, en de betere score is een leuke bijkomstigheid. Maar als je het wilt overslaan, is dat ook prima.

Context van het beveiligingsrapport

Het uitvoeren van fwupdmgr security toont wat slaagt en wat niet. Na het inschakelen van Secure Boot zijn de overgebleven fouten op deze hardware:

TestNa deze handleidingReden
UEFI Secure Boot✓ PassOpgelost door deze handleiding
Encrypted RAM (HSI-4)✗ Not SupportedHardwarebeperking: Ryzen AI 9 HX 370 implementeert AMD SME/TME niet
Linux Kernel Verification✗ TaintedProprietary NVIDIA-driver vervuilt de kernel permanent (verwacht gedrag)
Linux Kernel Lockdown✗ Not EnabledVereist kernel lockdown-modus, niet behandeld hier; conflicteert met proprietary modules

fwupdmgr security uitvoer met HSI:3 en UEFI Secure Boot uitgeschakeld

Hoe het werkt

In plaats van de shim → MOK → kernel-keten die veel distributies gebruiken, schrijft sbctl aangepaste Secure Boot-sleutels rechtstreeks in de UEFI-firmware in. De bootloader en het kernel EFI-image worden daarna ondertekend met die sleutels. Geen shim of MOK Manager nodig.

sbctl wordt ook geleverd met een pacman-hook die alle geregistreerde EFI-binaries automatisch opnieuw ondertekent na kernel- of bootloader-updates, iets wat je na de initiële setup niet meer handmatig hoeft te doen.

Installatie

sudo pacman -S sbctl

Stap 1: UEFI Setup Mode activeren

Setup Mode is een UEFI-toestand waarbij er nog geen Secure Boot-sleutels zijn ingeschreven, waardoor nieuwe sleutels kunnen worden toegevoegd. Je moet eerst in deze toestand komen voordat je sleutels aanmaakt.

Herstart naar de ASUS UEFI:

systemctl reboot --firmware-setup

In de ASUS UEFI (druk op F7 voor Geavanceerde Modus indien nodig):

  1. Ga naar het tabblad Security
  2. Selecteer Secure Boot
  3. Zet Secure Boot Control op Enabled
  4. Open Key Management
  5. Selecteer Clear Secure Boot Keys (of Reset to Setup Mode indien beschikbaar)
  6. Bevestig en Save & Exit (F10)

Controleer na het herstarten in CachyOS of Setup Mode actief is:

sudo sbctl status

Verwachte uitvoer:

Installed:    ✗ sbctl is not installed
Owner GUID:   <jouw-guid>
Setup Mode:   ✗ Enabled
Secure Boot:  ✗ Disabled
Vendor Keys:  none

Setup Mode met de waarde Enabled bevestigt dat de UEFI klaar is voor sleutelinschrijving. De -symbolen zijn hier geen fouten; ze geven alleen aan dat de sleutels nog niet zijn aangemaakt, wat precies de bedoeling is op dit punt.

Stap 2: Sleutels aanmaken

sudo sbctl create-keys

Stap 3: Sleutels inschrijven

Dit schrijft de aangepaste sleutels in de firmware in, inclusief de UEFI CA-certificaten van Microsoft. De --microsoft-vlag is vereist op ASUS-hardware; zonder die certificaten weigeren option ROMs (GPU-firmware) en andere UEFI-drivers van Microsoft te laden. Ik aarzelde een beetje om de sleutels van Microsoft mee te nemen, maar zonder die vlag start het systeem niet goed op.

sudo sbctl enroll-keys --microsoft

Stap 4: EFI-binaries ondertekenen

Het ondertekeningsproces verschilt iets per bootloader.

systemd-boot

Onderteken alle EFI-binaries en registreer ze in de sbctl-database. De -s-vlag is belangrijk; die zorgt ervoor dat bestanden automatisch opnieuw worden ondertekend na toekomstige updates:

sudo sbctl verify
sudo sbctl-batch-sign
sudo sbctl verify

Alle vermeldingen moeten tonen. Als er staan, onderteken ze dan handmatig:

sudo sbctl sign -s /pad/naar/niet-ondertekend.efi

CachyOS gebruikt systemd-boot-update.service om de systemd-boot binary bij te werken. Dit werkt buiten de standaard sbctl-hook om, dus de bronbinary moet expliciet worden ondertekend zodat die bij elke bootloader-update opnieuw wordt meegenomen:

sudo sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
  /usr/lib/systemd/boot/efi/systemd-bootx64.efi

Limine

Limine beheert zijn eigen ondertekeningsproces en vereist geen handtekeningen op kernel-images:

sudo limine-enroll-config
sudo limine-update

Stap 5: Secure Boot inschakelen

Herstart opnieuw naar de ASUS UEFI:

systemctl reboot --firmware-setup
  1. Ga naar SecuritySecure Boot
  2. Zet Secure Boot Control op Enabled
  3. Bevestig dat de sleutels aanwezig zijn onder Key Management (DB, KEK, PK moeten allemaal gevuld zijn)
  4. Save & Exit (F10)

Verificatie

Na het herstarten ziet het er zo uit:

sudo sbctl status
Installed:    ✓ sbctl is installed
Owner GUID:   <jouw-guid>
Setup Mode:   ✓ Disabled
Secure Boot:  ✓ Enabled
Vendor Keys:  microsoft

sbctl status bevestigt dat Secure Boot ingeschakeld is en Setup Mode uitgeschakeld is

fwupdmgr security

De regel UEFI Secure Boot onder HSI-1 moet nu Enabled tonen. De algehele score blijft HSI:3! (Encrypted RAM op HSI-4 wordt niet ondersteund op deze hardware, wat los staat van deze handleiding).

fwupdmgr security uitvoer na het inschakelen van Secure Boot - HSI:3 met UEFI Secure Boot nu geslaagd onder HSI-1

GNOME Instellingen → Privacy & Beveiliging → Apparaatbeveiliging bevestigt ook het resultaat:

GNOME Apparaatbeveiliging met Protected en Secure Boot is Active

NVIDIA en kernelupdates

UEFI Secure Boot verifieert alleen de bootloader en het kernel-EFI-image. De NVIDIA-driver wordt als DKMS-module door de kernel geladen. In deze configuratie staat de kernel module-signatures niet af te dwingen, waardoor de NVIDIA-module blijft werken, maar de kernel als tainted wordt gemarkeerd. Extra module-signing voor NVIDIA valt daarom buiten de scope van deze handleiding.

Wie ook kernelmodules cryptografisch wil afdwingen, moet NVIDIA-modules met dezelfde sleutel signen of de proprietary driver vermijden.

Na een kernelupdate activeert pacman beide:

  1. sbctl-hook → ondertekent het nieuwe kernel EFI-image opnieuw
  2. DKMS → bouwt NVIDIA-modules voor de nieuwe kernel opnieuw

Na updates is geen handmatige actie nodig.

Kernelvervuiling: De proprietary NVIDIA-driver zal de kernel blijven vervuilen. Dit verschijnt als Linux Kernel Verification: Tainted in het HSI-rapport. Dit is verwacht; het betekent dat niet-open-source code is geladen, niet dat het systeem is aangetast.

Overgebleven HSI-fouten uitgelegd

Encrypted RAM (HSI-4)

Niet oplosbaar op deze hardware. De Ryzen AI 9 HX 370 ondersteunt AMD Secure Memory Encryption (SME) niet op de manier waarop fwupd dit controleert. Dit is een hardwarebeperking, geen configuratieprobleem.

Linux Kernel Lockdown

Kernel lockdown kan worden ingeschakeld door lockdown=integrity toe te voegen aan de kernelparameters. Lockdown beperkt echter niet-ondertekende kernelmodules en bepaalde bevoorrechte bewerkingen, en de proprietary NVIDIA-driver zou niet werken onder lockdown-modus. Niet iets wat ik zou aanraden voor dagelijks gebruik op deze hardware.

Linux Kernel Verification (Tainted)

Veroorzaakt door de proprietary NVIDIA-driver. Kan niet worden opgelost zolang proprietary NVIDIA-drivers worden gebruikt. Dit is geen beveiligingslek.

Probleemoplossing voor Secure Boot staat op de pagina Bekende Problemen.

Referenties