Aplica-se a SUSE Linux Enterprise Desktop 15 SP5

17 UEFI (Unified Extensible Firmware Interface) #

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 representam uma visão geral da UEFI, são apenas dicas sobre como determinados recursos são implementados no SUSE Linux Enterprise Desktop.

17.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 Desktop, a placa-mãe e o firmware on-board podem ser considerados a “plataforma”. Em outras palavras, 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, um driver localizado na memória flash de uma placa PCI Express ou no disco, ou uma atualização do próprio firmware.

Para usar 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 é confiável.

É 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.

17.1.1 Implementação no SUSE Linux Enterprise Desktop #

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

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

Por padrão, o recurso Boot Seguro está habilitado nas instalações UEFI/x86_64. Você encontra a opção Habilitar Suporte a Boot Seguro na guia Opções de Código de Boot da caixa de diálogo Configurações do Carregador de Boot. Ela suporta a inicialização quando o boot seguro está ativado no firmware, tornando possível inicializar mesmo quando está desativada.

Figura 17.1: Suporte a boot seguro #

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 um carregador de boot com assinatura digital que o firmware reconheça como uma chave confiável. Teoricamente, essa chave é 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 17.2: UEFI: processo de boot seguro #

Na camada de implementação, o SUSE usa o carregador shim, que é instalado por padrão. Trata-se de uma solução inteligente que evita problemas legais e simplifica consideravelmente as etapas de certificação e assinatura. A tarefa do carregador shim é carregar um carregador de boot, como GRUB 2, e verificá-lo; por sua vez, o carregador de boot carrega 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:

O primeiro tipo são as chamadas “Variáveis Autenticadas”, que podem ser atualizadas tanto do processo de boot (conhecido como Ambiente de Serviços de Boot) quanto do OS em execução. Isso pode ser feito 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 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 (“Variável Apenas de Serviços de Boot”) que ajuda a implementar o Boot Seguro de maneira segura, pronta para código-fonte aberto e, portanto, compatível com GPLv3.

O SUSE começa com shim: um carregador de boot EFI pequeno e simples assinado pela SUSE e pela Microsoft.

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.

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

Para substituir kernels, drivers ou outros componentes específicos que fazem parte do processo de boot, você precisa usar as Chaves do Proprietário da Máquina (MOKs, Machine Owner Keys). A ferramenta mokutil pode ajudá-lo a gerenciar as MOKs.

Você pode criar uma solicitação de registro de MOK com mokutil. A solicitação é armazenada em uma variável em tempo de execução (RT, Runtime) UEFI chamada MokNew. No próximo boot, o carregador de boot shim detecta a MokNew e carrega o MokManager, que inclui várias opções. Você pode usar as opções Registrar chave do disco e Registrar hash do disco para adicionar a chave à MokList. Use a opção Registrar MOK para copiar a chave da variável MokNew.

Normalmente, o registro de uma chave do disco é feito quando o shim falha ao carregar o grub2 e efetua fallback para carregar o MokManager. Como a MokNew ainda não existe, você tem a opção de localizar a chave na partição UEFI.

17.1.3 Inicializando um kernel personalizado #

As informações a seguir são baseadas no https://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 https://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. Tipo:
```
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.

17.1.4 Usando drivers que não são de caixa de entrada #

Não há suporte para adição de drivers que não são de caixa de entrada (isto é, drivers que não vêm com o SUSE Linux Enterprise Desktop) durante a instalação com o Boot Seguro habilitado. Por padrão, a chave de assinatura usada para SolidDriver/PLDP não é confiável.

É possível instalar drivers de terceiros durante a instalação, com o Boot Seguro habilitado de duas formas diferentes. Nos dois casos:

Adicionar as chaves necessárias ao banco de dados do firmware usando as ferramentas de gerenciamento do firmware/sistema antes da instalação. Essa opção depende do hardware específico que você usa. Fale com o fornecedor do hardware para obter mais informações.
Usar uma ISO do driver inicializável em https://drivers.suse.com/ ou pedir ao fornecedor do hardware para inscrever as chaves necessárias na lista MOK na primeira inicialização.

Para usar a ISO do driver inicializável para inscrever as chaves do driver na lista MOK, siga estas etapas:

Grave a imagem ISO acima em um meio de CD/DVD vazio.
Inicie a instalação usando o novo meio de CD/DVD, com a mídia de instalação padrão em mãos ou um URL para um servidor de instalação de rede.
Ao fazer uma instalação de rede, digite o URL da fonte de instalação de rede na linha de comando de boot usando a opção install=.
Ao instalar de uma mídia ótica, o instalador inicializará primeiro do kit do driver e, em seguida, solicitará para inserir o primeiro disco de instalação do produto
Um initrd com os drivers atualizados será usado para instalação.

Para obter mais informações, consulte https://drivers.suse.com/doc/Usage/Secure_Boot_Certificate.html.

17.1.5 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.
Suporte ao modo de vídeo da UEFI. 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.
Desde o SUSE Linux Enterprise Server 15 SP3, o Kexec e o Kdump são suportados no modo de Boot Seguro.

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

Para que o Boot Seguro não seja facilmente ignorado, determinados 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.
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.

17.2 Mais informações #

https://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):
https://en.opensuse.org/openSUSE:UEFI: UEFI com openSUSE.