São as traduções de duas postagens que James Bottomley fez em seu blog. A primeira postagem foi feita em 1º de fevereiro e se chama "LCA2013 e Reestruturando a Inicialização Segura"
Fiquei quieto um pouco, então é hora de dar uma atualização sobre o que está acontecendo com o carregador de inicialização seguro da Linux Foundation (especialmente que foi apresentado no LCA2013). (Link para os slides)
A essência do problema é que GregKH (desenvolvedor do kernel Greg Kroah-Hartman) descobriu no início de dezembro que o Pre-BootLoader proposto não funcionaria em sua forma atual com o Gummiboot. Isso foi um pouco assustador porque significava que não estava cumprindo a missão da Linux Foundation de ativar todos os bootloaders. Na pesquisa, o motivo era simples: o Gummiboot foi criado para demonstrar que você poderia fazer um bootloader pequeno e simples que tiraria proveito de todos os serviços disponíveis na plataforma UEFI em vez de ser um carregador de link massivo como o GRUB. Infelizmente, isso significa que você inicializa os kernels usando a função BootServices-> LoadImage (), o que significa que o kernel a ser inicializado deve passar pelas verificações de inicialização segura na plataforma UEFI. Originalmente o Pre-BootLoader, como calço (Bootloader de Mathew Garrett), foi escrito para usar o carregamento de link PE / Coff para superar as verificações de inicialização seguras. Infelizmente, isso significa que algo executado pelo Pre-BootLoader também deve usar o carregamento de link para vencer as verificações de inicialização segura em qualquer coisa que ele deseja carregar e, portanto, Gummiboot, que deliberadamente não é um carregador de link, não funcionará sob este esquema.
Então eu tive que reestruturar e reescrever: O problema agora ia de "como criar um carregador de link assinado pela Microsoft que obedeça às suas políticas" para "como permitir que todos os filhos do carregador de boot usem a função BootServices-> LoadImage () de forma de obedecer às suas políticas. Felizmente, existe uma maneira de interceptar a infraestrutura de assinatura da plataforma UEFI instalando seu próprio protocolo de segurança de arquitetura. Infelizmente, a especificação de inicialização da plataforma não é realmente parte da especificação UEFI, mas felizmente é implementada por todos os sistemas Windows 8 que você encontrar. A nova arquitetura intercepta esse protocolo e adiciona sua própria verificação de segurança. No entanto, há um segundo problema: enquanto estamos no retorno de chamada do protocolo de segurança da arquitetura, não necessariamente possuímos a tela do sistema UEFI, tornando completamente impossível fazer um teste de usuário para autorizar a execução do binário. Felizmente, existe uma maneira não interativa de fazer isso: o mecanismo MOK (Chave do proprietário da máquina SUSE). Portanto, o Linux Foundation Pre-BootLoader agora evoluiu para usar variáveis MOK padrão para armazenar hashes binários autorizados.
O resultado de tudo isso é que agora você pode usar o Pre-BootLoader com Gummiboot (assim como foi feito na demonstração no LCA2013). Para inicializar, você deve adicionar 2 hashes: um para o próprio Gummiboot e outro para o kernel que deseja inicializar, mas na verdade é uma coisa boa porque agora você tem uma única política de segurança controlando toda a sequência de inicialização. O próprio Gummiboot também foi corrigido para reconhecer uma falha devido à inicialização segura e exibe uma mensagem informando qual hash deve ser registrado.
Farei um post separado explicando como funciona a nova arquitetura, mas achei melhor explicar o que aconteceu no mês passado.
E este segundo post que ele fez ontem e se chama "Lançado o Sistema de Inicialização Segura do Linux Foundation"
Conforme prometido, aqui está o Linux Foundation Secure Boot System. Na verdade, foi lançado para nós pela Microsoft no dia 6 de fevereiro, mas com as viagens, conferências e reuniões não tive tempo de validar tudo até hoje. Os arquivos são:
PreLoader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
Crie também uma imagem mini-USB inicializável; (Tem que instalar no USB usando o dd; a imagem tem partições GPT, então usa todo o disco). Ele tem um shell EFI onde o kernel deveria estar e usa gummiboot para carregá-lo. Você pode encontrá-lo aqui (md5sum 7971231d133e41dd667a184c255b599f).Para usar a imagem mini-USB, você deve inserir os hashes para o loader.efi (na pasta \ EFI \ BOOT) e o shell.efi (na pasta raiz). Também inclui uma cópia do KeyTool.efi que você precisa inserir no hash para executar.
O que aconteceu ao KeyTool.efi? Originalmente, faria parte do nosso kit autografado. No entanto, durante o teste, a Microsoft descobriu que, devido a um bug em uma das plataformas UEFI, ela poderia ser usada para remover a chave da plataforma programaticamente, o que arruinaria o sistema de segurança da UEFI. Até que possamos resolver isso (temos o fornecedor privado no loop), eles se recusaram a assinar o KeyTool.efi, embora você possa autorizá-lo adicionando variáveis MOK se quiser executá-lo.
Deixe-me saber como foi, porque estou interessado em obter feedback sobre o que funciona e o que não funciona. Em particular, estou preocupado com o fato de que a substituição do protocolo de segurança pode não funcionar em algumas plataformas, portanto, gostaria de saber se isso não funcionaria para elas.
Fontes:
http://blog.hansenpartnership.com/lca2013-and-rearchitecting-secure-boot/
http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/
Decida se são boas ou más notícias.