Installation et signature de modules de noyau personnalisés sur SLES 15 Secure Boot

Un pilote tiers sur SUSE Linux Enterprise Server 15 peut se compiler correctement mais ne pas se charger avec l'erreur « Clé requise non disponible » ou « Clé rejetée par le service ». Lorsque le démarrage sécurisé UEFI exige la signature des modules, la solution consiste à signer le module noyau personnalisé avec un certificat de confiance, à enregistrer ce certificat via la gestion des clés du propriétaire de la machine (MOK), puis à charger le module normalement, sans désactiver le démarrage sécurisé.

Cette procédure suppose un système SLES 15 UEFI standard utilisant SUSE shim, un kernel-defaultnoyau, des droits d'administrateur et une source fiable pour votre pilote. Elle traite .kodes modules personnalisés, mais pas de la signature d'un noyau de remplacement ni de la modification des clés de plateforme du firmware. Les exemples suivent le modèle d'administration SLES 15 SP6/SP7 ; vérifiez les différences de paquets et de noyaux selon votre Service Pack installé.

1. Vérifiez d'abord le démarrage sécurisé et le noyau en cours d'exécution.

Connectez-vous avec des droits d'administrateur et identifiez le noyau que vous avez effectivement démarré. Un nom de paquet correspondant ne prouve pas à lui seul qu'un module peut être chargé dans ce noyau.

uname -r
mokutil --sb-state
ls -ld "/lib/modules/$(uname -r)/build"

Si mokutille démarrage sécurisé est activé, une signature non approuvée est une explication probable de l'échec de chargement lié aux clés. S'il est désactivé, recherchez d'autres causes avant de générer des clés ; l'application explicite des signatures du noyau peut également avoir une incidence. Consultez le journal du noyau après un échec de chargement pour obtenir le message de rejet exact.

sudo journalctl -k -b --no-pager | tail -n 50

Vérifiez le module candidat avant de l'installer. Remplacez l'exemple par le nom de fichier réel ; celui-ci vermagicdoit correspondre à la version du noyau en cours d'exécution et aux propriétés de compilation compatibles.

modinfo -F name /path/to/mydriver.ko
modinfo -F vermagic /path/to/mydriver.ko

2. Utilisez un package de pilotes pris en charge ou créez un module correspondant

Commencez par demander au fournisseur du matériel ou du logiciel un package de module noyau (KMP) compatible SLES et déjà signé. Cette solution est préférable à l'installation manuelle d'un fichier binaire : le fournisseur peut proposer la gestion des mises à jour du noyau et une procédure d'enregistrement de certificat documentée. La signature du fournisseur n'est pas automatiquement approuvée sur toutes les machines compatibles avec le démarrage sécurisé.

Si vous devez compiler le pilote, installez les fichiers de développement correspondant à votre noyau. kernel-defaultLes paquets SLES standard incluent généralement le paquet de développement du noyau par défaut, les fichiers de développement du noyau et les outils de compilation. La disponibilité des dépôts et les versions dépendent de l'enregistrement et des modules SLES activés.

sudo zypper install gcc make openssl mokutil kernel-devel kernel-default-devel
rpm -q kernel-default-devel kernel-devel
readlink -f "/lib/modules/$(uname -r)/build"

Si le répertoire de compilation est manquant ou si le paquet de développement cible une version de noyau différente, corrigez d'abord l'incompatibilité entre le paquet et le noyau. Un noyau nouvellement installé peut nécessiter un redémarrage contrôlé avant la compilation.

À partir du répertoire source du pilote de confiance, suivez les instructions de compilation du fournisseur. Pour les modules classiques basés sur kbuild, la commande ci-dessous effectue une compilation avec le noyau en cours d'exécution ; elle ne télécharge ni ne crée de pilote.

cd /path/to/driver-source
make -C "/lib/modules/$(uname -r)/build" M="$PWD" modules

Évitez la compilation si vous disposez déjà d'une version compatible .koprovenant d'un fournisseur de confiance. Ne forcez jamais le chargement d'un module avec une signature incorrectevermagic ; une signature ne peut pas réparer un binaire incompatible.

3. Créez la clé de signature et signez le module installé

Générez une clé RSA dédiée et un certificat X.509 dans un répertoire réservé à l'utilisateur root. Le certificat public sera enregistré ; la clé privée doit rester protégée car quiconque la contrôle peut signer des modules supplémentaires auxquels cette machine pourrait faire confiance.

sudo -i
umask 077
mkdir -p /root/module-signing
cd /root/module-signing
openssl req -new -x509 -newkey rsa:3072 -sha256 -days 3650 -nodes \
  -subj "/CN=SLES Custom Module Signing/" \
  -keyout MOK.priv -out MOK.pem
openssl x509 -in MOK.pem -outform DER -out MOK.der
chmod 600 MOK.priv

-nodesCet exemple simple génère une clé privée non chiffrée ; pour un processus de signature en production, utilisez une clé chiffrée correctement protégée ou un service de signature externe conforme à votre politique de sécurité. La durée de validité de dix ans indiquée ici est donnée à titre indicatif et ne constitue pas une recommandation quant à la durée de vie des certificats au sein d'une organisation.

Copiez le module finalisé dans le répertoire des modules du noyau en cours d'exécution. Signez le fichier installé après toute modification (empaquetage, suppression de code superflu, etc.). Remplacez `<module>` mydriveret son chemin par le nom de base et l'emplacement réels du module.

install -D -m 0644 /path/to/mydriver.ko \
  "/lib/modules/$(uname -r)/extra/mydriver.ko"
SIGN_FILE="$(readlink -f /lib/modules/$(uname -r)/build)/scripts/sign-file"
test -x "$SIGN_FILE" || echo "Locate the sign-file binary for this kernel"
"$SIGN_FILE" sha256 /root/module-signing/MOK.priv \
  /root/module-signing/MOK.der \
  "/lib/modules/$(uname -r)/extra/mydriver.ko"
modinfo -F signer "/lib/modules/$(uname -r)/extra/mydriver.ko"

Si sign-filel'outil est absent à cet emplacement, recherchez celui fourni avec vos fichiers de compilation du noyau plutôt que de copier une version non compatible. La présence d'un signataire indique que le fichier contient des métadonnées de signature ; cela ne prouve pas que le signataire a été enregistré. Ne supprimez ni ne modifiez jamais le module après sa signature.

4. Enregistrez le certificat public à l'aide de MOK.

Importez le certificat public au format DER (et non le certificat standard MOK.priv) et définissez le mot de passe d'inscription unique demandé mokutil. Configurez l'accès à la console avant de redémarrer ; l'autorisation s'effectue dans l'interface MokManager au démarrage, et non dans un shell SSH.

mokutil --import /root/module-signing/MOK.der
mokutil --list-new
reboot

Au prochain démarrage, sélectionnez « Enregistrer MOK » , suivez les instructions de confirmation, saisissez le mot de passe à usage unique et poursuivez le démarrage. L’apparence du menu dépend de la version du firmware et du shim. Si vous retournez sous Linux sans confirmer l’enregistrement, le nouveau certificat ne sera pas considéré comme fiable.

Après le démarrage, vérifiez que le certificat spécifique est bien enregistré :

sudo mokutil --test-key /root/module-signing/MOK.der
sudo mokutil --list-enrolled

5. Chargez le module signé et isolez les erreurs restantes.

Met à jour les métadonnées des dépendances du module et charge ce dernier par son nom, et non par son chemin d'accès complet. modprobeRésout les dépendances et respecte la configuration standard des modules.

sudo depmod -a
sudo modprobe mydriver
lsmod | grep -w mydriver
modinfo -F signer mydriver

Si le chargement échoue toujours, choisissez l'action corrective qui correspond aux éléments de preuve :

• Clé rejetée ou clé requise indisponible : relancezmokutil --test-key ; vérifiez que le fichier installé est bien celui qui est signé et vérifiez si une mise à jour du pilote l’a remplacé.
• Format de module invalide : comparez modinfo -F vermagicavec uname -r, reconstruisez pour le noyau actif et vérifiez l’architecture du processeur.
• Symbole inconnu ou dépendance manquante : inspectez journalctl -k -bles modules requis par le fournisseur et l’ABI du noyau ; une autre signature ne corrigera pas les symboles manquants.

Pour les pilotes de stockage ou réseau critiques au démarrage, effectuez d'abord des tests sur un système hors production et assurez-vous qu'une console de récupération est disponible. Configurez le chargement automatique uniquement lorsque le pilote fonctionne de manière fiable ; consultez la documentation SUSE /etc/modules-load.d/pour les modules qui ne se chargent pas automatiquement lors de la détection du périphérique.

Vérifiez le résultat après un redémarrage

Redémarrez une nouvelle fois pendant votre fenêtre de maintenance si le chargement persistant est important. Vérifiez que le démarrage sécurisé est toujours activé, que la clé publique est enregistrée, que le module est présent et que le noyau ne signale aucune nouvelle erreur de vérification ou de compatibilité. Recompilez ou réinstallez et signez la version mise à jour .koaprès les mises à niveau du noyau ou des pilotes du fournisseur.

mokutil --sb-state
sudo mokutil --test-key /root/module-signing/MOK.der
modinfo -F signer mydriver
lsmod | grep -w mydriver
sudo journalctl -k -b --no-pager | tail -n 30

Documentation principale : SUSE SLES 15 SP6 : UEFI et clés de propriétaire de la machine ; SUSE : Gestion des modules du noyau ; Noyau Linux : Fonctionnalité de signature des modules ; Noyau Linux : Compilation de modules externes . Le guide d’administration de SLES 15 SP6 a été mis à jour le 17 septembre 2026 ; le comportement des commandes pour les installateurs de pilotes tiers et les distributions de noyau non standard doit être vérifié auprès de leurs responsables.