Como comparar chaves de inicialização seguras armazenadas no banco de dados de firmware da placa-mãe com os arquivos .efi assinados?

Question

É muito fácil habilitar a inicialização segura em uma máquina virtual, mas estou lutando para fazer o mesmo com o OpenSUSE no meu computador antigo de 2012, que se recusa a inicializar no modo de inicialização segura, mesmo na configuração padrão (com as chaves da Microsoft, ao que parece) . Gostaria de solucionar a parte mais crítica: as chaves correspondem entre o firmware e o calço? Como verificar isso?

Answer 1

O que é inicialização segura?

CitandoPartícula.io:

...Inicialização segura refere-se ao processo de autenticação do firmware e do sistema operacional de um dispositivo em relação a uma chave criptográfica segura conhecida colocada no dispositivo no momento da fabricação. Essa autenticação ocorre toda vez que o dispositivo é inicializado para validar se o firmware ou código que está sendo carregado é a versão legítima que foi colocada ali por quem o produziu.

A citação acima e o link referem-se a dispositivos IoT. A citação ainda é válida para os PCs se os considerarmos “coisas”. No caso da pergunta do OP não importa a idade do aparelho, pois a premissa da cotação era a mesma em 2012 e agora. Vou começar o restante desta resposta de solução de problemas assumindo que o repositório de chaves precisa ser "redefinido", o que o OP já fez, mas estou fazendo isso para o benefício de futuros visitantes.

Etapas detalhadas

Vamos gerar uma lista numerada do que precisamos fazer para dividir esta tarefa em partes menores:

1. Leia emComo funciona o Secure Boot no Linux em relação ao SuSE. Observação: A implementação nesse link em 2012 é basicamente como todas as distribuições implementaram inicialização segura.
   • Para simplificar, vou postar a "carne" desse artigo (para aqueles que lêem superficialmente), pois este é o problema fundamental que o OP está enfrentando):
2. Redefina o firmware do Mac para os padrões de fábricarealizando uma redefinição de PRAM
3. Use estas etapasdelineado por Roderick Smith
   • A etapa 3 pode ser simplificada se o OpenSuSE Live ISO incluir o programa MokManager ou o programa MokUtil.
4. Registre a chave desejada no banco de dados MOK.
   • Opcional: Se você seguir as etapas acima (itens 3 e 4), acabará registrando a chave rEFInd e a chave SuSE. Se você planeja inicializar OSX e OpenSuSE com inicialização dupla, recomendo usar este Boot Manager. Se você planeja usar apenas o OpenSuSE, você só precisa registrar esse certificado.
5. Agora você shimdeve estar ciente das novas chaves e passar corretamente o processo para o Grub2, e o Grub 2 inicializará o OpenSuSE.

O que fazer se as etapas acima falharem

Consulte a seção Solução de problemas deInstale o openSUSE em um Mac. Como palpite, citando Roderick Smith novamente:

Algumas implementações de EFI (principalmente anteriores a 2014) não cumprem bem as opções de inicialização definidas por meio do efibootmgr do Linux ou de outras ferramentas. Você também pode não ter acesso a esses utilitários, como se precisar instalar o rEFInd no Windows. Nesses casos, pode ser necessário alterar o nome do carregador de boot para que o EFI o veja como o carregador de boot padrão. O rEFInd deve então inicializar quando sua NVRAM não tiver informações sobre carregadores de inicialização específicos para usar.

No caso acima, renomeie shim<arch>.efio arquivo do OpenSuSE para boot<arch>.efie coloque-o no BOOTdiretório (se não houver BOOTdiretório, coloque-o na raiz) onde archestá x32ou x64 Se este método funcionar, o firmware do OP suporta apenas a inicialização a partir de um arquivo. Ver:Opções alternativas de nomenclatura.

Por outro lado, correções como essa são necessárias mesmo em sistemas mais novos. Ver:Atualize a NVRAM para que shimx64.efi seja executado em vez de grubx64.efi no sistema Debian para inicialização segura. Sinto a dor do OP nesse sentido.