El comando Linux/Unix insmod instala un módulo cargable en el núcleo en ejecución. insmod intenta enlazar un módulo en el kernel en ejecución resolviendo todos los símbolos de la tabla de símbolos exportados del kernel.

Si el nombre del archivo del módulo se da sin directorios o extensión, insmod buscará el módulo en algunos directorios predeterminados comunes. La variable de entorno MODPATH puede utilizarse para anular este valor predeterminado. Si existe un archivo de configuración de módulo como /etc/modules.conf , sustituirá las rutas definidas en MODPATH .

La variable de entorno MODULECONF también puede utilizarse para seleccionar un archivo de configuración diferente al predeterminado /etc/modules.conf (o /etc/conf.modules (obsoleto)). Esta variable de entorno anula todas las definiciones anteriores.

Cuando la variable de entorno UNAME_MACHINE está establecida, modutils usará su valor en lugar del campo máquina de la llamada al sistema uname(). Esto es principalmente útil cuando está compilando módulos de 64 bits en espacio de usuario de 32 bits o viceversa, ajuste UNAME_MACHINE al tipo de módulos. Los modutils actuales no soportan el modo cross build completo para los módulos, se limita a elegir entre versiones de 32 y 64 bits de la arquitectura del host.

Opciones

-e persist_name, –persist = persist_name

Especifica dónde se leen los datos persistentes del módulo durante la carga y dónde se escriben cuando se descarga esta instanciación del módulo. Esta opción se ignora silenciosamente si el módulo no tiene datos persistentes. Los datos persistentes sólo son leídos por insmod si esta opción está presente, por defecto insmod no procesa datos persistentes.

Como forma abreviada, -e «» (una cadena vacía) es interpretada por insmod como el valor de persistdir tal y como se define en modules.conf , seguido del nombre de archivo del módulo en relación con la ruta de búsqueda del módulo en el que se encontró, menos cualquier rastro de «.gz», «.o» o «.mod». Si modules.conf especifica » persistdir = » (i.e. persistdir es un campo vacío) entonces esta forma abreviada se ignora silenciosamente. (Ver modules.conf (5)).

-f , –force

Intente cargar el módulo incluso si la versión del núcleo en ejecución y la versión del núcleo para la que se compiló el módulo no coinciden. Esto sólo anula la comprobación de la versión del núcleo, no tiene efecto en las comprobaciones de nombre de símbolo. Si los nombres de los símbolos del módulo no coinciden con el núcleo, no hay forma de forzar a insmod a cargar el módulo.

-h , –help

Muestre un resumen de las opciones y salga inmediatamente.

-k , –autoclean

Fije el indicador de autolimpieza en el módulo. Esta bandera será usada por kerneld (8) para remover módulos que no han sido usados en algún periodo de tiempo – usualmente un minuto.

-L , –lock

Utilice flock (2) para evitar cargas simultáneas del mismo módulo.

-m , –map

Salida de un mapa de carga en stdout, lo que facilita la depuración del módulo en caso de pánico del kernel.

-n , –noload

Dummy run, hacer todo excepto cargar el módulo en el kernel. Si lo solicita un -m o -O , la ejecución producirá un mapa o archivo de notas. Como el módulo no está cargado, la dirección real de carga del núcleo es desconocida, por lo que el mapa y el archivo blob se basan en una dirección de carga arbitraria de 0x12340000.

-o module_name, –name = module_name

Ponga un nombre explícito al módulo, en lugar de derivar el nombre del nombre base del archivo del objeto de origen.

-O blob_name, –blob = blob_name

Guardar el objeto binario en blob_name. El resultado es una nota binaria (sin encabezados ELF) que muestra exactamente lo que se carga en el núcleo después de la manipulación y reubicación de secciones. Se recomienda la opción -m para obtener un mapa del objeto.

-p , –probe

Examine el módulo para ver si puede cargarse correctamente. Esto incluye localizar el archivo de objeto en la ruta del módulo, comprobar los números de versión y resolver los símbolos. No verifica las reubicaciones ni produce un mapa o archivo de notas.

-P prefijo, –prefijo = prefijo

Esta opción puede usarse con módulos versionados para un núcleo SMP o bigmem, ya que estos módulos tienen un prefijo extra añadido en sus nombres de símbolo. Si el núcleo se construyó con versiones de símbolos, entonces insmod extraerá automáticamente el prefijo de la definición de «get_module_symbol» o «inter_module_get», uno de los cuales debe existir en cualquier núcleo que soporte módulos. Si el núcleo no tiene versiones de símbolos pero el módulo fue construido con versiones de símbolos, entonces el usuario debe proporcionar -P .

-q , –quiet

No imprima una lista de símbolos no resueltos. No se queje de la falta de coincidencia de versiones. El problema sólo se reflejará en el estado de salida de insmod .

-r , –root

Algunos usuarios compilan módulos bajo un userid no root y luego instalan los módulos como root. Este proceso puede dejar los módulos propiedad del userid no root, aunque el directorio de módulos sea propiedad de root. Si el userid no raíz está comprometido, un intruso puede sobrescribir los módulos existentes que son propiedad de ese userid y usar esta exposición para arrancar hasta el acceso de root.

Por defecto, modutils rechazará los intentos de usar un módulo que no sea propiedad de root. Especificar -r cambiará la comprobación y permitirá a root cargar módulos que no son propiedad de root.

El valor por defecto para la comprobación de raíz se puede cambiar cuando modutils está configurado. El uso de -r para desactivar la comprobación de raíz o establecer el valor predeterminado en «sin comprobación de raíz» en el momento de la configuración es una importante exposición de seguridad y no se recomienda.

-s , –syslog

Emita todo en syslog (3) en lugar de en el terminal.

-S , –kallsyms

Forzar al módulo cargado a tener datos de kallsyms , incluso si el kernel no lo soporta. Esta opción es para sistemas pequeños donde el kernel se carga sin kallsyms datos pero los módulos seleccionados necesitan kallsyms para depurar. Esta opción es la predeterminada en Red Hat Linux.

-v , –verbose

Sea verboso.

-V , –versión

Mostrar la versión de insmod .

-X , -export ; -x , –noexport

Exporte y no exporte todos los símbolos externos del módulo, respectivamente. El valor por defecto es para los símbolos que se van a exportar. Esta opción sólo es efectiva si el módulo no exporta explícitamente su propia tabla de símbolos controlada y, por lo tanto, está obsoleta.

-Y , –ksymoops ; -y , –noksymoops

Añadir y no añadir símbolos ksymoops a los ksyms. Estos símbolos son usados por ksymoops para proporcionar una mejor depuración si hay un Oops en este módulo. El valor por defecto es para los símbolos ksymoops a ser definidos. Esta opción es independiente de las opciones -X / -x .

ksymoops añaden aproximadamente 260 bytes por módulo cargado. A menos que tenga muy poco espacio en el núcleo y esté intentando reducir los ksyms a su tamaño mínimo, tome el valor por defecto y obtenga una depuración de Oops más precisa. ksymoops son necesarios para guardar los datos persistentes del módulo.

-N , –sólo numérico

Compruebe únicamente la parte numérica de la versión del módulo con respecto a la versión del núcleo, es decir, ignore EXTRAVERSION cuando decida si un módulo pertenece a un núcleo. Esta bandera se fija automáticamente para el núcleo 2.5 en adelante, es opcional para los núcleos anteriores.

Parámetros del módulo

Algunos módulos aceptan parámetros de tiempo de carga para personalizar su operación. Estos parámetros son a menudo puertos de E/S y números de IRQ que varían de una máquina a otra y que no se pueden determinar desde el hardware.

En los módulos construidos para núcleos de la serie 2.0, cualquier número entero o símbolo de puntero de carácter puede ser tratado como un parámetro y modificado. A partir de los núcleos de la serie 2.1, los símbolos se marcan explícitamente como parámetros para que sólo se puedan cambiar valores específicos. Además, se proporciona información sobre el tipo para comprobar los valores proporcionados en el momento de la carga.

En el caso de los números enteros, todos los valores pueden estar en decimal, octal o hexadecimal a la C: 17, 021 o 0x11. Los elementos del array se especifican en una secuencia separada por comas. Los elementos pueden omitirse omitiendo el valor.

En los módulos de la serie 2.0, los valores que no comienzan con un número se consideran cadenas. Comenzando en 2.1, la información de tipo del parámetro indica si se debe interpretar el valor como una cadena. Si el valor comienza con comillas dobles ( « ), la cadena se interpreta como en C, secuencias de escape y todo. Tenga en cuenta que desde el intérprete de comandos, las comillas en sí pueden necesitar ser protegidas de la interpretación de shell.

Módulos y símbolos con licencia GPL

Comenzando con el núcleo 2.4.10, los módulos deberían tener una cadena de licencia, definida usando MODULE_LICENSE() . Varias cadenas son reconocidas como compatibles con la GPL; cualquier otra cadena de licencia o sin licencia significa que el módulo es tratado como propietario.

Si el kernel soporta la bandera /proc/sys/kernel/tainted entonces insmod O la bandera manchada con `1′ al cargar un módulo sin licencia GPL. Se emite una advertencia si el kernel soporta la contaminación y se carga un módulo sin licencia. Siempre se emite una advertencia para los módulos que tienen un MODULE_LICENSE() que no es compatible con GPL, incluso en núcleos antiguos que no soportan la contaminación. Esto minimiza las advertencias cuando se utiliza un nuevo modutils en núcleos antiguos.

insmod -f (modo de fuerza) O la bandera manchada con ‘2’ en los núcleos que soportan la mancha. Siempre emite una advertencia.

Algunos desarrolladores de kernel requieren que los símbolos exportados por su código sólo deben ser utilizados por módulos con una licencia compatible con GPL. Estos símbolos son exportados por EXPORT_SYMBOL_GPL en lugar de la normal EXPORT_SYMBOL . Los símbolos sólo GPL exportados por el núcleo y por otros módulos sólo son visibles para módulos con una licencia compatible con GPL, estos símbolos aparecen en /proc/ksyms con un prefijo de ‘ GPLONLY_ ‘. insmod ignora el prefijo GPLONLY_ en los símbolos mientras carga un módulo con licencia GPL, por lo que el módulo sólo hace referencia al nombre del símbolo normal, sin el prefijo. Los símbolos de GPL solamente no están disponibles para los módulos sin una licencia compatible con GPL, esto incluye los módulos sin licencia en absoluto.

Asistencia Ksymoops

Para ayudar a depurar los Oops del kernel cuando se usan módulos, insmod por defecto agrega algunos símbolos a los ksyms, vea la opción -Y . Estos símbolos comienzan con __insmod_ modulename_. El modulename es necesario para que los símbolos sean únicos. Es legal cargar el mismo objeto más de una vez bajo diferentes nombres de módulos. Actualmente, los símbolos definidos son:

__insmod_ modulename_ Oobjectfile_ Mmtime_ Vversion

objectfile es el nombre del archivo desde el que se cargó el objeto. Esto asegura que los ksymoops puedan hacer coincidir el código con el objeto correcto. mtime es la última marca de tiempo modificada en ese archivo en hexadecimal, cero si la estadística falla. version es la versión del núcleo para la que se compiló el módulo, -1 si no hay ninguna versión disponible. El símbolo _O tiene la misma dirección de inicio que la cabecera del módulo.

__insmod_ modulename_ Ssectionname_ Llength

Este símbolo aparece al principio de las secciones seleccionadas de la FEB, actualmente .text,.rodata,.data,.bss y.sbss. Sólo aparece si la sección tiene un tamaño distinto de cero. sectionname es el nombre de la sección ELF, length es la longitud de la sección en decimales. Estos símbolos ayudan a ksymoops a mapear direcciones a secciones cuando no hay símbolos disponibles.

__insmod_ modulename _Ppersistent_ filename

Sólo creado por insmod si el módulo tiene uno o más parámetros marcados como datos persistentes y está disponible un nombre de archivo para guardar datos persistentes (véase -e , arriba).

El otro