En informática , un módulo de kernel cargable ( LKM ) es un archivo objeto que contiene código para extender el kernel en ejecución , o el llamado kernel base , de un sistema operativo . Los LKM se utilizan normalmente para agregar soporte para nuevo hardware (como controladores de dispositivos ) y/o sistemas de archivos , o para agregar llamadas al sistema . Cuando la funcionalidad proporcionada por un LKM ya no es necesaria, se puede descargar para liberar memoria y otros recursos.
La mayoría de los sistemas tipo Unix actuales y Microsoft Windows admiten módulos del kernel cargables con diferentes nombres, como módulo cargable del kernel ( kld ) en FreeBSD , extensión del kernel ( kext ) en macOS (aunque se está eliminando el soporte para módulos de terceros [1] ) , [2] módulo de extensión del kernel en AIX , módulo del kernel cargable dinámicamente en HP-UX , [3] controlador en modo kernel en Windows NT [4] y módulo del kernel descargable ( DKM ) en VxWorks . También se les conoce como módulos cargables del kernel (o KLM ), y simplemente como módulos del kernel ( KMOD ).
Sin módulos de kernel cargables, un sistema operativo tendría que incluir todas las funciones anticipadas posibles compiladas directamente en el kernel base. Gran parte de esa funcionalidad residiría en la memoria sin ser utilizada, desperdiciando memoria [ cita necesaria ] , y requeriría que los usuarios reconstruyan y reinicien el kernel base cada vez que requieran una nueva funcionalidad.
Una crítica menor a preferir un núcleo modular a uno estático es la llamada penalización por fragmentación . El núcleo base siempre se descomprime en la memoria contigua real mediante sus rutinas de configuración; por lo tanto, el código base del kernel nunca se fragmenta. Una vez que el sistema se encuentra en un estado en el que se pueden insertar módulos, por ejemplo, una vez que se han montado los sistemas de archivos que contienen los módulos, es probable que cualquier nueva inserción de código del núcleo haga que el núcleo se fragmente, introduciendo así una penalización menor en el rendimiento. al utilizar más entradas TLB , lo que provoca más errores de TLB. [ cita necesaria ]
Los módulos del kernel cargables en Linux se cargan (y descargan) mediante el modprobecomando. Están ubicados en /lib/moduleso /usr/lib/modulesy tienen la extensión .ko("objeto kernel") desde la versión 2.6 (las versiones anteriores usaban la .oextensión). [5] El lsmodcomando enumera los módulos del kernel cargados. En casos de emergencia, cuando el sistema no arranca debido, por ejemplo, a módulos rotos, se pueden habilitar o deshabilitar módulos específicos modificando la lista de parámetros de arranque del kernel (por ejemplo, si usa GRUB , presionando 'e' en el menú de inicio de GRUB, luego editando la línea de parámetros del kernel).
En opinión de los mantenedores de Linux, LKM son trabajos derivados del kernel [ cita requerida ] . Los mantenedores de Linux toleran la distribución de módulos propietarios , [ cita necesaria ] pero permiten que los símbolos se marquen como disponibles solo para los módulos de Licencia Pública General (GPL) de GNU .
Cargar un módulo propietario o no compatible con GPL establecerá un indicador de 'contaminación' [6] [7] en el kernel en ejecución, lo que significa que será menos probable que los mantenedores investiguen cualquier problema o error experimentado. [8] [9] Los LKM se convierten efectivamente en parte del kernel en ejecución, por lo que pueden dañar las estructuras de datos del kernel y producir errores que tal vez no puedan investigarse si el módulo es realmente propietario.
En 2004, Linuxant, una empresa consultora que lanza controladores de dispositivos propietarios como módulos de kernel cargables, intentó abusar de un terminador nulo en su MODULE_LICENSE, como se ve en el siguiente extracto de código:
MODULE_LICENSE ( "GPL \0 para archivos en el directorio \" GPL \" ; para otros, solo se aplica el archivo LICENCIA" );El código de comparación de cadenas utilizado por el kernel en ese momento intentó determinar si el módulo tenía licencia GPL cuando alcanzó un carácter nulo ( \0), por lo que se engañó al pensar que el módulo estaba declarando que su licencia era solo "GPL". [10]
Los módulos del kernel para FreeBSD se almacenan dentro /boot/kernel/de los módulos distribuidos con el sistema operativo , o generalmente /boot/modules/para módulos instalados desde puertos FreeBSD o paquetes FreeBSD , o para módulos propietarios o solo binarios. Los módulos del kernel de FreeBSD suelen tener la extensión .ko. Una vez que la máquina se ha iniciado, se pueden cargar con el kldloadcomando, descargar con kldunloady enumerar con kldstat. Los módulos también se pueden cargar desde el cargador antes de que se inicie el kernel, ya sea automáticamente (a través de /boot/loader.conf) o manualmente.
Algunos módulos del kernel cargables en macOS se pueden cargar automáticamente. Los módulos del kernel cargables también se pueden cargar mediante el kextloadcomando. Se pueden enumerar mediante el kextstatcomando. Los módulos del kernel cargables se encuentran en paquetes con la extensión .kext. Los módulos suministrados con el sistema operativo se almacenan en el /System/Library/Extensionsdirectorio; Los módulos suministrados por terceros se encuentran en varios otros directorios.
Un módulo del kernel de NetWare se conoce como módulo cargable de NetWare (NLM). Los NLM se insertan en el kernel de NetWare mediante el comando LOAD y se eliminan mediante el comando UNLOAD; el modulescomando enumera los módulos del kernel actualmente cargados. Los NLM pueden residir en cualquier ruta de búsqueda válida asignada en el servidor NetWare y tienen .NLMcomo extensión de nombre de archivo.
Se puede crear un proyecto de tipo módulo de kernel descargable (DKM) para generar un archivo ".out" que luego se puede cargar en el espacio del kernel usando el comando "ld". Este módulo del kernel descargable se puede descargar usando el comando "unld".
Solaris tiene una ruta de carga del módulo del kernel configurable, cuyo valor predeterminado es /platform/platform-name/kernel /kernel /usr/kernel. La mayoría de los módulos del kernel se encuentran en subdirectorios bajo /kernel; aquellos que no se consideran necesarios para iniciar el sistema hasta el punto en que init pueda iniciarse a menudo (pero no siempre) se encuentran en /usr/kernel. Cuando se ejecuta una compilación del kernel DEBUG, el sistema intenta activamente descargar módulos.
Linux no proporciona una API o ABI estable para los módulos del kernel. Esto significa que existen diferencias en la estructura interna y el funcionamiento entre las diferentes versiones del kernel, lo que puede causar problemas de compatibilidad. En un intento por combatir esos problemas, los datos de versiones de símbolos se colocan dentro de la sección de módulos ELF.modinfo cargables . Esta información de versiones se puede comparar con la del kernel en ejecución antes de cargar un módulo; si las versiones son incompatibles, el módulo no se cargará.
Otros sistemas operativos, como Solaris , FreeBSD , macOS y Windows mantienen la API del kernel y la ABI relativamente estables, evitando así este problema. Por ejemplo, los módulos del kernel de FreeBSD compilados con la versión 6.0 del kernel funcionarán sin recompilación en cualquier otra versión de FreeBSD 6.x, por ejemplo, 6.4. Sin embargo, no son compatibles con otras versiones principales y deben recompilarse para usarse con FreeBSD 7.x, ya que la compatibilidad API y ABI se mantiene solo dentro de una rama.
Si bien los módulos del kernel cargables son un método conveniente para modificar el kernel en ejecución, los atacantes pueden abusar de esto en un sistema comprometido para evitar la detección de sus procesos o archivos , lo que les permite mantener el control sobre el sistema. Muchos rootkits utilizan LKM de esta manera. Tenga en cuenta que, en la mayoría de los sistemas operativos, los módulos no ayudan a la elevación de privilegios de ninguna manera, ya que se requieren privilegios elevados para cargar un LKM; simplemente hacen que al atacante le resulte más fácil ocultar el robo. [11]
Linux permite deshabilitar la carga de módulos mediante la opción sysctl/proc/sys/kernel/modules_disabled . [12] [13] Un sistema initramfs puede cargar módulos específicos necesarios para una máquina en el arranque y luego deshabilitar la carga de módulos. Esto hace que la seguridad sea muy similar a la de un núcleo monolítico. Si un atacante puede cambiar initramfs, puede cambiar el binario del kernel.
En OS X Yosemite y versiones posteriores, una extensión del kernel debe estar firmada con un código de certificado de desarrollador que tenga un "derecho" particular. Apple solo proporciona dicho certificado de desarrollador a pedido y no se entrega automáticamente a los miembros desarrolladores de Apple . Esta característica, llamada "firma kext", está habilitada de forma predeterminada e indica al kernel que detenga el arranque si hay extensiones del kernel sin firmar. [14] En OS X El Capitan y versiones posteriores, forma parte de System Integrity Protection .
En versiones anteriores de macOS, o si la firma kext está deshabilitada, los usuarios no root pueden cargar un módulo del kernel cargable en un paquete de extensión del kernel si la propiedad OSBundleAllowUserLoad está establecida en True en la lista de propiedades del paquete. [15] Sin embargo, si alguno de los archivos del paquete, incluido el archivo de código ejecutable, no es propiedad del root y del grupo wheel, o el grupo u "otro" pueden escribirlo, el intento de cargar el módulo cargable del kernel fallará. . [dieciséis]
Los módulos del kernel pueden tener opcionalmente una sección ELF de firma criptográfica que se verifica durante la carga según la configuración de la política de arranque verificado. El kernel puede exigir que los módulos estén firmados criptográficamente mediante un conjunto de certificados confiables; La lista de certificados confiables se mantiene fuera del sistema operativo en ILOM en algunas plataformas basadas en SPARC. La carga del módulo del kernel iniciada en el espacio de usuario solo es posible desde la ruta confiable cuando el sistema se ejecuta con la función de zona global inmutable habilitada.