La commande Linux / Unix insmod installe un module chargeable dans le noyau en cours d’exécution.insmod tente de lier un module au noyau en cours d'exécution en résolvant tous les symboles de la table de symboles exportée du noyau.
Si le nom du fichier du module est donné sans répertoire ni extension,insmod cherchera le module dans des répertoires par défaut courants. La variable d'environnementMODPATH peut être utilisé pour remplacer cette valeur par défaut. Si un fichier de configuration de module tel que/etc/modules.conf existe, il remplacera les chemins définis dansMODPATH.
La variable d'environnementMODULECONF peut également être utilisé pour sélectionner un fichier de configuration différent de celui par défaut/etc/modules.conf (ou/etc/conf.modules (obsolète)). Cette variable d'environnement remplacera toutes les définitions ci-dessus.
Quand variable d'environnementUNAME_MACHINE est défini, modutils utilisera sa valeur à la place du champ machine du syscall uname (). C’est surtout utile lorsque vous compilez des modules 64 bits dans un espace utilisateur 32 bits ou inversement, définissezUNAME_MACHINE au type des modules. Les modutils actuels ne prennent pas en charge le mode de construction transversale complet pour les modules, il se limite à choisir entre les versions 32 et 64 bits de l'architecture hôte.
Les options
-e nom persistant , --persister= nom persistant
Spécifie où toutes les données persistantes du module sont lues lors du chargement et écrites lorsque cette instanciation du module est déchargée. Cette option est ignorée si le module ne contient aucune donnée persistante. Les données persistantes ne sont lues que parinsmod si cette option est présente, par défautinsmod ne traite pas les données persistantes.
En forme abrégée,-e "" (une chaîne vide) est interprété parinsmod comme la valeur depersister tel que défini dansmodules.conf, suivi du nom du fichier du module par rapport au chemin de recherche du module dans lequel il a été trouvé, moins les ".gz", ".o" ou ".mod" suivants. Simodules.conf précise "persistdir =" (c'est à dire.persister est un champ vide), cette forme abrégée est ignorée en silence. (Voirmodules.conf (5).)
-F, --Obliger
Essayez de charger le module même si la version du noyau en cours d'exécution et la version du noyau pour laquelle le module a été compilé ne correspondent pas. Cela ne fait que remplacer la vérification de version du noyau, cela n'a aucun effet sur les vérifications de noms de symboles. Si les noms de symbole dans le module ne correspondent pas au noyau, il n’ya aucun moyen de forcerinsmod charger le module.
-h, --Aidez-moi
Affiche un résumé des options et quitte immédiatement.
-k, --autoclean
Définissez l'indicateur de nettoyage automatique sur le module. Ce drapeau sera utilisé parKerneld(8) supprimer les modules qui n'ont pas été utilisés depuis un certain temps, généralement une minute.
-L, --fermer à clé
Utilisationtroupeau(2) pour éviter les charges simultanées du même module.
-m, --carte
Génère une carte de chargement sur stdout, facilitant le débogage du module en cas de panique du noyau.
-n, --noload
Exécuter factice, tout faire sauf charger le module dans le noyau. Si demandé par un-m ou-O, l’exécution produira une carte ou un fichier blob. Le module n'étant pas chargé, l'adresse de chargement réelle du noyau étant inconnue, la carte et le fichier blob sont basés sur une adresse de chargement arbitraire de 0x12340000.
-o nom_module , --prénom= nom_module
Nommez explicitement le module plutôt que de dériver le nom du nom de base du fichier d'objet source.
-O nom_blob , --goutte= nom_blob
Enregistrez l'objet binaire dans nom_blob . Le résultat est un blob binaire (sans en-tête ELF) montrant exactement ce qui est chargé dans le noyau après la manipulation et le déplacement de la section. Option-m est recommandé pour obtenir une carte de l'objet.
-p, --sonde
Sondez le module pour voir s'il peut être chargé avec succès. Cela inclut la localisation du fichier objet dans le chemin du module, la vérification des numéros de version et la résolution des symboles. Il ne vérifie pas les délocalisations ni ne produit de fichier de carte ou de blob.
-P préfixe , --préfixe= préfixe
Cette option peut être utilisée avec les modules versionnés pour un noyau SMP ou Bigmem, car ces modules ont un préfixe supplémentaire ajouté dans leurs noms de symbole. Si le noyau a été construit avec des versions de symboles, alorsinsmod extraira automatiquement le préfixe de la définition de "get_module_symbol" ou "inter_module_get", dont l'un doit exister dans tout noyau prenant en charge les modules. Si le noyau n'a pas de version de symbole mais que le module a été construit avec des versions de symbole, l'utilisateur doit fournir-P.
-q, --silencieux
N'imprimez pas de liste de symboles non résolus. Ne vous plaignez pas de non concordance de version. Le problème ne sera reflété que dans le statut de sortie deinsmod.
-r, --racine
Certains utilisateurs compilent les modules sous un ID utilisateur non-root, puis les installent en tant que root. Ce processus peut laisser les modules appartenant à l'ID utilisateur non root, même si le répertoire des modules appartient à root. Si l'ID utilisateur non root est compromis, un intrus peut écraser les modules existants appartenant à cet ID utilisateur et utiliser cette exposition pour initialiser un accès root.
Par défaut, modutils refusera les tentatives d'utilisation d'un module n'appartenant pas à root. En précisant -r basculera la vérification et autorisera root à charger des modules n'appartenant pas à root.
Remarque: La valeur par défaut de la vérification racine peut être modifiée lorsque modutils est configuré.L'utilisation de -r pour désactiver la vérification racine ou définir le paramètre par défaut sur "aucune vérification racine" au moment de la configuration est un risque majeur pour la sécurité et n'est pas recommandé.
-s, --syslog
Tout sortie àsyslog(3) au lieu du terminal.
-S, --callsyms
Forcer le module chargé à avoirkallsyms données, même si le noyau ne les prend pas en charge. Cette option est pour les petits systèmes où le noyau est chargé sanskallsyms données mais les modules sélectionnés ont besoinkallsyms pour le débogage. Cette option est la valeur par défaut sous Red Hat Linux.
-v, --verbeux
Soyez prolixe.
-V, --version
Afficher la version deinsmod.
-X, --exportation; -X, --noexport
Effectuez et n'exportez pas tous les symboles externes du module, respectivement. Par défaut, les symboles doivent être exportés. Cette option est effective uniquement si le module n'exporte pas explicitement sa propre table de symboles contrôlée et est donc obsolète.
-Y, --ksymoops; -y, --noksymoops
Faire et ne pas ajouterksymoops symboles pour ksyms. Ces symboles sont utilisés parksymoops pour fournir un meilleur débogage s'il y a un Oops dans ce module. La valeur par défaut est pour leksymoopssymboles à définir. Cette option est indépendante de la-X/-X options.
ksymoops les symboles ajoutent environ 260 octets par module chargé. À moins que vous ne manquiez vraiment d'espace dans le noyau et que vous essayiez de réduire ksyms à sa taille minimale, prenez le paramètre par défaut et obtenez un débogage Oups plus précis.ksymoops des symboles sont nécessaires pour enregistrer les données de module persistantes.
-N, --numérique seulement
Vérifiez uniquement la partie numérique de la version du module par rapport à la version du noyau, c’est-à-dire que vous ignorez EXTRAVERSION lorsque vous décidez si un module appartient à un noyau. Cet indicateur est automatiquement défini pour le noyau 2.5 et ultérieur, il est facultatif pour les noyaux précédents.
Paramètres du module
Certains modules acceptent des paramètres de temps de chargement pour personnaliser leur fonctionnement. Ces paramètres sont souvent des ports d'E / S et des numéros d'IRQ qui varient d'un ordinateur à l'autre et ne peuvent pas être déterminés à partir du matériel.
Dans les modules conçus pour les noyaux de la série 2.0, tout symbole de pointeur entier ou caractère peut être traité en tant que paramètre et modifié. À partir des noyaux de la série 2.1, les symboles sont explicitement marqués en tant que paramètres afin que seules des valeurs spécifiques puissent être modifiées. De plus, des informations de type sont fournies pour vérifier les valeurs fournies au moment du chargement.
Dans le cas d'entiers, toutes les valeurs peuvent être en décimal, octal ou hexadécimal à la C: 17, 021 ou 0x11. Les éléments de tableau sont des séquences spécifiées séparées par des virgules. Les éléments peuvent être ignorés en omettant la valeur.
Dans les modules de la série 2.0, les valeurs qui ne commencent pas par un nombre sont considérées comme des chaînes. À partir de la version 2.1, les informations de type du paramètre indiquent s'il faut interpréter la valeur en tant que chaîne. Si la valeur commence par des guillemets doubles ('), la chaîne est interprétée comme en C, séquences d'échappement et tout. Notez que depuis l'invite du shell, les citations elles-mêmes peuvent avoir besoin d'être protégées de l'interprétation du shell.
Modules et symboles sous licence GPL
À partir du noyau 2.4.10, les modules doivent avoir une chaîne de licence, définie à l'aide deMODULE_LICENSE (). Plusieurs chaînes sont reconnues compatibles avec la GPL; Toute autre chaîne de licence ou aucune licence signifie que le module est considéré comme propriétaire.
Si le noyau supporte le/ proc / sys / kernel / tainted drapeau alorsinsmod OU le drapeau corrompu avec «1» lors du chargement d’un module sans licence GPL. Un avertissement est émis si le noyau prend en charge l’altération et si un module est chargé sans licence. Un avertissement est toujours émis pour les modules qui ont uneMODULE_LICENSE () ce n'est pas compatible avec la GPL, même sur les noyaux plus anciens qui ne supportent pas les altérations. Cela minimise les avertissements lorsqu'un nouveau modutils est utilisé sur des noyaux plus anciens.
insmod -f (force) sera OU le drapeau corrompu avec '2' sur les noyaux supportant la corruption. Il émet toujours un avertissement.
Certains développeurs du noyau exigent que les symboles exportés par leur code ne soient utilisés que par des modules disposant d'une licence compatible GPL. Ces symboles sont exportés parEXPORT_SYMBOL_GPL au lieu de la normaleEXPORT_SYMBOL. Les symboles uniquement GPL exportés par le noyau et d’autres modules ne sont visibles que par les modules disposant d’une licence compatible GPL. Ces symboles apparaissent dans/ proc / ksyms avec un préfixe 'GPLONLY_'. insmod ignore leGPLONLY_ préfixe sur les symboles lors du chargement d'un module sous licence GPL afin que le module fasse simplement référence au nom de symbole normal, sans le préfixe. Les symboles uniquement GPL ne sont pas mis à la disposition des modules sans licence compatible GPL, cela inclut les modules sans licence.
Ksymoops Assistance
Pour aider au débogage du noyau Oops lors de l’utilisation de modules,insmod Par défaut, certains symboles sont ajoutés à ksyms, voir le-Y option. Ces symboles commencent par__insmod_ nom_module_ . le nom de module est nécessaire pour rendre les symboles uniques. Il est légal de charger le même objet plusieurs fois sous différents noms de modules. Actuellement, les symboles définis sont:
__insmod_ nom de module _ Oobjectfile _ Mmtime _ Vversion
objectfile est le nom du fichier à partir duquel l'objet a été chargé. Cela garantit que ksymoops peut associer le code au bon objet. mtime est le dernier horodatage modifié sur ce fichier en hexadécimal, zéro si stat a échoué version est la version du noyau pour laquelle le module a été compilé, -1 si aucune version n'est disponible. le_O Le symbole a la même adresse de départ que l'en-tête du module.
__insmod_ nom de module _ Nom_section _ Longueur
Ce symbole apparaît au début des sections ELF sélectionnées, actuellement .text, .rodata, .data, .bss et .sbss. Il n'apparaît que si la section a une taille non nulle. Nom de la section est le nom de la section ELF, longueur est la longueur de la section en décimal. Ces symboles aident ksymoops à mapper les adresses sur des sections lorsqu'aucun symbole n'est disponible.
__insmod_ nom de module _Persistent_ nom de fichier
Seulement créé parinsmod si le module a un ou plusieurs paramètres marqués comme données persistantes et un nom de fichier pour enregistrer les données persistantes (voir-e, ci-dessus) est disponible.
L’autre problème avec le débogage du noyau Oops dans les modules est que le contenu de / proc / ksyms et / proc / modules peut changer entre les Oops et lorsque vous traitez le fichier journal. Pour aider à surmonter ce problème, si le répertoire / var / log / ksymoops existe, alorsinsmod etrmmod copie automatiquement / proc / ksyms et / proc / modules dans / var / log / ksymoops avec le préfixe `date +% Y% m% d% H% M% S`. L'administrateur système peut indiquer à ksymoops les fichiers d'instantané à utiliser lors du débogage d'un problème. Il n'y a pas d'interrupteur pour désactiver cette copie automatique. Si vous ne le souhaitez pas, ne créez pas / var / log / ksymoops. Si ce répertoire existe, il doit appartenir à root et être en mode 644 ou 600 et vous devez exécuter ce script tous les jours ou à peu près. Le script ci-dessous est installé en tant que insmod_ksymoops_clean.
#! / bin / sh # Supprimer les ksyms et les modules sauvegardés non utilisés dans les 2 jours si -d / var / log / ksymoops puis set -e # Assurez-vous qu'il y a toujours au moins une version d = `date +% Y% m% d% H% M% S` cp -a / proc / ksyms /var/log/ksymoops/${d}.ksyms cp -a / proc / modules /var/log/ksymoops/${d}.modules find / var / log / ksymoops -type f -atime +2 -exec rm {} ; Fi PRÉNOM insmod - installer le module de noyau chargeable SYNOPSIS insmod -fhkLmnpqrsSvVxXyYN -e nom persistant -o nom_module -O nom_blob -P préfixe module symbole= valeur … Informations de base à connaître
