Pilotes non signés : quand la sécurité a cassé du matériel parfaitement fonctionnel

novembre 11, 2025 • février 3, 2026 • Lecture : 28 min • Views: 0

Cet article vous a aidé ?

Le matériel est sain. Les câbles sont bien branchés. Les voyants clignotent comme d’habitude. Et pourtant votre chemin SAN a disparu, votre carte réseau a
disparu, ou votre nœud GPU est soudainement « périphérique inconnu ». Bienvenue dans la panne moderne : ce n’est pas un disque défaillant,
mais un pilote qui est devenu politiquement inacceptable du jour au lendemain.

Les pilotes non signés (ou mal signés) ne se contentent pas de « échouer à s’installer ». Dans de vrais systèmes, ils échouent bruyamment, au démarrage,
après une mise à jour, sous Secure Boot, ou seulement sur la sous-partie d’hôtes qui appliquent correctement les politiques. Le résultat ressemble
à une panne matérielle, mais c’est en réalité une panne de confiance. L’ordinateur n’a pas cessé de croire au périphérique. Il a cessé de croire en vous.

Ce qui a réellement cassé : la confiance, pas le matériel

Les incidents de pilotes non signés concernent rarement le périphérique. Ils concernent la plateforme qui décide que le code en mode noyau doit pouvoir être
prouvé comme étant écrit par quelqu’un en qui elle a confiance. Les pilotes ne sont pas des « applis ». Ils vivent en ring 0, peuvent lire la mémoire
appartenant à d’autres processus, et peuvent transformer votre réseau soigneusement segmenté en théâtre d’interprétation.

Les systèmes d’exploitation ont donc commencé à exiger des signatures. La signature n’est pas une garantie magique de qualité. C’est une chaîne de responsabilité :
quelqu’un se porte garant pour ce binaire, et l’OS est prêt à le charger en fonction de la politique. Cette politique devient plus stricte avec le temps,
parce que le noyau est une cible juteuse. Les équipes sécurité adorent ça. Les équipes Ops l’adorent jusqu’au moment où un redémarrage à minuit découvre que
le pilote HBA « parfaitement fonctionnel » a été signé avec le mauvais certificat, le mauvais algorithme de hachage, ou pas du tout.

Il existe trois grands ensembles de problèmes « pilote non signé » :

Jamais signé : raccourcis du fournisseur, pilotes hérités, builds de laboratoire passés en production, ou modules communautaires.
Signé, mais non acceptable : format de signature correct, mauvaise chaîne de confiance, certificat révoqué, horodatage expiré, ou bloqué par la politique.
Signé, mais non apparié : le module a été reconstruit lors d’une mise à jour noyau ; la signature ne correspond plus au binaire.

Si vous exécutez du stockage ou du réseau en production, ce n’est pas académique. Un pilote bloqué peut signifier :

Tous les chemins vers un LUN disparaissent au démarrage (multipath s’effondre, systèmes de fichiers deviennent lecture seule, bases de données paniquent).
Renommages d’interfaces ou NIC manquantes (bonding échoue, VRRP échoue, le cluster perd le quorum).
Les nœuds GPU perdent l’accélération et deviennent de coûteux radiateurs.
Les outils de gestion RAID/HBA échouent d’une manière qui masque de vrais problèmes de disque.

Faits et contexte : comment on en est arrivé là

L’exigence de signature n’est pas arrivée parce que les fournisseurs voulaient vous embêter. Elle est arrivée parce que le malware en mode noyau gagnait
trop souvent. Quelques faits courts et concrets aident à expliquer pourquoi l’application s’est durcie et continue de se durcir :

Windows x64 a commencé à pousser fortement la signature des pilotes au milieu des années 2000. Le changement a été progressif, mais la direction a été sans retour : davantage d’application, moins d’exceptions.
Secure Boot a changé le modèle de menace. Une fois que le firmware et la chaîne de démarrage sont vérifiés, les modules noyau non signés deviennent la prochaine tentative évidente de contournement.
Stuxnet (2010) utilisait des pilotes signés. De vrais certificats ont été détournés pour charger des pilotes noyau malveillants ; cela a prouvé que les signatures sont nécessaires mais pas suffisantes.
La révocation de certificats est devenue réelle opérationnellement. Lorsqu’une clé de signature est compromise, les fournisseurs la révoquent. Cela peut casser d’anciens pilotes qui « fonctionnaient hier ».
La dépréciation de SHA-1 a forcé le re-sig. Certains anciens pilotes s’appuyaient sur des algorithmes cryptographiques maintenant considérés faibles ; les plateformes les rejettent de plus en plus.
Les Windows Hardware Quality Labs (WHQL) de Microsoft ont modelé le comportement des fournisseurs. Être « correctement signé » signifie souvent passer par des processus d’écosystème, pas simplement acheter un certificat.
La signature de modules Linux existe, mais la politique dépend de la distribution et de l’organisation. Le noyau peut effectuer des vérifications de signature, mais le faire dépend de la configuration, de Secure Boot et des modes de verrouillage.
Les mises à jour dbx UEFI peuvent rendre des composants de démarrage précédemment fiables inutilisables. Les listes de révocation sont mises à jour dans le firmware ; votre pilote peut être signé, mais l’ancre de confiance peut être mise sur liste noire plus tard.
La virtualisation n’a pas supprimé le problème ; elle l’a déplacé. VFIO, SR-IOV, vGPU et le passthrough dépendent tous de pilotes noyau qui se chargent et s’exécutent de manière cohérente selon la politique.

Si vous cherchez un méchant unique ici, ce n’est pas la « sécurité ». C’est l’hypothèse que le code noyau peut être traité comme un logiciel en espace utilisateur. Ce n’est pas le cas.
Le noyau est la ligne ténue entre « serveur » et « art abstrait ».

Une citation à garder sur un post-it près de votre calendrier de changements :

« L’espoir n’est pas une stratégie. » — idée paraphrasée attribuée à de nombreux responsables opérations

Modes d’échec qui rendent les pilotes non signés aléatoires

Les équipes Ops détestent les incidents de pilotes non signés parce qu’ils se présentent comme incohérents. La même mise à jour fonctionne sur cinq hôtes et explose sur
le sixième. Ce n’est pas surnaturel. C’est de la dérive de politique plus du timing.

1) La politique n’active que sous Secure Boot ou en mode lockdown

Beaucoup d’environnements ont un cerveau divisé : certains hôtes ont Secure Boot activé (ou un mode « lockdown »), d’autres non. Le pilote se charge
sur les hôtes permissifs, échoue sur les stricts. La différence peut être un réglage du BIOS, une variation de l’image standard, ou un technicien sur site qui a
« corrigé » quelque chose lors d’une visite de rack.

2) Les mises à jour du noyau modifient le binaire, si bien que la signature ne correspond plus

Si vous dépendez de modules construits par DKMS (courants pour les NIC, HBA, pilotes GPU, ZFS-on-Linux, et divers modules « performance »), une mise à jour
du noyau déclenche une reconstruction. Cette reconstruction doit aussi être signée dans les environnements Secure Boot. Si ce n’est pas le cas, le module ne se chargera pas.

3) Le pilote est signé, mais la chaîne n’est plus approuvée

Les chaînes de confiance vieillissent. Les certificats expirent. Les racines tournent. Des révocations surviennent. Un pilote peut être parfaitement signé, mais rejeté
parce que l’OS ne fait plus confiance au certificat de signature ou que l’horodatage n’est plus valide. Cela se manifeste par « ça marchait avant », ce qui n’est pas un détail diagnostique,
c’est une confession.

4) Les fournisseurs expédient plusieurs paquets avec des états de signature différents

Il est courant de voir un paquet « datacenter » et un paquet « desktop », ou une branche « legacy » et une branche « moderne ». L’un est signé pour attestation,
l’autre est signed-test, l’un est « signé par le fournisseur mais pas par l’autorité de l’écosystème ». Installer le mauvais et vous vivez sur du temps emprunté.

5) Les humains ne redémarrent pas assez souvent

La dure vérité : beaucoup d’équipes ne redémarrent pas régulièrement les serveurs. Cela signifie que le problème de pilote non signé reste latent jusqu’au seul redémarrage
que vous ne pouvez pas éviter : travaux d’alimentation, mise à jour firmware, mise à jour du noyau, ou « c’est mercredi, nuit de patch ».

Blague n°1 (courte, pertinente) : Les pilotes sont comme les parachutes : vous ne découvrez la couture manquante que quand vous en avez vraiment besoin.

Playbook de diagnostic rapide (premier/second/troisième)

Quand un hôte perd le stockage ou le réseau après une mise à jour ou un redémarrage, vous n’avez pas le temps pour des débats philosophiques sur la confiance.
Vous avez besoin d’une séquence qui trouve rapidement le goulot d’étranglement, produit des preuves, et mène à une décision.

Premier : confirmer que le périphérique est présent et ce qui a changé

Le périphérique PCI est-il visible par l’OS ?
L’état Secure Boot/lockdown a-t-il changé ?
Le noyau a-t-il été mis à jour ? Le pilote a-t-il été reconstruit ?

Second : prouver l’échec du chargement du pilote et capturer la raison exacte

Consultez les logs du noyau pour rejet de signature, « taint » ou « Required key not available ».
Vérifiez si le module existe, si son vermagic correspond, et s’il est signé.
Vérifiez les codes d’erreur Device Manager sous Windows (notamment Code 52) et le statut de signature.

Troisième : choisir entre trois voies de récupération sûres

Changement de politique (temporaire) : désactiver l’application pour restaurer le service, mais traiter cela comme une action contrôlée de casse-glace.
Changement de pilote : installer une version de pilote correctement signée qui correspond à la politique et à la build OS.
Correction du workflow de signature : signer les modules DKMS (MOK sur Linux) ou utiliser des paquets certifiés par le fournisseur (WHQL/attestation sur Windows).

L’erreur est d’essayer les trois en même temps, de générer du bruit, et de perdre la chaîne causale. Choisissez une hypothèse, collectez des preuves, exécutez un changement,
validez.

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

Ci-dessous se trouvent des tâches pratiques que vous pouvez exécuter sur de vrais systèmes. Chacune inclut : la commande, un exemple de sortie, ce que signifie la sortie,
et la décision à prendre. Les commandes sont séparées entre Linux et Windows (via PowerShell, mais exécutées depuis un shell de type bash utilisant pwsh quand approprié).
Utilisez ce qui s’applique à votre parc.

Task 1 (Linux): confirm Secure Boot state

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

Sens : le système applique une politique de démarrage vérifiée. Les modules noyau non signés peuvent être bloqués.

Décision : si vous dépendez de modules hors arbre (DKMS, pilotes fournisseurs), vous devez vous assurer que la signature des modules est en place.

Task 2 (Linux): check kernel lockdown mode

cr0x@server:~$ cat /sys/kernel/security/lockdown
integrity [confidentiality]

Sens : le lockdown est actif (integrity/confidentiality). Cela accompagne souvent Secure Boot et peut restreindre le chargement des modules et certaines interfaces du noyau.

Décision : traitez « le module non signé ne se chargera pas » comme un comportement attendu ; corrigez la signature plutôt que de lutter contre le noyau.

Task 3 (Linux): confirm the PCI device is detected

cr0x@server:~$ lspci -nn | egrep -i 'ethernet|fibre|raid|nvme'
03:00.0 Ethernet controller [0200]: Broadcom Inc. and subsidiaries NetXtreme BCM57414 [14e4:16d7]
05:00.0 Fibre Channel [0c04]: Emulex Corporation LPe32002-M2 [10df:f0f5]

Sens : l’énumération matérielle est correcte. L’OS voit le périphérique sur le bus.

Décision : concentrez-vous sur l’attachment/chargement du pilote, pas sur le câblage ou le remplacement matériel.

Task 4 (Linux): check which driver is bound (or not)

cr0x@server:~$ lspci -k -s 05:00.0
05:00.0 Fibre Channel: Emulex Corporation LPe32002-M2
	Subsystem: Emulex Corporation LPe32002-M2
	Kernel driver in use: (none)
	Kernel modules: lpfc

Sens : le noyau connaît le module qui pourrait le piloter (lpfc), mais il n’est pas chargé/attaché.

Décision : tentez de charger le module et surveillez les logs pour des erreurs de signature.

Task 5 (Linux): try loading the module and capture the error

cr0x@server:~$ sudo modprobe lpfc
modprobe: ERROR: could not insert 'lpfc': Key was rejected by service

Sens : il s’agit d’un problème de signature/confiance (clé rejetée). Sur les systèmes Secure Boot, cela signifie fréquemment que le module n’est pas signé par une clé de confiance.

Décision : ne pas insister en répétant. Vérifiez la signature du module et inscrivez une clé (MOK) ou installez un module signé par le fournisseur.

Task 6 (Linux): pull the exact kernel log line

cr0x@server:~$ dmesg -T | tail -n 20
[Mon Jan 21 03:14:02 2026] Lockdown: modprobe: Loading of unsigned module is restricted; see man kernel_lockdown.7
[Mon Jan 21 03:14:02 2026] lpfc: module verification failed: signature and/or required key missing - tainting kernel
[Mon Jan 21 03:14:02 2026] modprobe: ERROR: could not insert 'lpfc': Key was rejected by service

Sens : vous avez une chaîne de preuve claire : lockdown + échec de signature + rejet de clé.

Décision : corrigez la signature ; si c’est un chemin de stockage sur un hôte de production, prévoyez le casse-glace contrôlé uniquement si vous n’avez pas d’autre chemin.

Task 7 (Linux): check if a module is signed (modinfo)

cr0x@server:~$ modinfo lpfc | egrep -i 'signer|sig_key|sig_hashalgo|vermagic' || true
vermagic:       6.5.0-21-generic SMP preempt mod_unload

Sens : l’absence de champs signer implique probablement que le module n’est pas signé (ou que les métadonnées ne sont pas présentes).

Décision : si Secure Boot est activé, les modules hors arbre non signés ne sont pas une option. Utilisez des paquets signés ou signez vous-même avec MOK.

Task 8 (Linux): verify kernel version vs module build

cr0x@server:~$ uname -r
6.5.0-21-generic

Sens : vous avez besoin d’un module construit pour cet ABI du noyau. Même un module signé peut échouer si vermagic ne correspond pas.

Décision : si le module a été construit pour un noyau différent, réinstallez le bon paquet ou reconstruisez DKMS et signez le résultat.

Task 9 (Linux): inspect DKMS status to spot unsigned rebuilds

cr0x@server:~$ dkms status
zfs/2.2.2, 6.5.0-21-generic, x86_64: installed
nvidia/535.154.05, 6.5.0-21-generic, x86_64: installed

Sens : DKMS a construit des modules pour ce noyau. C’est bien. Cela ne dit rien sur la signature.

Décision : confirmez la signature et l’enrôlement MOK ; « installed » n’est pas synonyme de « chargeable sous Secure Boot ».

Task 10 (Linux): list enrolled Machine Owner Keys (MOK)

cr0x@server:~$ sudo mokutil --list-enrolled | head -n 12
[key 1]
SHA1 Fingerprint: 9a:2b:1c:3d:4e:5f:60:71:82:93:a4:b5:c6:d7:e8:f9:0a:1b:2c:3d
Subject: CN=Ops Module Signing 2025
Issuer:  CN=Ops Module Signing 2025

Sens : une clé de signature est enrôlée. Si vos modules ne sont pas signés par cette clé, le noyau ne les chargera toujours pas.

Décision : standardisez une clé organisationnelle par environnement, et assurez-vous que les hooks de signature DKMS l’utilisent de façon cohérente.

Task 11 (Linux): sign a module (example) and confirm it

cr0x@server:~$ sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /root/MOK.priv /root/MOK.der /lib/modules/$(uname -r)/updates/dkms/zfs.ko

cr0x@server:~$ modinfo /lib/modules/$(uname -r)/updates/dkms/zfs.ko | egrep -i 'signer|sig_key|sig_hashalgo|vermagic'
vermagic:       6.5.0-21-generic SMP preempt mod_unload
sig_id:         PKCS#7
signer:         Ops Module Signing 2025
sig_key:        9A2B1C3D4E5F60718293A4B5C6D7E8F90A1B2C3D
sig_hashalgo:   sha256

Sens : le module porte maintenant une signature valide et identifie le signataire.

Décision : si le signataire correspond à une clé enrôlée, le module devrait se charger sous Secure Boot. Procédez au chargement et vérifiez le fonctionnement du périphérique.

Task 12 (Linux): check for missing storage devices after driver failure

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT | head
NAME      SIZE TYPE MOUNTPOINT
sda       447G disk 
├─sda1      1G part /boot
└─sda2    446G part /

Sens : seul le disque de démarrage est présent ; les LUN SAN ou périphériques NVMe sont absents, cohérent avec un pilote HBA/NVMe non chargé.

Décision : arrêtez le débogage au niveau système de fichiers. Corrigez d’abord le chemin de chargement du pilote, puis rescannez et confirmez multipath.

Task 13 (Linux): verify multipath health (if applicable)

cr0x@server:~$ sudo multipath -ll
mpatha (3600508b400105e210000900000490000) dm-2 IBM,2145
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 4:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 5:0:0:1 sdc 8:32 active ready running

Sens : vous avez au moins un chemin actif. Si cette sortie est vide ou montre « failed faulty », le chemin/pilote de stockage est compromis.

Décision : si les chemins sont down à cause d’un échec de chargement du pilote, ne faites pas rebondir multipath en boucle ; restaurez d’abord le pilote HBA/NVMe sous-jacent.

Task 14 (Windows via PowerShell): spot Code 52 and signature issues

cr0x@server:~$ pwsh -NoProfile -Command "Get-PnpDevice | Where-Object { $_.Status -ne 'OK' } | Select-Object -First 5 -Property Class,FriendlyName,Status,ProblemCode"
Class        FriendlyName                         Status   ProblemCode
-----        ------------                         ------   -----------
Net          Intel(R) Ethernet Controller X710     Error             52
SCSIAdapter  Vendor RAID Controller               Error             52

Sens : ProblemCode 52 de Windows signifie classiquement « Windows ne peut pas vérifier la signature numérique des pilotes requis pour ce périphérique ».

Décision : ne perdez pas de temps à réinstaller le même paquet. Obtenez un pilote correctement signé (WHQL/attestation) correspondant à la build OS et à la politique de sécurité.

Task 15 (Windows via PowerShell): check if test signing is enabled (it shouldn’t be)

cr0x@server:~$ pwsh -NoProfile -Command "bcdedit /enum {current} | Select-String -Pattern 'testsigning|nointegritychecks|secureboot'"
testsigning              No
nointegritychecks        No

Sens : le système n’est pas en mode « laissez tout se charger ».

Décision : maintenez cet état. Résolvez la signature des pilotes correctement ; désactiver les contrôles d’intégrité laisse une dette opérationnelle coûteuse.

Task 16 (Linux): confirm module is actually loaded after signing

cr0x@server:~$ sudo modprobe zfs

cr0x@server:~$ lsmod | grep -E '^zfs\b'
zfs                  6356992  0

Sens : le module se charge. Vous pouvez maintenant vérifier si les pools s’importent, si les NIC apparaissent, ou si les périphériques FC s’énumèrent.

Décision : validez la fonctionnalité de bout en bout (périphériques présents, systèmes de fichiers montés, services en bonne santé) avant de déclarer victoire.

Blague n°2 (courte, pertinente) : Les politiques de sécurité sont comme les ceintures de sécurité : vous ne les regrettez que jusqu’au moment où vous souhaitez les avoir.

Trois mini-récits d’entreprise issus des guerres des pilotes

Mini-récit 1 : la panne causée par une mauvaise hypothèse

Une entreprise de taille moyenne exploitait une flotte d’hôtes de virtualisation avec des HBA Fibre Channel en duplex. L’installateur du fournisseur avait été utilisé pendant des années :
télécharger le paquet, exécuter l’installateur, redémarrer pendant une fenêtre de maintenance, passer à autre chose. L’hypothèse était simple et erronée : « Si le pilote
s’installe, il se chargera. »

Puis la baseline sécurité a changé. Les nouveaux hôtes ont été provisionnés avec Secure Boot activé par défaut—silencieusement, parce que c’est ce que le firmware livre désormais,
et l’équipe build était fière de ce « hardening ». Personne n’a mis à jour le runbook parce que rien n’avait encore cassé. C’était une configuration parfaite pour une panne parfaite :
un cluster a été étendu avec des nœuds « plus sécurisés », et ils semblaient sains jusqu’à leur premier redémarrage.

La nuit de patch est arrivée. La moitié du cluster a redémarré et est revenue sans aucun LUN SAN. Les datastores « avaient disparu », les VM refusaient de démarrer,
et le canal d’incident s’est rempli de théories sur le zoning des switches et des fautes de baie. La baie allait bien. Les switches FC allaient bien. Les HBA allaient bien.
Le pilote FC n’était pas approuvé.

Le détail révélateur était dans dmesg : « Key was rejected by service. » Secure Boot avait modifié les règles, et le module fournisseur hors arbre n’avait jamais été
signé d’une manière acceptée par le noyau. L’hypothèse « l’installation a réussi = runtime ok » leur a coûté des heures.

La correction n’a pas été héroïque. Ils ont standardisé les réglages firmware, documenté l’état Secure Boot comme champ d’inventaire de première classe, et sont passés
à un parcours de paquet pilote qui supportait la signature de module. Le changement le plus précieux fut culturel : la conformité des pilotes est devenue partie intégrante
de la gestion du cycle de vie, pas une étape d’installation ponctuelle.

Mini-récit 2 : une optimisation qui s’est retournée contre eux

Une équipe d’ingénierie voulait accélérer le patching. Ils ont construit un noyau personnalisé avec un ensemble minimal de modules et ont utilisé DKMS pour compiler quelques pilotes
fournisseurs et modules de performance pendant la construction de l’image. C’était propre : moins de paquets, démarrage plus rapide, versions noyau prévisibles.

Ils ont aussi activé Secure Boot dans le cadre d’une initiative de conformité. Mais le workflow de signature n’a pas été intégré à la pipeline d’image.
En dev, les gens désactivaient Secure Boot « temporairement ». En prod, Secure Boot restait activé. Vous voyez la suite.

Le retour de bâton est arrivé lors d’une mise à niveau de noyau routinière. DKMS a reconstruit automatiquement les modules au redémarrage. Les modules étaient corrects pour
le nouveau noyau, mais non signés. Les hôtes sont revenus sans interfaces réseau pilotées par ces modules DKMS. Certains nœuds sont sortis du cluster.
D’autres ont démarré mais ont subi une baisse de bande passante et des pics de latence parce que le bonding est passé sur une interface plus lente.

Le postmortem fut inconfortable parce que l’optimisation semblait intelligente : compiler au moment de la construction, réduire les dépendances, automatiser les reconstructions.
Le point manquant était la confiance : chaque reconstruction automatisée doit être automatiquement signée, et la clé de signature doit être enrôlée et gérée comme tout secret de production
(avec rotation et accès contrôlé).

Ils l’ont corrigé en faisant de la signature une étape de la pipeline, pas une opération manuelle, et en ajoutant une porte préalable au redémarrage : si un hôte allait booter
vers un noyau sans modules requis signés, la mise à jour est bloquée. Cela a évité que des fenêtres de patch futures se transforment en audits surprise de pilotes.

Mini-récit 3 : la pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation exploitait des serveurs Linux orientés stockage avec NVMe et quelques modules fournisseurs spécifiques. Ce n’était pas glamour, mais c’était discipliné.
Chaque hôte avait un profil « politique de démarrage » enregistré : état Secure Boot, empreintes MOK enrôlées, et une liste de modules requis qui doivent se charger pour que le nœud
soit considéré sain.

Avant de déployer une mise à jour noyau, ils effectuaient un test à blanc : vérifier la présence des modules, vérifier les signatures, vérifier que le signataire correspond à une clé
MOK enrôlée. Si quelque chose échouait, l’hôte n’entrait simplement pas dans le lot de maintenance. Cela signifiait que le patch prenait parfois plus de temps, ce qui était correct,
parce que les pannes prennent plus de temps que le patch.

Un jour, un fournisseur a publié un bundle de pilotes mis à jour. Quelqu’un a tenté de le pousser rapidement parce qu’il « corrigeait les performances ». Les vérifications préalables ont signalé
que le signataire du module ne correspondait pas à la clé MOK enrôlée de l’organisation, et il ne se chargerait pas sous Secure Boot. Le déploiement s’est arrêté automatiquement.

Ils ont eu le temps d’engager le fournisseur, d’obtenir un paquet correctement signé, et de le tester dans un environnement avec Secure Boot activé. La production n’a jamais vu l’échec.
Personne n’a été réveillé à 3h du matin. La pratique n’était pas un outil sophistiqué. C’était traiter « va-t-il se charger selon la politique » comme un critère de release, pas comme une
surprise post-redémarrage.

Erreurs courantes : symptôme → cause première → correction

Les échecs liés aux pilotes non signés se répètent parce que les équipes interprètent mal les symptômes. Voici les schémas qui apparaissent en salle d’incident, avec la correction actionnable,
pas des posters motivants.

1) LUN de stockage manquants après redémarrage → pilote HBA bloqué par Secure Boot → installer un module signé ou enrôler la clé de signature

Symptôme : lsblk affiche seulement le disque de démarrage ; multipath vide ; périphérique FC présent dans lspci mais aucun pilote en cours d’utilisation.
Cause : module rejeté : « Key was rejected by service » / « required key missing ».
Correction : utilisez un paquet fournisseur qui supporte Secure Boot, ou signez le module avec une clé MOK enrôlée ; validez avec les champs signer de modinfo.

2) NIC disparue ou renommée → module NIC hors arbre n’a pas pu se charger → confirmer module + signature et reconstruire/signer DKMS

Symptôme : bonds échouent ; ip link n’a pas l’interface attendue ; routage cassé.
Cause : après mise à jour du noyau, DKMS a reconstruit le module mais ne l’a pas signé ; Secure Boot le bloque.
Correction : appliquer des hooks de signature DKMS ; garder les clés MOK cohérentes ; ajouter des vérifications préalables avant redémarrage.

3) Windows Device Manager affiche Code 52 → pilote mal signé pour la politique → remplacer par une version WHQL/attestation signée

Symptôme : le périphérique affiche « Windows cannot verify the digital signature… » et refuse de démarrer.
Cause : mauvaise branche de pilote (test-signed ou signé par le fournisseur sans chaîne acceptable), ou chaîne de signature révoquée/bloquée.
Correction : installer le paquet correctement signé ; éviter de désactiver l’application des signatures ; confirmer via le statut PnP et les logs d’événements.

4) « Ça marche jusqu’au redémarrage » → module chargé une fois, puis politique renforcée ou noyau changé → traiter les redémarrages comme événements de validation

Symptôme : aucun problème en runtime ; après un redémarrage de maintenance le périphérique disparaît.
Cause : l’application de la politique ne s’évalue qu’au moment du chargement ; les sessions existantes masquent les futurs échecs au boot.
Correction : tester les redémarrages en staging avec la même politique firmware ; planifier des redémarrages contrôlés périodiques pour faire remonter les problèmes latents.

5) Sous-ensemble aléatoire d’hôtes échoue → dérive de politique dans le parc → inventorier Secure Boot et clés enrôlées

Symptôme : le même pilote fonctionne sur certains hôtes, échoue sur d’autres.
Cause : BIOS Secure Boot incohérent, différents états db/dbx de révocation, enrôlement MOK différent, ou paramètres lockdown noyau mixtes.
Correction : normaliser les réglages firmware ; capturer l’état politique des hôtes dans la CMDB/inventaire ; appliquer à la provision.

6) « Nous avons désactivé Secure Boot pour corriger » → récupération court terme, fragilité long terme → utiliser casse-glace avec rollback et suivi

Symptôme : service restauré rapidement en désactivant l’application, mais maintenant l’environnement est « spécial ».
Cause : le correctif d’urgence est devenu permanent parce que la vraie cause (workflow de signature) n’a jamais été résolue.
Correction : si vous devez désactiver l’application, limitez dans le temps, documentez, et créez une tâche pour réactiver avec des modules signés testés.

Checklists / plan étape par étape

Checklist A: before you roll a kernel update (Linux)

Enregistrer l’état politique : Secure Boot activé/désactivé, mode lockdown, empreintes MOK enrôlées.
Lister les modules requis : stockage (HBA/NVMe), réseau, GPU, système de fichiers (par ex. ZFS), add-ons de virtualisation.
Vérifier l’existence du module pour le nouveau noyau : vérifier que le fichier du module existe sous /lib/modules/NEWKERNEL/.
Vérifier les signatures : modinfo doit afficher les champs signer ; le signataire doit correspondre à la clé enrôlée.
Planifier un test de redémarrage : redémarrer un canari avec Secure Boot activé ; valider l’énumération des périphériques et la santé des services.
Définir un chemin de retour : garder le noyau précédent disponible ; confirmer que le bootloader peut le sélectionner à distance.

Checklist B: when a driver gets blocked in production

Arrêter les suppositions : collecter dmesg / journal comme preuves d’échec de signature ou de rejet de clé.
Confirmer la présence matérielle : lspci et attachement pilote lspci -k.
Confirmer la politique : mokutil --sb-state, mode lockdown.
Confirmer la signature du module : champs signer de modinfo.
Choisir une voie de récupération :
- Installer un paquet pilote correctement signé.
- Enrôler MOK et signer les modules.
- Casse-glace : détendre temporairement l’application (documenter, limiter dans le temps, revenir en arrière).
Valider de bout en bout : périphériques présents, multipath sain, services up, performances normales.
Prévenir la récurrence : ajouter des vérifications préalables à la pipeline de patch ; inventorier l’état firmware.

Checklist C: build a sustainable signing workflow (Linux DKMS-heavy environments)

Créer une clé dédiée de signature de module par environnement (séparer prod et non-prod compte).
Stocker les clés privées en sécurité (accès restreint, usage auditéré, plan de rotation).
Enrôler la clé publique via MOK sur chaque hôte Secure Boot, comme partie de la provision.
Automatiser la signature après les constructions DKMS (hooks post-install) et vérifier les signatures en CI.
Bloquer les redémarrages sans vérifications préalables pour que les hôtes ne puissent pas booter dans un état où les modules requis ne se chargent pas.
Documenter le casse-glace avec propriétaire explicite et délai de réactivation.

FAQ

1) Qu’est-ce qu’un « pilote non signé » en pratique ?

C’est tout composant en mode noyau que la plateforme refuse de charger parce qu’elle ne peut pas valider une signature qu’elle considère fiable. Cela inclut
les binaires véritablement non signés, les mal signés, et les correctement signés dont la chaîne de confiance n’est pas acceptable sous la politique en vigueur.

2) Pourquoi cela n’apparaît-il qu’après un redémarrage ?

L’application de la signature du pilote s’évalue lorsque le noyau charge le module ou initialise le pilote. S’il était déjà chargé, votre système peut fonctionner
correctement jusqu’au prochain démarrage qui force une évaluation fraîche. Le redémarrage est un sérum de vérité.

3) Désactiver Secure Boot est-ce une solution acceptable ?

Comme casse-glace temporaire pour restaurer le service, parfois oui—si vous comprenez le risque et pouvez revenir rapidement. Comme solution permanente, non.
Vous accumulerez des exceptions, perdrez de l’auditabilité, et finirez par échouer un audit de conformité ou de sécurité pour une raison difficile à défendre.

4) Sur Linux, pourquoi l’OS dit-il « tainting kernel » ?

« Taint » signifie que le noyau se marque comme exécutant du code qui ne répond pas à ses attentes habituelles de support ou de politique (souvent propriétaire ou non signé).
C’est un signal de debugging/support. Dans les environnements Secure Boot + lockdown, vous n’atteindrez souvent même pas le stade du « taint »—le module est bloqué net.

5) Quelle est la différence entre signer le module et enrôler la clé ?

Signer attache une signature cryptographique au module. Enrôler la clé indique à la plateforme quelles clés publiques elle doit considérer comme dignes de confiance pour la vérification
des modules. Vous avez besoin des deux : un module signé et un signataire de confiance.

6) Pourquoi les pilotes DKMS causent-ils tant d’incidents ?

DKMS automatise la reconstruction des modules quand le noyau change. C’est pratique, mais cela introduit une nouvelle étape : le module reconstruit doit être signé à chaque fois.
Sans automatisation, le premier redémarrage après une mise à jour du noyau devient un test de production de votre discipline de signature.

7) Comment les révocations de certificats cassent-elles des pilotes « signés » ?

La confiance ne se résume pas à avoir une signature ; il s’agit que le signataire soit acceptable aujourd’hui. Si un certificat de signature est révoqué, ou si une racine
devient non digne de confiance, l’OS peut rejeter les binaires signés par celui-ci. Les mises à jour de révocation firmware (dbx) peuvent aussi invalider des composants auparavant acceptés.

8) Pourquoi Windows montre Code 52 et Linux « Required key not available » ?

Différentes plateformes, même thème : le code en mode noyau doit se valider contre une chaîne de confiance. Windows l’affiche via des codes d’erreur PnP et des journaux d’événements ;
Linux le révèle via dmesg/journal et des messages d’erreur de chargement de module.

9) Comment prévenir la dérive « ça marche sur certains hôtes » ?

Traitez la politique de démarrage comme de la configuration, pas comme une personnalité : standardisez les réglages firmware, enregistrez l’état Secure Boot, gérez les clés enrôlées centralement,
et assurez-vous que chaque hôte utilise les mêmes paquets pilotes et le même workflow de signature. Les flottes à politique mixte sont des incubateurs de pannes.

10) Si les signatures ne garantissent pas la qualité, pourquoi s’en soucier ?

Parce que les signatures vous donnent une frontière de confiance contrôlée et de la responsabilisation. Elles empêchent du code noyau arbitraire de se charger silencieusement,
réduisent la surface d’attaque, et imposent un processus. Le processus est justement le but.

Conclusion : actions suivantes pour éviter la prochaine panne « matériel mystère »

Les pannes causées par des pilotes non signés sont le pire genre d’embarras opérationnel : le matériel est sain, la fenêtre de changement fond, et la réparation ressemble à argumenter avec un videur
sur un code vestimentaire que vous ne connaissiez pas. Le remède n’est pas héroïque. C’est de la gouvernance.

Faites ces étapes ensuite, dans cet ordre :

Inventoriez l’état politique sur l’ensemble du parc : Secure Boot, lockdown, clés enrôlées.
Identifiez les pilotes « must-load » pour le stockage, le réseau, le GPU et les systèmes de fichiers ; explicitez-les.
Ajoutez des vérifications préalables au patching : vérifier que les modules existent, que le vermagic correspond, que le signataire correspond à une clé enrôlée.
Automatisez la signature pour DKMS et tous les modules hors arbre ; traitez les clés de signature comme des secrets de production.
Testez les redémarrages dans un environnement qui reflète la politique de production, pas un lab permissif.
Documentez et limitez le casse-glace. Si vous désactivez l’application, planifiez et exécutez le travail de réactivation avant que cela ne devienne « notre façon de faire ».

La sécurité n’a pas cassé votre matériel. Votre cycle de vie des pilotes l’a fait. Corrigez le cycle de vie, et le matériel redeviendra ennuyeux—ce que la production mérite exactement.