La construction de modules de noyau hors-arbre n'est généralement pas recommandée pour les débutants comme moi afin d'éviter des problèmes comme les suivants vermagic inadéquation :
config MODVERSIONS
...
Habituellement, vous devez utiliser les modules compilés avec votre noyau. Le fait de dire Y ici rend parfois possible l'utilisation de modules compilés pour des noyaux différents, en ajoutant suffisamment d'informations aux modules pour (avec un peu de chance) repérer tout changement qui les rendrait incompatibles avec le noyau que vous utilisez.
De même, le avertissement :
le chargement d'un module hors-arbre entache le noyau
Chargement forcé des modules peut conduire à des situations telles que Symboles / références non définis (fonctions / variables exporté et disponible sur /proc/kallsyms ).
J'ai fait des recherches et j'ai découvert que vous devez signer le module pour le charger.
...
Mais cela n'a pas non plus de sens quand je pense à la façon dont n'importe quel développeur pourrait étendre le noyau en écrivant des modules si cette barrière est en place.
C'est le comportement souhaité :
La signature des modules augmente la sécurité en rendant plus difficile le chargement d'un module malveillant dans le noyau.
Et c'est pourquoi MODULE_SIG_FORCE est là. Sur les PC UEFI Secure Boot exige nécessairement que le noyau et les modules soient signés dans le cadre de la chaîne de démarrage sécurisée. Le système Android Verified Boot signes entiers boot mais qui ensuite - en utilisant dm-verity - sécurise /system y /vendor les partitions qui peuvent éventuellement inclure les modules chargeables du noyau. La signature des modules ne semble donc pas nécessaire :
La signature du module n'est pas obligatoire et n'est pas testée par rapport aux critères suivants
Citation tirée de Modules de noyau chargeables .
Je suppose qu'il n'y a aucun moyen d'obtenir la clé privée que le noyau a utilisée à l'origine lors de la compilation.
Vous avez raison. La paire de clés publique / privée est générée (en utilisant openssl ) lors de la construction du noyau. La clé publique est intégrée au noyau et peut être consultée dans le fichier /proc/keys ou par :
~# keyctl list %:.system_keyring
Si le noyau a été construit avec IKCONFIG_PROC L'algorithme de hachage peut être vu comme suit :
~# zcat /proc/config.gz | grep MODULE_SIG_HASH
Un script perl fait également partie de l'arbre des sources du noyau et peut être utilisé pour signer les modules :
~$ sign-file <algorithm> <priv_key_file> <pub_key_file> <module>.ko
Existe-t-il un moyen de désactiver l'application de la signature du noyau et de charger le module que j'ai créé ?
Non.
Sinon, puis-je d'une manière ou d'une autre signer mon module et le charger ?
Demandez au développeur du noyau de fournir la même clé privée (si possible), sinon la seule option est de reconstruire le noyau entier. Obtenez la configuration du noyau en cours d'exécution à partir de /proc/config.gz si elle est disponible et requise. N'oubliez pas de désactiver CONFIG_MODULE_SIG ou mettre CONFIG_MODULE_SIG_ALL .
SOURCE : Construction de modules externes
