Instalar e assinar módulos de kernel personalizados no Secure Boot do SLES 15

Um driver de terceiros no SUSE Linux Enterprise Server 15 pode compilar corretamente, mas falhar ao carregar, exibindo as mensagens “Chave necessária não disponível” ou “A chave foi rejeitada pelo serviço”. Quando a Inicialização Segura UEFI impõe assinaturas de módulo, a solução é assinar o módulo de kernel personalizado com um certificado confiável, registrar esse certificado por meio do gerenciamento de Chaves do Proprietário da Máquina (MOK) e, em seguida, carregar o módulo normalmente — sem desativar a Inicialização Segura.

Este procedimento pressupõe um sistema SLES 15 UEFI padrão usando o SUSE shim, um kernel-defaultkernel, acesso de administrador e uma fonte confiável para o seu driver. Ele aborda .komódulos personalizados, não a assinatura de um kernel de substituição ou a alteração das chaves da plataforma de firmware. Os exemplos seguem o modelo de administração do SLES 15 SP6/SP7; verifique as diferenças de pacotes e variantes do kernel no seu pacote de serviços instalado.

1. Verifique primeiro a Inicialização Segura e o kernel em execução.

Faça login com acesso administrativo e identifique o kernel que você realmente inicializou. Um nome de pacote correspondente por si só não prova que um módulo pode ser carregado nesse kernel.

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

Se mokutilo sistema indicar que a Inicialização Segura está ativada, uma assinatura não confiável é uma explicação provável para a falha de carregamento relacionada à chave. Se estiver desativada, investigue outras causas antes de gerar chaves; a imposição explícita de assinatura no kernel também pode ser relevante. Verifique o log do kernel após uma falha de carregamento para obter a mensagem de rejeição exata.

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

Inspecione o módulo candidato antes de instalá-lo. Substitua o nome do arquivo real pelo exemplo; ele vermagicdeve corresponder à versão do kernel em execução e às propriedades de compilação compatíveis.

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

2. Utilize um pacote de drivers compatível ou crie um módulo correspondente.

Primeiro, solicite ao fornecedor do hardware ou software um pacote de módulo do kernel (KMP) compatível com SLES e já assinado. Isso é preferível à instalação manual de um binário: o fornecedor pode oferecer gerenciamento de atualizações do kernel e um processo documentado de inscrição de certificado. A assinatura do fornecedor não é automaticamente confiável em todas as máquinas com Inicialização Segura.

Se precisar compilar o driver, instale os arquivos de desenvolvimento correspondentes ao kernel em execução. Para a kernel-defaultdistribuição, os pacotes SLES usuais incluem o pacote de desenvolvimento do kernel padrão, os arquivos de desenvolvimento do kernel e as ferramentas de compilação. A disponibilidade e as versões do repositório dependem do registro e dos 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"

Se o diretório de compilação estiver ausente ou se o pacote de desenvolvimento for direcionado a uma versão diferente do kernel, corrija primeiro a incompatibilidade entre o pacote e o kernel. Um kernel recém-instalado pode exigir uma reinicialização controlada antes da compilação.

A partir do diretório de origem de drivers confiáveis, use as instruções de compilação do fornecedor. Para módulos convencionais baseados em kbuild, o comando abaixo compila com base no kernel em execução; ele não baixa nem cria um driver por si só.

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

Ignore a compilação se você já tiver um binário compatível .kode um fornecedor confiável. Nunca force o carregamento de um módulo com a assinatura errada vermagic; uma assinatura não pode corrigir um binário incompatível.

3. Crie a chave de assinatura e assine o módulo instalado.

Gere uma chave RSA dedicada e um certificado X.509 em um diretório restrito ao usuário root. O certificado público será registrado; a chave privada deve permanecer protegida, pois quem a controlar poderá assinar módulos adicionais nos quais esta máquina poderá 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

-nodesEste exemplo simplificado cria uma chave privada não criptografada; para um pipeline de assinatura em produção, utilize uma chave criptografada devidamente protegida ou um serviço de assinatura externo, conforme sua política de segurança. A validade de dez anos apresentada aqui é meramente ilustrativa e não representa uma recomendação organizacional para a duração do certificado.

Copie o módulo finalizado para o diretório de módulos do kernel em execução. Assine o arquivo instalado exatamente como está após qualquer empacotamento, remoção de código ou outras modificações. Substitua `<basename>` mydrivere seu caminho pelo nome base e localização reais do 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"

Se sign-filea ferramenta estiver ausente nesse caminho, localize a ferramenta fornecida com os arquivos de compilação do kernel correspondentes, em vez de copiar uma versão não relacionada. Um assinante exibido significa que o arquivo contém metadados de assinatura; isso não prova que o assinante foi cadastrado. Nunca remova ou modifique o módulo após a assinatura.

4. Inscreva o certificado público usando o MOK.

Importe o certificado público no formato DER (não MOK.privo certificado padrão) e defina a senha de inscrição única solicitada mokutil. Configure o acesso ao console antes de reiniciar; a autorização ocorre na interface do MokManager durante a inicialização, não em um shell SSH.

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

Na próxima inicialização, selecione "Inscrever MOK" , siga as instruções de confirmação, insira a senha de uso único e continue a inicialização. A aparência do menu depende da versão do firmware e do shim. Retornar ao Linux sem confirmar a inscrição fará com que o novo certificado seja considerado não confiável.

Após a inicialização, verifique se o certificado específico está registrado:

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

5. Carregue o módulo assinado e isole os erros restantes.

Atualiza os metadados de dependência do módulo e carrega o módulo pelo nome, não pelo caminho completo do arquivo. modprobeResolve as dependências e respeita a configuração padrão do módulo.

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

Se o carregamento ainda falhar, escolha a ação corretiva que corresponde às evidências:

• Chave rejeitada ou chave necessária indisponível: execute novamente mokutil --test-key; confirme se o arquivo instalado é o assinado e verifique se uma atualização de driver o substituiu.
• Formato de módulo inválido: compare modinfo -F vermagiccom uname -r, reconstrua para o kernel ativo e verifique a arquitetura da CPU.
• Símbolo desconhecido ou dependência ausente: inspecione journalctl -k -bos módulos necessários do fornecedor e a ABI do kernel; outra assinatura não corrigirá os símbolos ausentes.

Para drivers de armazenamento ou rede críticos para a inicialização, teste primeiro em um sistema que não seja de produção e certifique-se de que um console de recuperação esteja disponível. Configure o carregamento automático somente depois que o driver estiver funcionando de forma confiável; a SUSE documenta /etc/modules-load.d/os módulos que não são carregados automaticamente quando o dispositivo é detectado.

Verifique o resultado após reiniciar.

Reinicie o sistema mais uma vez durante a janela de manutenção, caso o carregamento persistente seja importante. Confirme se a Inicialização Segura permanece ativada, se a chave pública está cadastrada, se o módulo está presente e se o kernel não reporta nenhum novo erro de verificação ou compatibilidade. Recompile ou reinstale e assine o sistema atualizado .koapós as atualizações do kernel ou do driver do fornecedor.

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

Documentação principal: SUSE SLES 15 SP6: UEFI e chaves do proprietário da máquina ; SUSE: Gerenciando módulos do kernel ; Kernel Linux: Recurso de assinatura de módulos ; Kernel Linux: Compilando módulos externos . O Guia de Administração do SLES 15 SP6 foi atualizado em 17 de setembro de 2026; o comportamento dos comandos para instaladores de drivers de terceiros e versões não padrão do kernel deve ser confirmado com seus respectivos mantenedores.