Como instalar módulos de kernel personalizados no SLES 15 com Inicialização Segura (Secure Boot).

Para carregar um módulo de kernel personalizado no SLES 15 com o Secure Boot ativado, compile-o para o kernel exato que você executará, assine o .koarquivo finalizado com um certificado de assinatura confiável, registre esse certificado como uma Chave do Proprietário da Máquina (MOK) e, em seguida, carregue o módulo com `--load` modprobe. Uma MOK é um certificado controlado localmente que o shim do SUSE e o kernel do Linux podem usar para verificar o módulo do Secure Boot. Não desative o Secure Boot para contornar uma assinatura rejeitada. O processo abaixo é para um administrador que controla a máquina e pode aprovar o registro de uma chave na reinicialização.

Este guia segue a documentação de administração do SLES 15 SP7 da SUSE e as diretrizes de empacotamento de módulos do kernel da SUSE, verificadas em 6 de outubro de 2026. Os comandos usam acme_drivero nome do módulo como exemplo; substitua-o pelo nome real do módulo, sem o .kosufixo, quando apropriado. Estes são exemplos de comandos, não a saída de um host testado.

Quando este método é o mais adequado

Use esta abordagem para um módulo personalizado fora da árvore — fornecido separadamente do kernel em execução — quando você puder recompilar ou obter uma versão compilada para o kernel SLES de destino e registrar um certificado no servidor. Isso se aplica a sistemas inicializados pelo SUSE Secure Boot e pelo caminho shim. Se um fornecedor disponibilizar um pacote de drivers oficial para SLES 15, utilize primeiro as instruções de instalação e assinatura fornecidas por ele; um pacote do fornecedor pode lidar melhor com a compatibilidade e as atualizações do kernel do que uma cópia manual.

O Secure Boot valida a cadeia de inicialização e o kernel também verifica as assinaturas dos módulos carregáveis ​​de acordo com a política aplicável. Um módulo pode ser assinado, mas ainda assim falhar ao carregar se tiver como alvo uma ABI de kernel diferente, depender de símbolos ausentes ou for compilado para a arquitetura errada. Por outro lado, a correspondência com o kernel não torna um módulo não assinado confiável. A assinatura visa à confiança; ela não estabelece compatibilidade nem certifica que o código é seguro.

Antes de começar

• Utilize uma conta de administrador e confirme se há uma janela de manutenção disponível. O registro do MOK requer uma reinicialização e uma ação de aprovação no MokManager, normalmente por meio de um console local ou remoto.
• Verifique o estado do kernel em execução e da Inicialização Segura com uname -r` mokutil --sb-statesudo apt-get install kernel` e `sudo apt-get install kernel`. Compile o módulo usando os arquivos de desenvolvimento e a cadeia de ferramentas correspondentes ao tipo de kernel. Os nomes dos pacotes e os arquivos necessários variam de acordo com o pacote de serviços do SLES, o tipo de kernel e o método de compilação; portanto, verifique-os nos repositórios habilitados no sistema de destino.
• Defina onde a chave privada de assinatura será armazenada. Para um ambiente de produção, utilize o serviço de assinatura controlado pela organização ou um processo de gerenciamento de chaves aprovado. Para um laboratório ou um único host controlado, uma chave gerada localmente pode ser viável. Proteja a chave privada; o servidor precisa do certificado público para o registro, não da chave privada.
• Mantenha um caminho de recuperação, o código-fonte do módulo ou o pacote do fornecedor, e um kernel funcional disponíveis. Não carregue um driver em hardware de produção até que você entenda os requisitos do dispositivo e do kernel.

1. Crie uma chave de assinatura e um certificado público.

Em um sistema de assinatura protegido, crie uma chave privada e um certificado X.509 codificado em DER. As diretrizes de empacotamento de módulos do kernel da SUSE recomendam o codeSigninguso de chaves estendidas nos pacotes de serviços atuais do SLES 15. Este exemplo usa o OpenSSL e um nome de certificado descritivo:

openssl req -new -x509 -newkey rsa:2048 -sha256 \
  -keyout module-signing.key \
  -out module-signing.der -outform DER -nodes \
  -days 4745 -addext "extendedKeyUsage=codeSigning" \
  -subj "/CN=Custom Module Signing/"
chmod 600 module-signing.key

Essa -nodesopção deixa a chave privada sem criptografia, portanto, as permissões de arquivo e os controles de armazenamento são importantes. Não copie essa chave privada para um servidor de uso geral nem a incorpore em um pacote. Se a política da organização exigir uma chave criptografada, assinatura com suporte de hardware, rotação de chaves ou um ciclo de vida de certificado diferente, siga essa política e os requisitos da ferramenta de assinatura. Transfira apenas module-signing.derpara o sistema que irá registrar a chave pública.

2. Compile o módulo para o kernel de destino e assine-o.

Compile o módulo usando a versão exata do kernel mostrada por uname -r. As instruções de compilação do projeto de origem determinam o compilador, os cabeçalhos e a configuração necessários; não existe um único comando de compilação que sirva para todos os módulos personalizados. Verifique os resultados vermagiccom modinfose precisar diagnosticar uma incompatibilidade de kernel.

Assine o arquivo final do módulo após a compilação e qualquer etapa de empacotamento ou remoção de código. A SUSE documenta sua ferramenta auxiliar de assinatura em /usr/lib/rpm/pesign/kernel-sign-file; o exemplo a seguir usa o formato PKCS#7 e o resumo SHA-256:

/usr/lib/rpm/pesign/kernel-sign-file -i pkcs7 sha256 \
  module-signing.key module-signing.der acme_driver.ko

O auxiliar deve estar disponível na integração de assinatura do SUSE em seu sistema. Caso esteja ausente, verifique a documentação oficial do SLES/KMP e os repositórios habilitados para a configuração de assinatura compatível, em vez de usar um comando de assinatura arbitrário. Uma assinatura de módulo é anexada ao arquivo. Não remova, edite, recomprima ou altere o módulo de qualquer outra forma após a assinatura; tais alterações podem invalidar a assinatura. Mantenha um artefato de compilação íntegro para que você possa repetir a etapa final de assinatura.

3. Inscreva o certificado público como um MOK (Certificado de Recebimento de Cidadão).

No servidor SLES, coloque o module-signing.dercertificado público em um local onde o usuário root possa lê-lo e, em seguida, coloque-o na fila para inscrição:

mokutil --root-pw --import module-signing.der
mokutil --list-new

A documentação da SUSE --root-pwapresenta uma forma de autorizar o registro pendente com a senha de root. O comando de importação enfileira o certificado; ele não o registra imediatamente. Reinicie o servidor. No MokManager, escolha "Registrar chave do disco" , selecione o certificado, confirme o registro e conclua a autorização solicitada. A redação do menu pode variar ligeiramente de acordo com a versão do shim/MokManager. Se você não conseguir acessar a tela de registro, verifique o caminho de inicialização e providencie o acesso ao console; não presuma que o certificado foi registrado apenas porque o comando de importação foi bem-sucedido.

Após a inicialização do servidor, confirme se a chave aparece na lista de inscritos:

mokutil --list-enrolled

4. Instale, atualize as dependências do módulo e carregue-o.

Copie o arquivo assinado para o diretório extra-modules do kernel em execução, atualize o mapa de dependências e solicite o módulo pelo nome. Substitua o nome da versão do kernel se estiver instalando para um kernel diferente.

release=$(uname -r)
install -D -m 0644 acme_driver.ko \
  "/lib/modules/$release/extra/acme_driver.ko"
depmod -a "$release"
modprobe acme_driver

modprobeGeralmente é preferível usar `systemctl load` insmodporque resolve as dependências entre módulos. Teste o dispositivo ou a funcionalidade que o driver fornece; um comando bem-sucedido por si só não comprova que o hardware funciona corretamente. Se o módulo for destinado a ser carregado na inicialização, adicione o nome do módulo em uma linha separada em um arquivo como `/etc/modules` /etc/modules-load.d/acme_driver.conf. O SLES usa o mecanismo de carregamento de módulos do systemd para esses arquivos de configuração.

5. Verificar o caminho de confiança e solucionar problemas.

Algumas verificações úteis incluem:

mokutil --list-enrolled
modinfo -F signer /lib/modules/$(uname -r)/extra/acme_driver.ko
lsmod | grep acme_driver
journalctl -k -b | tail -n 80

modinfo -F signerExibe os metadados do assinante incorporados no módulo. Por si só, não comprova que o certificado foi registrado ou que o kernel em execução aceitou a assinatura. Uma modprobeinicialização segura bem-sucedida, seguida de inspeção do log do kernel e verificação do funcionamento do dispositivo, é uma evidência mais útil. A saída do terminal exibida na figura é um exemplo dos comandos e uma saída ilustrativa, não um relatório de um teste realizado para este artigo.

A SUSE também monitora se um módulo é suportado, e carregar um módulo não suportado pode afetar o status de suporte ou o estado de contaminação do kernel. Essa política é independente da verificação de assinatura: alterar uma configuração de módulo não suportado não inscreve uma chave de assinatura e não corrigirá uma assinatura rejeitada. Consulte as diretrizes de suporte da SUSE antes de alterar essa política em um sistema de produção com suporte.

Planeje atualizações do kernel e implantações repetidas.

Um módulo compilado para uma versão do kernel não é automaticamente compatível com a versão seguinte. Após uma atualização do kernel, instale o ambiente de compilação correspondente, recompile o módulo para a nova ABI do kernel, assine o arquivo final, instale-o na árvore de módulos desse kernel e atualize as informações de dependência. Se o certificado de assinatura permanecer confiável, normalmente não é necessário registrá-lo novamente. Um certificado de substituição ou rotacionado requer seu próprio registro e aprovação. Teste o novo kernel e o módulo em conjunto antes de confiar no carregamento automático durante a inicialização.

Para uma frota ou um driver que precisa sobreviver a atualizações rotineiras, utilize um fluxo de trabalho de empacotamento repetível, como a abordagem de Pacote de Módulo do Kernel (KMP) da SUSE, quando esta se adequar ao seu modelo de driver e suporte. O empacotamento pode organizar as compilações e etapas de assinatura por kernel, mas não elimina a necessidade de proteção de chave adequada, compatibilidade de módulos, confiança MOK e testes de atualização. Consulte a documentação para obter informações sobre o pacote de serviços específico do SLES 15 e o ciclo de vida do kernel suportado pela sua organização.

Referências oficiais

• Guia de Administração do SUSE Linux Enterprise Server 15 SP7 — Inicialização Segura e inscrição MOK, carregamento de módulos e política de módulos não suportados.
• Manual de Pacotes de Módulos do Kernel SUSE — Processo de assinatura de KMP e requisitos de assinatura aplicáveis ​​ao SLES 15.
• Documentação sobre assinatura de módulos do kernel Linux — comportamento da assinatura do kernel e restrições em arquivos de módulos assinados.