Instalar y firmar módulos de kernel personalizados en SLES 15 Secure Boot

Un controlador de terceros en SUSE Linux Enterprise Server 15 puede compilarse correctamente, pero fallar al cargarse con el mensaje "Clave requerida no disponible" o "El servicio rechazó la clave". Cuando UEFI Secure Boot exige firmas de módulos, la solución consiste en firmar el módulo del kernel personalizado con un certificado de confianza, registrar dicho certificado mediante la administración de la clave de propietario de la máquina (MOK) y, a continuación, cargar el módulo normalmente, sin deshabilitar Secure Boot.

Este procedimiento presupone un sistema UEFI SLES 15 estándar con SUSE shim, un kernel-defaultkernel, acceso de administrador y una fuente confiable para el controlador. Se refiere a .komódulos personalizados, sin firmar un kernel de reemplazo ni modificar las claves de la plataforma del firmware. Los ejemplos siguen el modelo de administración de SLES 15 SP6/SP7; verifique las diferencias entre paquetes y versiones del kernel en su Service Pack instalado.

1. Primero, compruebe el arranque seguro y el kernel en ejecución.

Inicie sesión con permisos de administrador e identifique el kernel que utilizó para arrancar el sistema. Un nombre de paquete coincidente por sí solo no garantiza que un módulo pueda cargarse en ese kernel.

uname -r
mokutil --sb-state
ls -ld "/lib/modules/$(uname -r)/build"

Si mokutilel arranque seguro está habilitado, una firma no confiable es una explicación probable para un fallo de carga relacionado con la clave. Si está deshabilitado, investigue otras causas antes de generar claves; la aplicación explícita de la firma del kernel también puede ser relevante. Revise el registro del kernel después de una carga fallida para ver el mensaje de rechazo.

sudo journalctl -k -b --no-pager | tail -n 50

Inspeccione el módulo candidato antes de instalarlo. Sustituya el nombre de archivo real por el del ejemplo; este vermagicdebe coincidir con la versión del kernel en ejecución y las propiedades de compilación compatibles.

modinfo -F name /path/to/mydriver.ko
modinfo -F vermagic /path/to/mydriver.ko

2. Utilice un paquete de controladores compatible o cree un módulo compatible.

Primero, solicite al proveedor de hardware o software un paquete de módulo del kernel (KMP) compatible con SLES y ya firmado. Esto es preferible a la instalación manual de un binario: el proveedor puede ofrecer la gestión de actualizaciones del kernel y un proceso documentado de registro de certificados. La firma del proveedor no se considera automáticamente confiable en todas las máquinas con arranque seguro.

Si necesita compilar el controlador, instale los archivos de desarrollo que coincidan con su kernel en ejecución. Para esta kernel-defaultversión, los paquetes SLES habituales incluyen el paquete de desarrollo del kernel predeterminado, los archivos de desarrollo del kernel y las herramientas de compilación. La disponibilidad del repositorio y las versiones dependen del registro y de los módulos SLES habilitados.

sudo zypper install gcc make openssl mokutil kernel-devel kernel-default-devel
rpm -q kernel-default-devel kernel-devel
readlink -f "/lib/modules/$(uname -r)/build"

Si falta el directorio de compilación o el paquete de desarrollo apunta a una versión diferente del kernel, primero corrija la discrepancia entre el paquete y el kernel. Un kernel recién instalado puede requerir un reinicio controlado antes de compilarlo.

Desde el directorio de código fuente del controlador de confianza, utilice las instrucciones de compilación del proveedor. Para los módulos convencionales basados ​​en kbuild, el siguiente comando compila sobre el kernel en ejecución; no descarga ni crea un controlador por sí mismo.

cd /path/to/driver-source
make -C "/lib/modules/$(uname -r)/build" M="$PWD" modules

Omita la compilación cuando ya tenga una versión compatible .kode un proveedor de confianza. Nunca fuerce la carga de un módulo con la versión incorrecta vermagic; una firma no puede reparar un binario incompatible.

3. Cree la clave de firma y firme el módulo instalado.

Genere una clave RSA dedicada y un certificado X.509 en un directorio de acceso restringido al usuario root. El certificado público se registrará; la clave privada debe permanecer protegida, ya que quien la controle podrá firmar módulos adicionales en los que esta máquina pueda confiar.

sudo -i
umask 077
mkdir -p /root/module-signing
cd /root/module-signing
openssl req -new -x509 -newkey rsa:3072 -sha256 -days 3650 -nodes \
  -subj "/CN=SLES Custom Module Signing/" \
  -keyout MOK.priv -out MOK.pem
openssl x509 -in MOK.pem -outform DER -out MOK.der
chmod 600 MOK.priv

-nodesSe crea una clave privada sin cifrar para un ejemplo sencillo; para un proceso de firma en producción, utilice una clave cifrada con la protección adecuada o un servicio de firma externo conforme a su política de seguridad. La validez de diez años que se muestra aquí es ilustrativa y no constituye una recomendación sobre la duración del certificado para su organización.

Copie el módulo finalizado en el directorio de módulos del kernel en ejecución. Firme el archivo instalado tal cual después de cualquier empaquetado, eliminación de datos u otras modificaciones. Reemplace mydrivery su ruta con el nombre base y la ubicación reales del módulo.

install -D -m 0644 /path/to/mydriver.ko \
  "/lib/modules/$(uname -r)/extra/mydriver.ko"
SIGN_FILE="$(readlink -f /lib/modules/$(uname -r)/build)/scripts/sign-file"
test -x "$SIGN_FILE" || echo "Locate the sign-file binary for this kernel"
"$SIGN_FILE" sha256 /root/module-signing/MOK.priv \
  /root/module-signing/MOK.der \
  "/lib/modules/$(uname -r)/extra/mydriver.ko"
modinfo -F signer "/lib/modules/$(uname -r)/extra/mydriver.ko"

Si sign-fileno se encuentra en esa ruta, localice la herramienta incluida en los archivos de compilación del kernel correspondientes en lugar de copiar una versión no relacionada. La presencia de un firmante indica que el archivo contiene metadatos de firma; esto no prueba que el firmante esté registrado. Nunca elimine ni modifique el módulo después de firmarlo.

4. Inscriba el certificado público utilizando MOK.

Importe el certificado público en formato DER (no MOK.privel certificado de registro único) y establezca la contraseña de registro único solicitada por mokutil. Configure el acceso a la consola antes de reiniciar; la autorización se realiza en la interfaz de MokManager durante el arranque, no en una consola SSH.

mokutil --import /root/module-signing/MOK.der
mokutil --list-new
reboot

Durante el siguiente arranque, seleccione «Registrar MOK» , siga las instrucciones de confirmación, introduzca la contraseña de un solo uso y continúe con el arranque. La apariencia del menú depende de la versión del firmware y del módulo de autenticación. Si regresa a Linux sin confirmar el registro, el nuevo certificado quedará sin confianza.

Tras el arranque, verifique que el certificado específico esté registrado:

sudo mokutil --test-key /root/module-signing/MOK.der
sudo mokutil --list-enrolled

5. Cargar el módulo firmado y aislar los errores restantes.

Actualiza los metadatos de dependencia del módulo y carga el módulo por su nombre, no por la ruta de archivo completa. modprobeResuelve las dependencias y respeta la configuración estándar del módulo.

sudo depmod -a
sudo modprobe mydriver
lsmod | grep -w mydriver
modinfo -F signer mydriver

Si la carga sigue fallando, elija la acción correctiva que coincida con la evidencia:

• Clave rechazada o clave requerida no disponible: vuelva a ejecutar mokutil --test-key; confirme que el archivo que instaló es el firmado y verifique si una actualización del controlador lo reemplazó.
• Formato de módulo no válido: compare modinfo -F vermagiccon uname -r, vuelva a compilar para el kernel activo y verifique la arquitectura de la CPU.
• Símbolo desconocido o dependencia faltante: inspeccione journalctl -k -blos módulos requeridos por el proveedor y la ABI del kernel; otra firma no solucionará los símbolos faltantes.

Para controladores de almacenamiento o de red críticos para el arranque, pruébelos primero en un sistema que no sea de producción y asegúrese de que haya una consola de recuperación disponible. Configure la carga automática solo después de que el controlador funcione correctamente; consulte la documentación de SUSE /etc/modules-load.d/para los módulos que no se cargan al detectar el dispositivo.

Verifique el resultado después de reiniciar.

Reinicia el sistema durante tu ventana de mantenimiento si la carga persistente es un problema. Confirma que el arranque seguro (Secure Boot) siga habilitado, que la clave pública esté registrada, que el módulo esté presente y que el kernel no reporte ningún error de verificación o compatibilidad. Recompila o reinstala y firma la versión actualizada .kotras las actualizaciones del kernel o del controlador del proveedor.

mokutil --sb-state
sudo mokutil --test-key /root/module-signing/MOK.der
modinfo -F signer mydriver
lsmod | grep -w mydriver
sudo journalctl -k -b --no-pager | tail -n 30

Documentación principal: SUSE SLES 15 SP6: UEFI y claves de propietario de máquina ; SUSE: Gestión de módulos del kernel ; Kernel de Linux: Funcionamiento de firma de módulos ; Kernel de Linux: Creación de módulos externos . La Guía de administración de SLES 15 SP6 se ​​actualizó el 17 de septiembre de 2026; el comportamiento de los comandos para los instaladores de controladores de terceros y las variantes de kernel no predeterminadas debe confirmarse con sus responsables.