UEFI (Unified Extensible Firmware Interface) | Guia de Administração

Documentação do SUSE Linux Enterprise Desktop › Guia de Administração › Sistema › UEFI (Unified Extensible Firmware Interface)

ConteúdoConteúdo

Guia de Administração

Navegação←→

Aplica-se a SUSE Linux Enterprise Desktop 12

14 UEFI (Unified Extensible Firmware Interface)

14.1 Boot seguro
14.2 Para obter mais informações

UEFI (Unified Extensible Firmware Interface) é a interface entre o firmware que vem com o hardware do sistema, todos os componentes do hardware do sistema e o sistema operacional.

A UEFI está se tornando cada vez mais disponível em sistemas PC e substituindo o PC-BIOS tradicional. Por exemplo, a UEFI suporta apropriadamente sistemas de 64 bits e oferece inicialização segura (“Boot Seguro”, firmware versão 2.3.1c ou superior necessário), que é um dos recursos mais importantes. Por fim, com a UEFI, um firmware padrão estará disponível em todas as plataformas x86.

A UEFI oferece também as seguintes vantagens:

Inicialização de discos grandes (mais de 2 TiB) com GPT (Tabela de Partição GUID).
Drivers e arquitetura independente da CPU.
Ambiente pré-OS flexível com recursos de rede.
CSM (Módulo de Suporte de Compatibilidade) para suportar inicialização de sistemas operacionais legados por emulação do tipo PC-BIOS.

Para obter mais informações, consulte http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface. As seguintes seções não são uma visão geral da UEFI, são apenas dicas sobre como alguns recursos são implementados no SUSE Linux Enterprise.

14.1 Boot seguro #

Para a UEFI, proteger o processo de boot significa estabelecer uma cadeia de confiança. A “plataforma” é a raiz da cadeia de confiança; no contexto do SUSE Linux Enterprise, a placa-mãe e o firmware on-board podem ser considerados a “plataforma”. Explicando de uma maneira um pouco diferente, imagine o fornecedor do hardware e a cadeia de confiança que parte desse fornecedor para os fabricantes dos componentes, os fornecedores de OS, etc.

A confiança é expressada através da criptografia de chave pública. O fornecedor do hardware coloca a chamada PK (Chave de Plataforma) no firmware, representando a base da confiança. A relação de confiança com os fornecedores do sistema operacional e os outros é documentada pela assinatura das chaves usando a Chave de Plataforma.

Por fim, a segurança é estabelecida exigindo que nenhum código seja executado pelo firmware, exceto se tiver sido assinado por uma das chaves “confiáveis”, seja um carregador de boot de OS, algum driver localizado na memória flash de uma placa PCI Express ou no disco, seja uma atualização do próprio firmware.

Basicamente, para usar o Boot Seguro, o carregador de OS deve ser assinado com uma chave de confiança do firmware, e você precisa que o carregador de OS verifique se o kernel que ele carrega pode ser confiado.

É possível adicionar Chaves de Troca de Chave (KEK) ao banco de dados de chaves UEFI. Dessa forma, é possível usar outros certificados, desde que sejam assinados com a parte privada da PK.

14.1.1 Implementação no SUSE Linux Enterprise #

A Chave de Troca de Chave (KEK) da Microsoft é instalada por padrão.

Nota: GPT (Tabela de Partição GUID) obrigatória

O recurso Boot Seguro requer que a GPT (Tabela de Partição GUID) substitua o particionamento antigo por um MBR (Master Boot Record).

Se o YaST detectar o modo EFI durante a instalação, ele tentará criar uma partição GPT. A UEFI espera encontrar os programas EFI na ESP (Partição de Sistema EFI) formatada por FAT.

O suporte a Boot Seguro UEFI requer basicamente um carregador de boot com assinatura digital que o firmware reconheça como uma chave confiável. Para ser útil aos clientes do SUSE Linux Enterprise, a chave precisa ser, antes de tudo, de confiança do firmware, sem exigir intervenção manual.

Há duas formas de conseguir isso. Uma é trabalhar com os fornecedores do hardware para que eles endossem uma chave do SUSE, que o SUSE usará para assinar o carregador de boot. A outra é utilizar o programa de Certificação de Logotipo do Windows da Microsoft para certificar o carregador de boot e para a Microsoft reconhecer a chave de assinatura do SUSE (isto é, assiná-lo com sua KEK). Até agora, o SUSE assinava o carregador pelo Serviço de Assinatura UEFI (que é a Microsoft, neste caso).

Figura 14.1 UEFI: processo de boot seguro #

Na camada de implementação, o SUSE usa o carregador shim, uma solução inteligente que evita problemas legais e simplifica a etapa de certificação e assinatura consideravelmente. A tarefa do carregador shim é carregar um carregador de boot, como eLILO ou GRUB 2 e verificá-lo; e o carregador de boot em troca vai carregar os kernels assinados apenas por uma chave do SUSE. O SUSE oferece esta funcionalidade desde o SLE11 SP3 em instalações novas que tenham o Boot Seguro UEFI habilitado.

Há dois tipos de usuários confiáveis:

Primeiro, os que detêm as chaves. A Chave de Plataforma (PK) permite quase tudo. A Chave de Troca de Chave (KEK) permite tudo o que pode uma PK, exceto modificar a PK.
Segundo, qualquer pessoa com acesso físico à máquina. Um usuário com acesso físico pode reinicializar a máquina e configurar a UEFI.

A UEFI oferece dois tipos de variáveis para atender às necessidades desses usuários:

A primeira são as chamadas “Variáveis Autenticadas”, que podem ser atualizadas tanto do processo de boot (o chamado Ambiente de Serviços de Boot) quanto do OS em execução, mas apenas quando o novo valor da variável é assinado com a mesma chave que assinou o valor antigo da variável. E elas só podem ser anexadas ou modificadas para um valor com número de série maior.
A segunda são as chamadas “Variáveis Apenas de Serviços de Boot”. Essas variáveis estão acessíveis a qualquer código executado durante o processo de boot. Após o término do processo de boot e antes de iniciar o OS, o carregador de boot deve chamar ExitBootServices. Depois disso, essas variáveis não estarão mais acessíveis, e o OS não poderá usá-las.

As várias listas de chaves UEFI são do primeiro tipo, já que permitem atualização online, adição e lista negra de chaves, drivers e impressões digitais do firmware. É o segundo tipo de variável, a “Variável Apenas de Serviços de Boot”, que ajuda a implementar o Boot Seguro de forma segura, pronta para código-fonte aberto e também compatível com GPLv3.

O SUSE começa com o shim, um carregador de boot EFI pequeno e simples, que foi originalmente desenvolvido pela Fedora. Ele é assinado por um certificado assinado pela KEK do SUSE e um certificado emitido pela Microsoft, com base nas KEKs disponíveis no banco de dados de chaves UEFI do sistema.

Dessa forma, o shim pode ser carregado e executado.

O shim continua para verificar se o carregador de boot que deseja carregar é confiável. Em uma situação padrão, o shim usa um certificado do SUSE independente incorporado. Além disso, o shim permite “inscrever” outras chaves, anulando a chave padrão do SUSE. A seguir, nós as chamamos de “Chaves do Proprietário da Máquina” ou MOKs, para abreviar.

Em seguida, o carregador de boot verifica e inicializa o kernel, e o kernel faz o mesmo com os módulos.

14.1.2 MOK (Chave do Proprietário da Máquina) #

Se o usuário (“proprietário da máquina”) deseja substituir algum componente do processo de boot, as Chaves do Proprietário da Máquina (MOKs) deverão ser usadas. A ferramenta mokutils ajuda com a assinatura dos componentes e o gerenciamento das MOKs.

O processo de inscrição começa com a reinicialização da máquina e a interrupção do processo de boot (por exemplo, pressionando uma tecla) quando o shim é carregado. O shim entra no modo de inscrição, permitindo ao usuário substituir a chave padrão do SUSE pelas chaves de um arquivo na partição de boot. Se o usuário quiser, o shim calculará um hash desse arquivo e colocará o resultado em uma variável “Apenas de Serviços de Boot”. Dessa forma, o shim pode detectar qualquer mudança no arquivo feita fora dos Serviços de Boot e evitar assim uma violação da lista de MOKs aprovadas pelo usuário.

Tudo isso acontece durante a inicialização, apenas o código verificado é executado agora. Portanto, apenas um usuário presente no console pode utilizar o conjunto de chaves do proprietário da máquina. Não é possível que seja um malware ou um invasor com acesso remoto ao OS, pois invasores ou malware só podem mudar o arquivo, mas não o hash armazenado na variável “Apenas de Serviços de Boot”.

O carregador de boot, após ser carregado e verificado pelo shim, chamará de novo o shim para verificar o kernel, evitando a duplicação do código de verificação. O shim usa a mesma lista de MOKs para isso e avisa o carregador de boot se ele pode carregar o kernel.

Dessa forma, você pode instalar seu próprio kernel ou carregador de boot. Só é necessário instalar um novo conjunto de chaves e autorizá-las estando fisicamente presente durante a primeira reinicialização. Como as MOKs são uma lista, e não apenas uma única MOK, é possível fazer com que o shim confie nas chaves de vários fornecedores diferentes, permitindo dual-boot e multi-boot pelo carregador de boot.

14.1.3 Inicializando um kernel personalizado #

As informações a seguir são baseadas no http://en.opensuse.org/openSUSE:UEFI#Booting_a_custom_kernel.

O Boot Seguro não impede você de usar um kernel autocompilado. Você deve assiná-lo com seu próprio certificado e tornar esse certificado reconhecível para o firmware ou a MOK.

Crie uma chave X.509 personalizada e um certificado usados para assinatura:
```
openssl req -new -x509 -newkey rsa:2048 -keyout key.asc \
  -out cert.pem -nodes -days 666 -subj "/CN=$USER/"
```
Para obter mais informações sobre como criar certificados, consulte http://en.opensuse.org/openSUSE:UEFI_Image_File_Sign_Tools#Create_Your_Own_Certificate.

Empacote a chave e o certificado como uma estrutura PKCS#12:

openssl pkcs12 -export -inkey key.asc -in cert.pem \
  -name kernel_cert -out cert.p12

Gere um banco de dados NSS para usar com o comando pesign:
```
certutil -d . -N
```
Importe a chave e o certificado incluídos no PKCS#12 para o banco de dados NSS:
```
pk12util -d . -i cert.p12
```

“Proteja” o kernel com a nova assinatura usando o comando pesign:

pesign -n . -c kernel_cert -i arch/x86/boot/bzImage \
  -o vmlinuz.signed -s

Liste as assinaturas na imagem do kernel:
```
pesign -n . -S -i vmlinuz.signed
```
Neste momento, é possível instalar o kernel em /boot, como de costume. Como o kernel agora tem uma assinatura personalizada, o certificado usado para a assinatura deve ser importado para o firmware ou a MOK UEFI.
Converta o certificado no formato DER para importá-lo para o firmware ou a MOK:
```
openssl x509 -in cert.pem -outform der -out cert.der
```
Copie o certificado para o ESP para facilitar o acesso:
```
sudo cp cert.der /boot/efi/
```
Use mokutil para iniciar a lista de MOKs automaticamente.
1. Importe o certificado para o MOK:
```
mokutil --root-pw --import cert.der
```
  A opção --root-pw habilita a utilização do usuário root diretamente.
2. Consulte a lista dos certificados preparados para inscrição:
```
mokutil --list-new
```
3. Reinicialize o sistema. O shim deve iniciar o MokManager. É necessário digitar a senha de root para confirmar a importação do certificado para a lista da MOK.
4. Verifique se a chave recém-importada foi inscrita:
```
mokutil --list-enrolled
```
1. Se preferir, este é o procedimento para iniciar a MOK manualmente:
  Reinicialize
2. No menu do GRUB 2, pressione a tecla 'c'.
3. Digite:
```
chainloader $efibootdir/MokManager.efi
boot
```
4. Selecione Enroll key from disk (Inscrever chave do disco).
5. Navegue até o arquivo cert.der e pressione Enter.
6. Siga as instruções para inscrever a chave. Normalmente, você pressiona '0' e 'y' para confirmar.
  Se preferir, o menu do firmware pode oferecer maneiras de adicionar uma nova chave ao Banco de Dados de Assinatura.

14.1.4 Recursos e limitações #

Ao inicializar no modo Boot Seguro, os seguintes recursos se aplicam:

Instalação no local do carregador de boot padrão UEFI, um mecanismo para manter ou restaurar a entrada de boot EFI.
Reinicialização por UEFI.
O hipervisor do Xen inicializará com UEFI quando não houver nenhum BIOS legado para o qual fazer fallback.
Suporte a boot PXE IPv6 da UEFI.
A UEFI oferece suporte ao modo de vídeo. O kernel pode recuperar o modo de vídeo da UEFI para configurar o modo KMS com os mesmos parâmetros.
A inicialização UEFI de dispositivos USB é suportada.

Ao inicializar no modo Boot Seguro, as seguintes limitações se aplicam:

Para que o Boot Seguro não seja facilmente desviado, alguns recursos do kernel são desabilitados durante a execução no modo Boot Seguro.
O carregador de boot, o kernel e os módulos do kernel devem ser assinados.
Kexec e Kdump estão desabilitados.
A hibernação (suspensão no disco) é desabilitada.
O acesso a /dev/kmem e /dev/mem não é possível, nem mesmo como usuário root.
O acesso à porta de E/S não é possível, nem mesmo como usuário root. Todos os drivers gráficos X11 devem usar um driver do kernel.
O acesso a PCI BAR por sysfs não é possível.
O custom_method em ACPI não está disponível.
Debugfs para o módulo asus-wmi não está disponível.
O parâmetro acpi_rsdp não tem nenhum efeito sobre o kernel.

14.2 Para obter mais informações #

http://www.uefi.org: Home page da UEFI onde você encontra as especificações atuais da UEFI.
Publicações no blog por Olaf Kirch e Vojtěch Pavlík (o capítulo acima é quase todo baseado nessas publicações):
http://en.opensuse.org/openSUSE:UEFI: UEFI com openSUSE.

Imprimir esta página