Comment installer des modules de noyau personnalisés sur SLES 15 avec démarrage sécurisé

Pour charger un module noyau personnalisé sur SLES 15 avec le démarrage sécurisé activé, compilez-le pour le noyau exact que vous utiliserez, signez le .kofichier final avec un certificat de signature de confiance, enregistrez ce certificat comme clé de propriétaire de la machine (MOK), puis chargez le module modprobe. Une MOK est un certificat contrôlé localement auquel le shim SUSE et le noyau Linux peuvent se fier pour la vérification des modules de démarrage sécurisé. Ne désactivez pas le démarrage sécurisé pour contourner une signature rejetée. La procédure ci-dessous est destinée à un administrateur qui contrôle la machine et peut approuver l'enregistrement d'une clé au redémarrage.

Ce guide suit la documentation d'administration de SLES 15 SP7 et les recommandations de SUSE concernant l'empaquetage des modules du noyau (vérifiées le 6 octobre 2026). Les commandes utilisent acme_driverun nom de module d'exemple ; remplacez-le par le nom réel du module sans le .kosuffixe, le cas échéant. Il s'agit d'exemples de commandes, et non de résultats de tests sur un système hôte.

Lorsque cette méthode est la plus appropriée

Utilisez cette méthode pour un module personnalisé hors du noyau (fourni séparément du noyau en cours d'exécution) lorsque vous pouvez recompiler ou obtenir une version du noyau SLES cible et enregistrer un certificat sur le serveur. Elle s'applique aux systèmes démarrant via le démarrage sécurisé SUSE et le chemin d'installation simplifié. Si un fournisseur propose un package de pilotes SLES 15 officiel, suivez d'abord ses instructions d'installation et de signature ; un package fourni par le fournisseur peut mieux gérer la compatibilité et les mises à jour du noyau qu'une copie manuelle.

Le démarrage sécurisé valide la chaîne de démarrage, et le noyau vérifie également les signatures des modules chargeables conformément à la politique applicable. Un module peut être signé et pourtant ne pas se charger s'il cible une ABI noyau différente, s'il dépend de symboles manquants ou s'il est compilé pour une architecture incorrecte. Inversement, la correspondance avec le noyau ne rend pas un module non signé fiable. La signature renforce la confiance ; elle n'établit pas la compatibilité ni ne certifie la sécurité du code.

Avant de commencer

• Utilisez un compte administrateur et assurez-vous de disposer d'une fenêtre de maintenance. L'inscription MOK nécessite un redémarrage et une approbation dans MokManager, généralement via une console locale ou distante.
• Vérifiez l'état du noyau en cours d'exécution et du démarrage sécurisé à l'aide des commandes `sudo uname -rapt mokutil --sb-state-get` et `sudo apt-get`. Compilez le module en utilisant les fichiers de développement du noyau et la chaîne d'outils correspondants à cette version du noyau. Les noms des paquets et les fichiers requis varient selon le Service Pack SLES, la version du noyau et la méthode de compilation ; vérifiez-les donc dans les dépôts activés sur le système cible.
• Déterminez l'emplacement de stockage de la clé de signature privée. Pour un parc de production, utilisez le service de signature contrôlé de l'organisation ou le processus de gestion des clés approuvé. Pour un laboratoire ou un hôte unique et contrôlé, une clé générée localement peut être une solution pratique. Protégez la clé privée ; le serveur a besoin du certificat public pour l'inscription, et non de la clé privée.
• Conservez une méthode de récupération, le code source du module ou le package du fournisseur, ainsi qu'un noyau fonctionnel. Ne chargez pas de pilote sur du matériel de production tant que vous n'en comprenez pas les exigences matérielles et de noyau.

1. Créez une clé de signature et un certificat public

Sur un système de signature protégé, créez une clé privée et un certificat X.509 encodé en DER. Les recommandations de SUSE concernant l'empaquetage des modules du noyau préconisent l' codeSigningutilisation d'une clé étendue sur les Service Packs SLES 15 actuels. Cet exemple utilise OpenSSL et un nom de certificat descriptif :

openssl req -new -x509 -newkey rsa:2048 -sha256 \
  -keyout module-signing.key \
  -out module-signing.der -outform DER -nodes \
  -days 4745 -addext "extendedKeyUsage=codeSigning" \
  -subj "/CN=Custom Module Signing/"
chmod 600 module-signing.key

Cette -nodesoption laisse la clé privée non chiffrée ; par conséquent, les permissions d’accès aux fichiers et les contrôles de stockage sont essentiels. Ne copiez pas cette clé privée sur un serveur généraliste et ne l’intégrez pas à un package. Si la politique de l’organisation exige une clé chiffrée, une signature matérielle, une rotation des clés ou un cycle de vie des certificats différent, respectez cette politique et les exigences de l’outil de signature. Transférez la clé uniquement module-signing.dervers le système qui enregistrera la clé publique.

2. Compilez le module pour le noyau cible et signez-le.

Compilez le module avec la version exacte du noyau indiquée par `npm install` uname -r. Les instructions de compilation du projet source déterminent le compilateur, les en-têtes et la configuration nécessaires ; il n'existe pas de commande de compilation unique compatible avec tous les modules personnalisés. Consultez les résultats vermagicavec modinfo`npm install` si vous devez diagnostiquer une incompatibilité de noyau.

Signez le fichier module final après la compilation et toute étape d'empaquetage ou de suppression de données. SUSE documente son outil de signature à l'adresse suivante/usr/lib/rpm/pesign/kernel-sign-file ; l'exemple suivant utilise le format PKCS#7 et le hachage SHA-256 :

/usr/lib/rpm/pesign/kernel-sign-file -i pkcs7 sha256 \
  module-signing.key module-signing.der acme_driver.ko

L'utilitaire doit être disponible via l'intégration de signature SUSE sur votre système. S'il est absent, consultez la documentation officielle SLES/KMP et les dépôts activés pour la configuration de signature prise en charge, au lieu d'utiliser une commande de signature arbitraire. Une signature de module est ajoutée au fichier. Après la signature, ne supprimez, ne modifiez, ne recompressez ni n'altérez le module de quelque manière que ce soit ; une telle modification pourrait invalider la signature. Conservez une copie intacte du fichier de compilation afin de pouvoir répéter l'étape de signature finale.

3. Inscrire le certificat public en tant que MOK

Sur le serveur SLES, placez le module-signing.dercertificat public à un emplacement où l'utilisateur root peut le lire, puis mettez-le en file d'attente pour l'inscription :

mokutil --root-pw --import module-signing.der
mokutil --list-new

La documentation SUSE --root-pwindique qu'il est possible d'autoriser l'inscription en attente avec le mot de passe root. La commande d'importation met le certificat en file d'attente ; elle ne l'inscrit pas immédiatement. Redémarrez le serveur. Dans MokManager, choisissez « Inscrire la clé depuis le disque » , sélectionnez le certificat, confirmez l'inscription et terminez l'autorisation demandée. Le libellé du menu peut légèrement varier selon la version de shim/MokManager. Si vous ne pouvez pas accéder à l'écran d'inscription, vérifiez le chemin de démarrage et configurez l'accès à la console ; ne présumez pas que le certificat a été inscrit simplement parce que la commande d'importation a réussi.

Une fois le serveur démarré, vérifiez que la clé apparaît bien dans la liste des éléments inscrits :

mokutil --list-enrolled

4. Installez, actualisez les dépendances du module et chargez-le.

Copiez le fichier signé dans le répertoire extra-modules du noyau en cours d'exécution, actualisez la table des dépendances et chargez le module par son nom. Remplacez la version du noyau si vous installez le module pour un noyau différent.

release=$(uname -r)
install -D -m 0644 acme_driver.ko \
  "/lib/modules/$release/extra/acme_driver.ko"
depmod -a "$release"
modprobe acme_driver

modprobeIl est généralement préférable d'utiliser `systemctl install` insmodcar cela résout les dépendances entre modules. Testez le périphérique ou la fonctionnalité fournie par le pilote ; une commande réussie ne prouve pas à elle seule le bon fonctionnement du matériel. Si le module doit être chargé au démarrage, ajoutez son nom sur une ligne distincte dans un fichier tel que ` /etc/modules-load.d/acme_driver.confsystemctl install`. SLES utilise le mécanisme de chargement de modules de systemd pour ces fichiers de configuration.

5. Vérifier le chemin de confiance et résoudre les problèmes liés aux défaillances

Les vérifications utiles comprennent :

mokutil --list-enrolled
modinfo -F signer /lib/modules/$(uname -r)/extra/acme_driver.ko
lsmod | grep acme_driver
journalctl -k -b | tail -n 80

modinfo -F signerAffiche les métadonnées du signataire intégrées au module. À elle seule, cette commande ne prouve ni que le certificat est enregistré ni que le noyau en cours d'exécution a accepté la signature. Une vérification réussie modprobeavec le démarrage sécurisé activé, suivie d'une analyse des journaux du noyau et d'un test fonctionnel du périphérique, constitue une preuve plus pertinente. La sortie du terminal affichée dans la figure est un exemple de commandes et de résultats illustratifs, et non un compte rendu de test réalisé pour cet article.

SUSE vérifie également si un module est pris en charge, et le chargement d'un module non pris en charge peut affecter l'état de prise en charge ou l'état de contamination du noyau. Cette politique est indépendante de la vérification de signature : modifier le paramètre relatif aux modules non pris en charge n'entraîne pas l'enregistrement d'une clé de signature et ne corrige pas une signature rejetée. Consultez les recommandations de SUSE avant de modifier ce paramètre sur un système de production pris en charge.

Planifiez les mises à jour du noyau et les déploiements répétés

Un module conçu pour une version de noyau n'est pas automatiquement compatible avec la suivante. Après une mise à jour du noyau, installez l'environnement de compilation correspondant, recompilez le module pour la nouvelle ABI du noyau, signez le fichier final, installez-le dans l'arborescence des modules de ce noyau et actualisez ses dépendances. Si le certificat de signature est toujours valide, il n'est généralement pas nécessaire de le réenregistrer. Un certificat de remplacement ou renouvelé requiert sa propre inscription et approbation. Testez le nouveau noyau et le module ensemble avant de vous fier au chargement automatique au démarrage.

Pour une flotte ou un pilote nécessitant des mises à jour régulières, utilisez un processus de packaging reproductible tel que l'approche KMP (Kernel Module Package) de SUSE, lorsqu'elle est adaptée à votre pilote et à votre modèle de support. Le packaging permet d'organiser les étapes de compilation et de signature pour chaque noyau, mais ne dispense pas d'une protection correcte des clés, de la compatibilité des modules, de la confiance accordée aux clés d'activation (MOK) et des tests de mise à jour. Consultez la documentation pour connaître la version exacte du Service Pack SLES 15 et le cycle de vie du noyau pris en charge par votre organisation.

Références officielles

• Guide d'administration de SUSE Linux Enterprise Server 15 SP7 — Démarrage sécurisé et inscription MOK, chargement de modules et politique relative aux modules non pris en charge.
• Manuel des packages de modules du noyau SUSE — Processus de signature KMP et exigences de signature applicables à SLES 15.
• Documentation sur la signature des modules du noyau Linux — comportement de la signature du noyau et contraintes sur les fichiers de modules signés.