Erreurs Secure Boot après l’installation : corriger la discordance clés/mode

Modèle mental : modes, clés et ce qui échoue réellement

Secure Boot n’est pas « un réglage ». C’est un système de chaîne de confiance appliqué par le firmware UEFI. Le firmware décide si l’exécutable suivant est autorisé à s’exécuter. Cet « exécutable suivant » est typiquement shim (sur de nombreuses distributions Linux), qui valide ensuite GRUB, qui valide ensuite le noyau (et parfois les modules du noyau).

Mode utilisateur vs mode configuration : les deux états importants

UEFI Secure Boot a deux états opérationnels pertinents :

• Mode configuration : la clé de plateforme (PK) n’est pas installée. Le firmware est effectivement « sans propriétaire ». Vous pouvez enrôler des clés sans autorisation parce qu’il n’y a pas de PK qui applique la propriété. C’est l’état dans lequel vous entrez souvent lorsque vous « effacez les clés Secure Boot ».
• Mode utilisateur : une PK est installée. Les bases de données de Secure Boot sont protégées et les mises à jour des clés nécessitent une autorisation. C’est l’état normal attendu pour un système qui applique Secure Boot.

Beaucoup d’échecs « post-installation Secure Boot » surviennent parce que la machine est en Mode configuration (ou a db/dbx vides), tandis que l’OS s’attend à ce que la chaîne de confiance tierce de Microsoft soit présente, ou s’attend à vos clés personnalisées. L’inverse arrive aussi : la machine est en Mode utilisateur avec des clés du fournisseur, mais vous avez installé un noyau ou un chargeur de démarrage qui n’est pas signé par une clé de confiance.

Les bases de données de clés : PK, KEK, db, dbx, et pourquoi dbx est le videur

• PK (Platform Key) : établit la propriété de la plateforme. Si la PK manque, vous êtes en Mode configuration.
• KEK (Key Exchange Key) : permet les mises à jour des listes autorisées/interdites.
• db : signatures/hachages autorisés. Si le signature du chargeur de démarrage se chaine à un certificat dans db, il peut s’exécuter.
• dbx : signatures/hachages interdits (liste de révocation). Si dbx dit « non », c’est non — même si db l’autoriserait autrement.

Les distributions qui supportent Secure Boot livrent généralement un shim signé. Ce shim est signé par une clé qui se relie à une CA UEFI tierce de Microsoft que de nombreux fournisseurs incluent dans db par défaut. Shim utilise ensuite son propre certificat intégré et/ou la liste MOK (Machine Owner Key) pour valider GRUB et les noyaux.

Qu’est-ce qu’une « discordance clés/mode » en pratique ?

Une discordance survient quand une partie suppose une racine de confiance qui n’est pas vraie :

• Le firmware applique Secure Boot en Mode utilisateur, mais le chargeur de démarrage/noyau installé n’est pas signé par une chaîne de confiance.
• Le firmware est en Mode configuration (PK effacée), mais votre OS s’attend aux clés du fournisseur/Microsoft, donc les signatures ne se valident pas comme prévu (ou vous n’appliquez rien, mais la chaîne de démarrage installée attend quand même un certain environnement).
• Vous avez des clés personnalisées mais vous avez oublié de les enrôler (ou vous les avez enrôlées dans MOK, alors que vous auriez dû les mettre dans db ; ou l’inverse).
• dbx a été mis à jour et bloque maintenant un ancien shim/grub (les erreurs liées à SBAT se trouvent souvent ici).

Une citation à garder en tête quand vous êtes tenté de « simplement désactiver » : (idée paraphrasée) « L’espoir n’est pas une stratégie. » — Gene Kranz. Secure Boot n’est pas parfait, mais le désactiver parce qu’il est agaçant équivaut en fiabilité à couper votre ceinture de sécurité parce qu’elle froisse votre vêtement.

Blague #1 : Secure Boot, c’est comme un videur de boîte de nuit avec un clipboard. Si votre nom n’est pas sur la liste, vous n’entrez pas — même si vous « connaissez le propriétaire ».

Faits intéressants et contexte historique (parce que le bazar a une histoire)

1. UEFI Secure Boot est arrivé dans le grand public avec le matériel de l’ère Windows 8. Il n’a pas été inventé pour embêter les utilisateurs Linux ; il répondait aux bootkits et malwares persistants qui vivaient sous l’OS.
2. La CA UEFI tierce de Microsoft est devenue le « pont » de facto pour Linux. Beaucoup de vendeurs l’installent dans db, ce qui permet aux distributions de démarrer un shim signé par Microsoft sans forcer chaque utilisateur à gérer ses propres clés.
3. Shim existe parce que les fournisseurs de firmware ne voulaient pas expédier la clé de chaque distro. Un seul shim signé plus une chaîne de confiance gérée par la distro est évolutif ; remplir db de tous les certificats serait impossible.
4. Les mises à jour de dbx sont des révocations globales en pratique. Lorsqu’une vulnérabilité est trouvée dans un composant de démarrage largement utilisé, dbx peut le bloquer sur les systèmes — utile et brutal.
5. SBAT a été introduit pour rendre la révocation plus granulaire. Au lieu de révoquer un certificat de signature entier (dommage collatéral), les métadonnées SBAT peuvent bloquer des builds vulnérables précis.
6. « Effacer les clés Secure Boot » n’est pas la même chose que « désactiver Secure Boot ». Effacer les clés vous met souvent en Mode configuration et peut créer des comportements plus étranges que simplement désactiver l’application.
7. MOK (Machine Owner Key) est un mécanisme au niveau de shim, pas du firmware. MOK est idéal pour signer noyaux/modules, mais il ne peuple pas magiquement le db du firmware.
8. Certaines marques livrent Secure Boot activé mais autorisent des clés tierces ; d’autres non. Ce bascule BIOS intitulée « Allow Microsoft 3rd party UEFI CA » décide si les shim Linux courants démarrent.
9. La signature des modules noyau est adjacente mais pas identique. Vous pouvez démarrer correctement et voir des pilotes échouer à se charger parce que l’application de la signature des modules est distincte de la validation UEFI Secure Boot.

Playbook de diagnostic rapide (vérifiez dans cet ordre)

Vous voulez du signal rapidement. Ne commencez pas par réinstaller quoi que ce soit. Ne commencez pas par désactiver Secure Boot. Vérifiez l’état, identifiez quel maillon de la chaîne a cassé, puis choisissez la correction la plus petite.

1) Vérifier le mode du firmware et l’état de Secure Boot

• Le système a-t-il démarré en mode UEFI (pas legacy/CSM) ?
• Secure Boot est-il activé et actif ?
• Le firmware est-il en Mode configuration (PK manquante) ou en Mode utilisateur ?

2) Identifier le composant en échec

• L’erreur provient-elle du firmware avant que shim ne s’exécute (« Security violation », « Invalid signature ») ?
• Shim démarre-t-il mais rejette GRUB/noyau (« Verification failed: (15) », « SBAT policy violation ») ?
• Démarre-t-il mais refuse-t-il ensuite des pilotes (NVIDIA, ZFS, Wi‑Fi) ? Là, c’est la signature des modules.

3) Confirmer quelles clés sont réellement enrôlées

• Contenu de firmware db/dbx (au moins existence/état).
• Contenu de la liste MOK si vous utilisez shim/MOK.
• Si « Microsoft 3rd party UEFI CA » est activée dans le firmware.

4) Décider votre modèle de confiance

• Parc d’entreprise : gardez généralement les clés du fournisseur + Microsoft, utilisez le shim de la distro, et utilisez MOK pour vos noyaux/modules.
• Contrôle total : utilisez des clés personnalisées (votre propre PK/KEK/db), signez tout ce que vous démarrez. Plus de travail. Plus de certitude.
• Machine de labo : si elle n’est pas connectée à quelque chose de sensible, désactiver Secure Boot est acceptable, mais documentez-le et cessez de prétendre que c’est « sécurisé ».

Signatures d’échec : ce que l’erreur signifie vraiment

Firmware : « Security violation » / « Invalid signature » avant tout menu

Le firmware a rejeté le binaire EFI. Causes typiques :

• Le chargeur de démarrage n’est pas signé par une clé dans db.
• Le hash/la signature du chargeur se trouve dans dbx (révoqué).
• Vous avez installé GRUB directement (non signé) au lieu du chemin signé par shim, ou vous avez écrasé le binaire signé.
• Le firmware est configuré pour interdire les CA tierces.

Shim : « Verification failed: (15) » après la sélection d’une entrée

Shim s’exécute, donc le firmware a accepté shim. Maintenant shim rejette GRUB ou le noyau parce qu’il ne peut pas valider l’étape suivante avec son certificat intégré ou la liste MOK.

SBAT policy violation

C’est souvent la logique de révocation qui fait son travail. Votre build shim/grub est suffisamment ancien (ou marqué vulnérable) pour que le dbx/SBAT actuel le bloque. La correction consiste généralement à démarrer un shim/grub plus récent, pas à combattre la liste de révocation.

Le système démarre, mais les pilotes échouent : « Required key not available »

Le noyau applique la signature des modules (souvent parce que Secure Boot est activé et que le verrouillage du noyau s’applique). Votre module tiers (NVIDIA, DKMS, ZFS, VirtualBox) n’est pas signé par une clé que le noyau approuve. Ce n’est pas un problème de db UEFI ; c’est un problème de porte-clés du noyau / MOK.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les vérifications que j’exécute sur des systèmes réels. Chaque tâche inclut : commande, ce que la sortie signifie et la décision à prendre. Les commandes supposent un environnement Linux ; si vous ne pouvez pas démarrer normalement, utilisez un live USB en mode UEFI et chroot là où c’est noté.

Task 1: Confirm the system booted in UEFI mode

cr0x@server:~$ test -d /sys/firmware/efi && echo "UEFI boot" || echo "Legacy boot"
UEFI boot

Signification : Si vous obtenez « Legacy boot », l’état de Secure Boot est sans objet parce que vous ne démarrez pas en UEFI.

Décision : Si legacy, corrigez d’abord le mode de démarrage du firmware (désactivez CSM/Legacy). Ne touchez pas aux clés pour l’instant.

Task 2: Check whether Secure Boot is enabled (runtime view)

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Signification : « enabled » signifie que le noyau croit que Secure Boot est actif. « disabled » peut vouloir dire qu’il est désactivé dans le firmware ou que vous avez démarré par un chemin qui le contourne.

Décision : Si désactivé alors que vous attendiez activé, vérifiez les modifications du firmware ou le démarrage en legacy.

Task 3: Check if firmware is in Setup Mode (PK missing)

cr0x@server:~$ mokutil --pk
PK is not enrolled

Signification : L’absence de PK signifie généralement le Mode configuration.

Décision : Si PK non enrôlée et que vous voulez l’application, restaurez/enrôlez des clés (valeurs par défaut du fournisseur ou PK/KEK/db personnalisées).

Task 4: Check if Microsoft and vendor keys are present (quick health check)

cr0x@server:~$ sudo efi-readvar -v db | head
Variable db, length 2346
PKCS7 signature:
Signer: Microsoft Corporation UEFI CA 2011

Signification : Voir des signataires Microsoft UEFI CA suggère que l’ancre de confiance commune est présente dans db.

Décision : Si db est vide ou illisible, restaurez les clés par défaut (si votre politique le permet) ou enrôlez les vôtres.

Task 5: Inspect dbx for obvious revocations causing your failure

cr0x@server:~$ sudo efi-readvar -v dbx | head
Variable dbx, length 17892
Signature list 1
Signature type: X509

Signification : dbx est peuplé. C’est normal. Une combinaison « dbx trop récent + shim trop ancien » peut casser le démarrage après des mises à jour.

Décision : Si l’erreur est liée à SBAT, priorisez la mise à jour de shim/grub plutôt que d’essayer de revenir en arrière sur dbx.

Task 6: Verify what EFI binaries exist and which one you’re booting

cr0x@server:~$ sudo ls -R /boot/efi/EFI | sed -n '1,80p'
/boot/efi/EFI:
Boot  ubuntu

/boot/efi/EFI/Boot:
BOOTX64.EFI

/boot/efi/EFI/ubuntu:
grubx64.efi  mmx64.efi  shimx64.efi

Signification : La présence de shimx64.efi indique un chemin compatible Secure Boot. Si vous n’avez que grubx64.efi et qu’il est non signé, le firmware peut le rejeter.

Décision : Si shim est absent, réinstallez le paquet shim-signed de la distribution et réenregistrez l’entrée de démarrage.

Task 7: Check UEFI boot entries and what file they point to

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0003* ubuntu	HD(1,GPT,4d7b...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0001* UEFI OS	HD(1,GPT,4d7b...,0x800,0x100000)/File(\EFI\Boot\BOOTX64.EFI)

Signification : Si votre entrée pointe directement vers grubx64.efi et que Secure Boot est activé, vous jouez avec le feu quant à l’acceptation de ce binaire.

Décision : Pointez l’entrée vers shim quand c’est approprié, ou corrigez la signature/chaîne de confiance pour GRUB.

Task 8: Confirm shim/grub are actually signed (file-level check)

cr0x@server:~$ sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi
signature 1
image signature issuers:
 - /CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
 - /CN=Canonical Ltd. Secure Boot Signing

Signification : Si sbverify peut lister des signatures et qu’elles se relient à quelque chose de plausible, le binaire n’est pas manifestement non signé.

Décision : S’il est non signé, réinstallez à partir de paquets de confiance. Ne copiez pas manuellement des binaires EFI depuis des sources aléatoires.

Task 9: Check MOK enrollment status (common after installing DKMS modules)

cr0x@server:~$ mokutil --list-enrolled | head
[key 1]
SHA1 Fingerprint: 9a:7c:...
Subject: CN=Local DKMS Signing

Signification : Une clé locale enrôlée existe. Utile si vous devez charger des modules DKMS signés.

Décision : Si vos noyaux/modules échouent avec « Required key not available », vous devrez probablement enrôler une clé ou signer les modules avec celle existante.

Task 10: See kernel lockdown and Secure Boot effects

cr0x@server:~$ dmesg | grep -i -E 'secureboot|lockdown' | head -n 20
[    0.000000] Secure boot enabled
[    0.532101] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7

Signification : Le verrouillage du noyau est actif ; certaines opérations (comme l’accès brut aux MSR, kexec dans certains modes) peuvent être restreintes.

Décision : Si un outil échoue soudainement après l’activation de Secure Boot, confirmez que c’est une conséquence du verrouillage et non une régression aléatoire.

Task 11: Diagnose module signature failures (NVIDIA/DKMS symptoms)

cr0x@server:~$ sudo journalctl -k -b | grep -i -E 'module verification|Required key not available' | head
kernel: Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
kernel: nvidia: module verification failed: signature and/or required key missing

Signification : Le système a démarré correctement ; maintenant le noyau refuse un module.

Décision : Signez le module avec une clé que le noyau approuve (souvent via MOK), ou utilisez des modules signés par la distribution quand c’est possible.

Task 12: Check installed shim/grub package versions (are you running antique boot components?)

cr0x@server:~$ dpkg -l | egrep 'shim-signed|grub-efi-amd64-signed' || true
ii  grub-efi-amd64-signed  1.187.3+2.12-1ubuntu7  amd64  GRUB EFI signed kernel loader
ii  shim-signed            1.58+15.7-0ubuntu1     amd64  Secure Boot chain-loading bootloader (Microsoft-signed)

Signification : Vous pouvez corréler ces versions avec la probabilité d’être compatible SBAT et patché.

Décision : Si vous êtes en retard et voyez des échecs SBAT, mettez à jour ces paquets depuis vos dépôts habituels.

Task 13: Validate the kernel image signature (when your distro signs kernels)

cr0x@server:~$ sbverify --list /boot/vmlinuz-$(uname -r) | head
signature 1
image signature issuers:
 - /CN=Canonical Ltd. Secure Boot Signing

Signification : Si le noyau est signé et que shim attend des noyaux signés, cela devrait paraître correct.

Décision : S’il est non signé, vous exécutez probablement un noyau personnalisé qui nécessite une signature et un enrôlement MOK, ou vous avez installé un noyau hors du jeu signé de la distro.

Task 14: Repair the EFI boot entry to point at shim (common simple fix)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "ubuntu-shim" -l '\EFI\ubuntu\shimx64.efi'
BootCurrent: 0003
BootOrder: 0007,0003,0001,0002
Boot0007* ubuntu-shim	HD(1,GPT,4d7b...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Signification : Vous avez créé une nouvelle entrée qui démarre shim directement.

Décision : Si Secure Boot fonctionne après cela, l’ancienne entrée pointait vers le mauvais binaire.

Task 15: Identify whether you’re in a “firmware won’t allow third-party” configuration

cr0x@server:~$ sudo efi-readvar -v db | grep -i -E 'Microsoft Corporation UEFI CA 2011|Windows UEFI' | head
Signer: Microsoft Windows UEFI Driver Publisher
Signer: Microsoft Corporation UEFI CA 2011

Signification : La présence suggère que db du firmware contient les clés Microsoft. Pourtant, certains firmwares ont un bascule séparée qui désactive l’usage des CA tierces.

Décision : Si db contient la CA mais que shim ne démarre toujours pas, inspectez l’interface du firmware pour le paramètre « third-party », ou le mode « Standard/Custom » du fournisseur.

Task 16 (live USB + chroot): Reinstall signed boot components cleanly

cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind $i /mnt$i; done
cr0x@server:~$ sudo chroot /mnt bash -lc 'apt-get update && apt-get install --reinstall shim-signed grub-efi-amd64-signed && update-grub'
Reading package lists... Done
Setting up shim-signed ...
Setting up grub-efi-amd64-signed ...
Generating grub configuration file ...

Signification : Vous forcez un redéploiement propre des binaires EFI signés et reconstruisez la configuration GRUB.

Décision : Si le système précédemment démarrait avec GRUB non signé ou un shim obsolète, cela corrige généralement le problème — à condition que les clés/modes soient corrects.

Corriger la discordance clés/mode : voies pratiques

Il y a trois stratégies sensées. Choisissez-en une. Les mélanger, c’est comment on finit dans le purgatoire « ça marche jusqu’à la prochaine mise à jour ».

Voie A : valeurs par défaut du fournisseur + shim de la distro (recommandé pour la plupart)

Quand choisir : portables, serveurs exécutant des distributions grand public, postes d’entreprise, tout ce où vous voulez une posture standard et supportable.

Objectif : Le firmware reste en Mode utilisateur avec les clés du fournisseur/Microsoft. Vous démarrez via le shim fourni par la distro et des GRUB/noyaux signés. Si vous avez besoin de modules DKMS, signez-les et enrôlez une MOK.

Ce que vous faites :

• Dans le firmware : chargez les clés par défaut (souvent nommé « Install factory default keys » ou « Restore factory keys »).
• Assurez-vous que « Microsoft 3rd party UEFI CA » est activé si votre distro l’utilise.
• Dans l’OS : réinstallez shim-signed et grub-efi-*-signed, assurez-vous que l’entrée de démarrage pointe vers shim.
• Si vous avez des modules non signés : générez une clé de signature locale, enrôlez-la via MOK manager, signez les modules.

Voie B : clés entièrement personnalisées (PK/KEK/db) pour environnements contrôlés

Quand choisir : systèmes réglementés, appliances, environnements où vous ne voulez pas de clés Microsoft dans votre magasin de confiance, ou si vous envoyez un produit et voulez une confiance de démarrage déterministe.

Objectif : Vous contrôlez PK/KEK/db. Vous signez shim/grub/noyau vous‑même (ou utilisez un shim signé par vos clés et les enrôlez). Vous maintenez votre propre logique de révocation.

Vérité dure : c’est du travail opérationnel. Rotation des clés, procédures de récupération, bizarreries des interfaces firmware et éviter de briquer les machines sont maintenant votre problème. Si vous ne pouvez pas vous y engager, faites la Voie A.

Voie C : désactiver Secure Boot (seulement quand vous en avez l’intention)

Quand choisir : urgence à court terme pour restaurer un service, machines de labo, ou comme décision de politique explicite avec contrôles compensatoires.

Objectif : Démarrer de façon fiable maintenant, puis revenir et implémenter A ou B correctement.

Blague #2 : Désactiver Secure Boot pour régler Secure Boot, c’est comme réparer une alarme incendie en enlevant la pile. Le bruit s’arrête ; l’incendie s’en fiche.

Situations courantes de « discordance de mode » et la correction propre

Situation : PK effacée (Mode configuration), Secure Boot « activé » et rien ne démarre de façon cohérente

Pourquoi ça arrive : quelqu’un a effacé les clés pour « réinitialiser », puis a laissé Secure Boot activé. Vous êtes maintenant dans un état qui varie selon le firmware du fournisseur et casse souvent les chaînes attendues.

Correction : restaurez les clés d’usine (Voie A) ou enrôlez PK/KEK/db personnalisés (Voie B). Ne laissez pas l’appareil à moitié « possédé ».

Situation : le firmware n’autorise pas la CA tierce

Pourquoi ça arrive : certains systèmes ont un paramètre qui ne fait confiance qu’aux clés Windows de production par défaut. Votre shim Linux dépend de la CA UEFI tierce de Microsoft.

Correction : activez la CA tierce dans le firmware, ou enrôlez le certificat shim de votre distro dans db (moins courant, plus laborieux), ou passez aux clés personnalisées.

Situation : vous avez installé un noyau personnalisé ou un GRUB compilé

Pourquoi ça arrive : vous avez remplacé des composants signés par des éléments non signés, puis Secure Boot a fait son travail.

Correction : signez les binaires et enrôlez la confiance correctement. Ou revenez aux paquets signés de la distribution.

Situation : violation de politique SBAT après des mises à jour

Pourquoi ça arrive : dbx/SBAT a révoqué d’anciens builds shim/grub vulnérables. Vos binaires EFI installés sont maintenant bloqués.

Correction : mettez à jour shim/grub vers une version non révoquée en utilisant un environnement de secours, puis démarrez normalement. Évitez de revenir en arrière sur dbx sauf si vous acceptez sciemment le risque connu.

Trois mini-récits d’entreprise venant du pays du « ça marchait sur mon portable »

Incident #1 : la panne causée par une mauvaise hypothèse

L’entreprise déployait une nouvelle image Linux pour des postes développeurs. L’équipe d’image l’a testée sur trois modèles de portables et l’a validée. Lundi, la file d’assistance s’est transformée en attaque par déni de service — avec des justificatifs. La moitié du parc est arrivée sur une erreur firmware concernant des signatures invalides.

L’hypothèse erronée était subtile : « Tous les fournisseurs installent la CA UEFI tierce de Microsoft dans db. » Beaucoup le font. Certains non. Et certains l’installent mais la cachent derrière un bascule BIOS qui est par défaut « off » dans certaines régions ou profils de sécurité.

Ce qui a empiré les choses : l’image était construite en supposant que shim serait accepté, mais l’entrée de démarrage pointait directement vers grubx64.efi sur un sous-ensemble de machines à cause d’un quirk de packaging lors de l’imagerie. Sur les machines au db permissif, ça démarré. Sur les firmwares plus stricts, c’était mort.

La correction n’a rien d’héroïque. Ils ont standardisé les paramètres firmware via leur outil de gestion, activé explicitement la CA tierce quand c’était permis, et mis à jour le processus d’imagerie pour enregistrer systématiquement l’entrée vers shim. Le vrai gain du post-mortem : ajouter une étape de préflight en staging qui validait Secure Boot sur chaque SKU matériel, pas seulement « ce qui traîne près du banc de tests ».

Incident #2 : l’optimisation qui s’est retournée contre eux

Une équipe plateforme voulait des itérations noyau plus rapides pour un service sensible à la latence. Quelqu’un a proposé de construire un noyau personnalisé avec un petit ensemble de patches et le déployer sur un parc d’edge servers. Ils voulaient garder Secure Boot activé — bonne instinct.

L’« optimisation » a été de sauter la chaîne de signature. La théorie : « Nous sommes déjà dans le centre de données ; la sécurité physique est forte ; on signera plus tard. » Ils ont poussé le noyau via l’automatisation, redémarré un canari, et vu l’échec de démarrage dû à des erreurs de signature. C’était attendu. L’imprévu : leur automation a interprété l’échec du canari comme « nœud non sain, redémarrez-le encore », et a créé une petite tempête de redémarrages sur un sous-ensemble de machines avant qu’on n’arrête le job.

Ils ont récupéré en démarrant le noyau signé précédent via l’entrée de secours du chargeur — sur les machines où GRUB l’offrait encore. Sur celles où la config du chargeur avait été « simplifiée » à une seule entrée (pour gagner une seconde de temps de démarrage), il n’y avait pas de fallback. Celles-là ont nécessité un sauvetage manuel.

Leçon : Secure Boot ne casse pas votre déploiement. Votre déploiement casse votre déploiement. Si vous livrez des noyaux personnalisés, la signature ne peut pas être une réflexion d’après-coup. C’est l’artefact de release.

Incident #3 : la pratique ennuyeuse mais correcte qui a sauvé la journée

Une équipe stockage gérait un petit cluster critique traitant des sauvegardes et archives long terme. Les serveurs n’étaient pas glamours, ce qui explique précisément leur valeur : ils changeaient rarement et fonctionnaient toujours.

Ils avaient une politique : chaque fois qu’ils appliquaient des mises à jour firmware, ils enregistraient l’état Secure Boot (activé/désactivé), le statut d’enrôlement PK et les chemins actuels des entrées de démarrage EFI. Le relevé vivait dans leur ticket de changement. C’était ennuyeux, répétitif, et personne n’a été promu pour ça.

Un trimestre, une mise à jour firmware a réinitialisé silencieusement les paramètres de clés Secure Boot sur deux nœuds. Les nœuds démarraient toujours, mais plus tard un module noyau utilisé pour la surveillance HBA a cessé de se charger avec « Required key not available ». L’ingénieur d’astreinte n’a pas paniqué. Il a comparé l’enregistrement de changement, vu que l’enrôlement MOK avait été effacé, a réenrôlé la clé durant la fenêtre de maintenance, et a re-signé les modules. Pas de perte de données, pas d’indisponibilité prolongée, pas de drame.

Le meilleur : l’équipe n’a pas « réparé » en désactivant Secure Boot. Ils ont réparé la discordance et ont continué. La fiabilité, c’est surtout de la répétition peu sexy, plus de bonnes notes.

Erreurs courantes : symptôme → cause → correction

1) « Verification failed: (15) » après l’installation

• Symptôme : shim s’exécute, mais la sélection de l’entrée Linux échoue.
• Cause : GRUB ou le noyau n’est pas signé par une clé que shim approuve ; MOK non enrôlée ; ou vous avez remplacé GRUB signé par un GRUB non signé.
• Correction : réinstallez le paquet grub signé ; assurez-vous que l’entrée de démarrage pointe vers shim ; enrôlez une MOK et signez le noyau si vous utilisez des builds personnalisés.

2) Firmware « Invalid signature » avant tout menu

• Symptôme : rejet immédiat du chargement du binaire EFI.
• Cause : db du firmware ne fait pas confiance au signataire du binaire, ou CA tierce désactivée, ou binaire révoqué par dbx.
• Correction : restaurez les clés d’usine et activez la CA tierce ; ou enrôlez vos propres clés et signez le binaire EFI ; ou mettez à jour shim/grub si révoqué.

3) Violation de politique SBAT après une mise à jour « normale »

• Symptôme : le système démarré hier ; aujourd’hui shim refuse avec un message SBAT.
• Cause : votre shim/grub est plus ancien que la politique de révocation désormais appliquée via dbx/SBAT.
• Correction : démarrez un média de secours, chroot, mettez à jour/réinstallez shim/grub, vérifiez que l’entrée EFI pointe vers le shim mis à jour.

4) Démarrage OK, mais NVIDIA/ZFS/VirtualBox échoue : « Required key not available »

• Symptôme : pilote manquant, build DKMS réussi mais module refusé.
• Cause : module non signé par une clé dans les keyrings de noyau ; MOK non enrôlée ou effacée.
• Correction : enrôlez une MOK et signez les modules ; relancez la signature DKMS ; vérifiez mokutil --list-enrolled.

5) Quelqu’un a « effacé les clés » pour dépanner et maintenant tout est bizarre

• Symptôme : Mode configuration, comportement incohérent au reboot, bascules Secure Boot qui ne se comportent pas comme prévu.
• Cause : PK supprimée ; plateforme pas dans un état stable Mode utilisateur.
• Correction : restaurez les clés par défaut (Voie A) ou implémentez un jeu de clés personnalisé complet (Voie B). Arrêtez d’effacer les clés comme étape de debug.

6) Dual-boot soudainement cassé après réinstallation de Windows ou Linux

• Symptôme : un OS démarre ; l’autre échoue avec des erreurs de signature ou des entrées manquantes.
• Cause : entrées de démarrage écrasées ; binaires EFI remplacés ; clés du fournisseur inchangées mais le chemin de démarrage pointe maintenant vers un GRUB non signé.
• Correction : reconstruisez les entrées avec efibootmgr ; réinstallez shim/grub pour Linux ; confirmez que chaque OS pointe vers son chargeur signé correct.

7) « SecureBoot disabled » dans l’OS mais le firmware dit activé

• Symptôme : divergence entre l’UI du firmware et mokutil --sb-state.
• Cause : démarré en mode legacy, ou via un chemin qui ne fait pas appliquer Secure Boot, ou bizarrerie d’implémentation du firmware.
• Correction : vérifiez le boot UEFI via /sys/firmware/efi ; inspectez les entrées de démarrage ; désactivez CSM.

Listes de contrôle / plan étape par étape

Checklist 1 : Vérifications minimales avant de toucher aux paramètres firmware

1. Confirmer le boot UEFI : test -d /sys/firmware/efi.
2. Vérifier l’état runtime de Secure Boot : mokutil --sb-state.
3. Vérifier l’enrôlement PK : mokutil --pk.
4. Inspecter les entrées de démarrage : efibootmgr -v.
5. Lister les binaires EFI : ls -R /boot/efi/EFI.

Si vous ne pouvez pas démarrer : faites ces vérifications depuis un live USB démarré en mode UEFI, après avoir monté la partition système EFI.

Checklist 2 : Voie de réparation pour « mauvaise entrée de démarrage » (gain rapide)

1. Monter l’ESP et confirmer que shim existe : /boot/efi/EFI/<distro>/shimx64.efi.
2. Créer une nouvelle entrée UEFI pointant vers shim avec efibootmgr -c ... -l '\EFI\...\shimx64.efi'.
3. La déplacer en tête de BootOrder (ou la définir explicitement).
4. Redémarrer et confirmer que la validation firmware passe.

Checklist 3 : Voie de réparation pour « shim/grub ancien révoqué » (mismatch SBAT/dbx)

1. Démarrer un environnement rescue/live à jour en mode UEFI.
2. Monter le système racine et l’ESP ; bind-monter /dev, /proc, /sys, /run.
3. Chrooter et réinstaller les paquets shim/grub signés.
4. Exécuter update-grub (ou équivalent distro).
5. Vérifier que l’entrée de démarrage pointe vers le shim mis à jour.

Checklist 4 : Voie de réparation pour « signature de module requise » (démarre mais pilotes échouent)

1. Confirmer l’échec du module dans les logs : journalctl -k -b.
2. Vérifier la liste MOK : mokutil --list-enrolled.
3. S’il n’existe pas de clé adaptée : créez-en une (via les outils de la distro), enrôlez-la, redémarrez via le MOK manager.
4. Signer les modules (ou relancer DKMS pour qu’il signe automatiquement).
5. Confirmer le chargement du module : modprobe <module> et revérifier les logs.

Checklist 5 : Politique sûre pour un parc (ce qu’il faut standardiser)

1. Documenter si vous dépendez de la CA UEFI tierce de Microsoft ou de clés personnalisées.
2. Standardiser les bascules firmware (Secure Boot activé, CA tierce autorisée si nécessaire, CSM désactivé).
3. Bloquer ou orchestrer les mises à jour shim/grub ; ne laissez pas de binaires EFI antiques traîner.
4. Avoir un workflow de secours capable de mettre à jour shim/grub depuis un média hors ligne.
5. Suivre les procédures d’enrôlement MOK pour les systèmes fortement dépendants de DKMS.

FAQ

1) Pourquoi Secure Boot a-t-il échoué juste après l’installation ? Je n’ai rien changé.

Parce que l’installateur a peut‑être fait quelque chose. Il a pu créer une entrée de démarrage pointant vers le mauvais binaire EFI, installer un GRUB non signé, ou supposer des clés firmware que votre système n’a pas (ou a désactivées).

2) Quelle est la différence entre effacer les clés et désactiver Secure Boot ?

Désactiver Secure Boot coupe l’application. Effacer les clés supprime l’état PK/KEK/db et vous met souvent en Mode configuration. Effacer les clés peut créer un état semi-cassé ; désactiver est au moins déterministe.

3) Si shim est signé par Microsoft, est-ce que ça signifie que Microsoft contrôle mon démarrage Linux ?

Non. La signature de Microsoft permet au firmware d’exécuter shim. Ensuite shim applique la validation des étapes suivantes en utilisant des certificats de la distro et/ou MOK. Votre modèle de confiance dépend des clés que vous acceptez dans db du firmware et de ce que shim approuve.

4) Je vois « Secure boot enabled » et « Kernel is locked down ». Est-ce mauvais ?

C’est un compromis. Le verrouillage réduit la surface d’attaque (bon) et bloque certains outils bas‑niveau (parfois ennuyeux). Si votre flux de travail nécessite ces outils, décidez délibérément si vous voulez Secure Boot et le verrouillage sur cette machine.

5) Puis-je simplement signer GRUB moi‑même et laisser tout le reste inchangé ?

Oui, mais vous devez vous assurer que le signataire est approuvé par le composant qui le valide. Le firmware valide le premier stage qu’il exécute ; shim valide l’étape suivante selon ses certificats intégrés et MOK. Signer sans enrôler la confiance, ce sont juste des bits coûteux.

6) Pourquoi un pilote échoue à se charger alors que le système démarre ?

Parce que la validation Secure Boot au démarrage et l’application de la signature des modules à l’exécution sont des couches séparées. Votre noyau peut être signé et accepté, mais un module DKMS construit localement peut rester non signé et être rejeté.

7) Qu’est‑ce que SBAT et pourquoi ça me gâche la journée ?

SBAT est un mécanisme pour révoquer des composants de démarrage vulnérables de façon plus précise. Si votre shim/grub est trop ancien, la politique SBAT peut le bloquer. La correction est typiquement la mise à jour de shim/grub, pas la bataille contre la liste de révocation.

8) Je fais du dual‑boot. Devrais‑je utiliser des clés personnalisées ?

En général non, sauf si vous aimez gérer un programme complet de gestion des clés pendant votre temps libre. Valeurs par défaut du fournisseur + shim de la distro est l’approche la plus supportable pour les systèmes dual‑boot.

9) Que faire si je ne peux pas démarrer du tout et que j’ai besoin de récupérer la machine maintenant ?

Démarrez un live USB en mode UEFI, montez le système et réinstallez shim/grub signés comme montré plus haut. Si la politique le permet, désactivez temporairement Secure Boot pour retrouver l’accès, puis corrigez les clés et réactivez.

10) Comment savoir si le problème vient de db/dbx ou de MOK ?

Si le firmware rejette avant shim, c’est db/dbx/confiance au niveau firmware. Si shim s’exécute mais rejette GRUB/noyau, c’est la confiance shim/MOK/certificats de la distro. Si l’OS démarre mais que les modules échouent, c’est le keyring du noyau / la signature des modules via MOK.

Étapes suivantes que vous devriez vraiment faire

Les échecs Secure Boot après installation sont rarement « aléatoires ». Il s’agit généralement d’une attente cassée : le firmware applique un modèle de confiance, votre chaîne de démarrage installée a été construite pour un autre, et clés/modes ne correspondent pas.

1. Exécutez les vérifications rapides : démarrage UEFI, état Secure Boot, présence de PK, cible de l’entrée de démarrage.
2. Choisissez une stratégie : valeurs par défaut du fournisseur + shim de la distro (dans la plupart des cas) ou clés personnalisées complètes (seulement si vous pouvez les gérer).
3. Réparez la chaîne de démarrage avec le changement le plus petit : pointez les entrées vers shim, réinstallez shim/grub signés, mettez à jour si SBAT/dbx bloque d’anciens builds.
4. Si vous avez des modules DKMS, traitez l’enrôlement MOK et la signature des modules comme partie intégrante du pipeline de build — pas comme un rituel de nuit blanche.
5. Notez ce que vous avez changé dans le firmware. Le vous du futur est une autre personne, et elle ne mérite pas des surprises.

Si vous faites cela correctement, Secure Boot cesse d’être une roulette russe. Il redevient ce qu’il était censé être : une porte prévisible qui ne s’ouvre que pour les logiciels que vous avez explicitement approuvés.