Eu prefiro descrever o processo de inicialização como:
1.) Aplique energia, inicie a execução do firmware UEFI com capacidade de inicialização segura
2.) O firmware verifica qualquer potencial carregador de inicialização contra conjuntos de chaves de Inicialização Segura, que são armazenados no sistema NVRAM (ou padrões compilados).
3.) O gerenciador de inicialização deve verificar o kernel do SO da mesma maneira.
4.) Para ser compatível com Secure Boot e significativamente efetivo, o kernel do Linux também deve checar criptograficamente quaisquer módulos do kernel carregados.
Os kernels modernos incluem um recurso opcional para o ponto 4): os kernels de distribuições corporativas, como o RedHat, o habilitam automaticamente ao inicializar em um sistema compatível com Boot Seguro. Os kernels personalizados podem ser fornecidos com uma chave de assinatura no momento da compilação.
Para os kernels RedHat, no tempo de execução, a lista de chaves permitidas é (a chave usada para assinar o kernel principal) + (o que estiver no conjunto de chaves Secure Boot db ) + (chaves permitidas no conjunto MOK usado por shim.efi , se existir).
Portanto, se você usar o Secure Boot e planejar usar módulos de kernel de terceiros com kernels de distribuição, será necessário assiná-los e obter a chave de assinatura na lista permitida. Mas se você rola seus próprios kernels e / ou assumiu o controle de suas chaves de Inicialização Segura, sua chave privada de Inicialização Segura também pode ser usada para assinar os módulos de terceiros.
Para que você possa assumir o controle da Inicialização Segura, seu sistema precisa permitir que você modifique as chaves de Inicialização Segura. Existem quatro (conjuntos de) chaves nas quais você está interessado:
-
db, o conjunto de certificados públicos de permitido bootloaders e / ou somas de verificação SHA256 de permitido bootloaders -
dbxdo conjunto de certificados públicos e / ou somas de verificação dos bootloaders explicitamente na lista negra . -
KEK, o conjunto de certificados públicos usados para validar quaisquer atualizações assinadas paradb - e
PKa única Chave primária (certificado) usada para validar as atualizações assinadas paraKEK.
Por padrão, o sistema deve ter o PK do fabricante do hardware e as chaves do fabricante da Microsoft e do hardware em KEK e db . Isso permite o uso de carregadores de inicialização certificados pela Microsoft (que incluem o "shim" usado com alguns Linuxes) e as ferramentas de atualização de firmware do fabricante de hardware prontas para uso.
O primeiro passo seria examinar as configurações do UEFI BIOS Setup com muito cuidado. Em alguns sistemas, a configuração permite adicionar e excluir todas as chaves de inicialização segura. Em outros sistemas, as únicas opções são redefinidas de volta para as chaves padrão de fábrica e limpando todas as chaves. Se sua instalação exigir a limpeza de todas as chaves para poder usar chaves personalizadas, convém fazer o backup de todas as chaves existentes primeiro, para que você possa restaurá-las seletivamente, se desejar.
De acordo com a especificação de inicialização segura, se PK estiver desmarcado, a inicialização segura estará no modo de configuração, o que permite a edição gratuita de todos os conjuntos de chaves e a inicialização irrestrita. Então, idealmente, você quer apenas remover o PK , mas deixar as outras chaves como estão por enquanto.
No melhor dos casos, isso permite editar as chaves de inicialização segura de dentro de um sistema operacional compatível com UEFI usando as ferramentas apropriadas; Na pior das hipóteses, você precisa usar o UEFI Shell e o utilitário keytool.efi de James Pacote de efitools de Bottomley .
Seu objetivo final deve ser algo assim:
- o
dbset deve conter:- seu próprio certificado de chave pública, para inicializar coisas que você assinou explicitamente
- talvez o certificado de assinatura do kernel da sua distribuição Linux favorita, se você quiser usar kernels pré-empacotados sem re-assiná-los manualmente
- talvez o certificado do fornecedor de hardware, para permitir a instalação de atualizações de firmware, se necessário
- talvez o certificado UEFI de terceiros da Microsoft, para permitir o uso de carregadores de inicialização pré-empacotados do Linux e de mídia de inicialização do Linux ao vivo sem renomá-los ou desativá-los explicitamente.
- talvez o certificado de assinatura de sistema operacional da Microsoft, se você fizer uma dupla inicialização com o Windows
- o
KEKset deve conter:- seu próprio certificado, para atualizar
dbedbx - se o sistema incluir sistemas operacionais Microsoft compatíveis com UEFI, talvez você queira incluir o certificado KEK da Microsoft, pois as atualizações da Microsoft às vezes incluem atualizações para
dbe / oudbxe essas atualizações não serão instaladas com êxito se o acesso ao Secure Inicialização negada
- seu próprio certificado, para atualizar
- e, finalmente, quando o restante estiver configurado como você deseja, você deverá colocar seu próprio certificado em
PKpara tornar a Inicialização segura novamente.