Publicado em 10/08/2012 às 15:15 | 17677 leituras
Empresa ofereceu detalhes sobre sua solução para a implementação de inicialização através da tecnologia UEFI Secure Boot.
O engenheiro da SUSE Vojtěch Pavlík detalhou os planos da empresa para implementar a tecnologia EFI Secure Boot. A empresa está buscando adotar uma solução similar à que o projeto Fedora quer incluir no Fedora 18. De acordo com uma entrada no blog oficial da SUSE escrita por Olaf Kirch, colega de Pavlík, a empresa também está planejando recomendar sua solução para o projeto openSUSE. Embora similar, os planos da SUSE diferem em pontos chaves do Fedora e diversos desenvolvedores do Fedora já deram indícios de que seu projeto pode modificar sua solução e incorporar algumas mudanças do plano da SUSE.
O plano detalhado por Pavlík prevê que a distribuição SUSE faça uso do bootloader shim desenvolvido pelo Fedora. A SUSE planeja oferecer duas versões separadas do shim, um assinado com uma chave oferecida pela Microsoft (similar à solução do Fedora) e uma assinada com a própria chave da SUSE. Assinar o shim com sua própria chave é algo que a comunidade Fedora descartou quando formularam sua estratégia para o Secure Boot e a solução da SUSE é muito similar em partes dos planos da Canonical para o Ubuntu. Os planos da SUSE prevêm que o processo de inicialização use a chave da Microsoft em sistemas em que a chave da SUSE não estiver presente no hardware.
Um novo aspecto na proposta da Pavlík é uma extensão ao shim que o SUSE desenvolverá e que permitirá que o software carregue chaves públicas adicionais de um arquivo separado e presente no disco. ESsas chaves podem ser usadas para verificar o GRUB e o kernel Linux mais a frente no processo de inicialização. Nos planos do Fedora, essas chaves serão diretamente integradas ao binários shim, o que obrigaria a ferramenta a ser recompilada e reassinada sempre que uma nova chave fosse adicionada.
Os desenvolvedores da SUSE batizaram as chaves públicas nesse arquivo de MOKs (Machine Owner Keys). Usuários podem acrescentar novas MOKS ao seus sistemas ativando um atalho de teclado no shim e iniciando o que Pavlík chama de "processo de recrutamento". Quando uma nova chave é adicionada, o shim cria um hash dela e salva esse resultado em uma variável "Boot Services Only" no firmware UEFI. Isso permite que o detecte se as chaves foram manipuladas indevidamente.
Tal qual os planos do Fedora, o inicializador minimalista shim vai invocar o GRUB2 caso ele tenha sido assinado com uma chave da própria SUSE ou por uma das MOKs. Para conseguir isso, o shim entrega a lista de MOKs para o GRUB. O próprio inicializador vai verificar a integridade dos kernels que pretende inicializar.
Esse plano para expandir a forma que o shim trabalha deve tornar mais fácil para que usuários inicializem seus próprios kernels com o Secure Boot ativado. Usuários podem simplesmente fornecer seus próprios MOKs através do shim ao invés de ter que assinar o shim e o GRUB com sua própria chave, que então deve ser carregada no firmware UEFI (um processo que difere com cada implementação de hardware). Outro benefício dessa soluçaõ é a capacidade de inicializar diferentes kernels de diferentes distribuições. Elas podem ser verificadas com a inclusão de um MOK para cada distribuição. Essa soluçaõ facilita a vida do usuário, mas contradiz um dos conceitos do UEFI, que foi criado para facilitar o "dual-booting" ao dar ao usuário a escolha de diferentes inicializadores durante a ativação da máquina.
A solução da SUSE também permite que o usuário modifique livremente sua versão do GRUB2 e consiga usá-la para inicializar seus sistemas. Isso está de acordo com a cláusula de "anti-Tivoização" presente na GPLv3 de deve evitar o problema de divulgação das chaves de assinatura, que fez com que a Canonical evitasse o uso do GRUB2 em sua solução.
Matthew Garrett, desenvolvedor da Red Hat que está liderando o desenvolvimento da solução de Secure Boot do Fedora, chamou a implementação da SUSE do arquivo MOK e sua proteção através da variável UEFI Boot Services Only de "uma solução incrivelmente elegante". Garrett assume que a extensão do inicializador shim a ser criado pela SUSE vai certamente ser usado na solução de inicialização do Fedora pois simplifica o processo, mas não afirmou quando isso iria acontecer. Greg Kroah-Hartman, parceiro da Linux Foundation e mantenedor do kernel Linux estável, também afirmou em uma entrada no Google+ que ele gostou da solução da SUSE. Enquanto isso, Josh Boyer, que está mantendo o kernel para o Fedora, postou uma longa entrada em seu blog pessoal que resume seus experimentos com o Secure Boot. Esse post oferece algumas de suas descobertas sobre o Secure Boot e como ele afeta o Linux e também destaca alguns problemas que ainda existem nessa área.