07 - Systemd-boot (Bootloader)

O systemd-boot (historicamente conhecido como gummiboot) é um carregador de inicialização (bootloader) minimalista, nativo e integrado ao ecossistema systemd. Ele opera exclusivamente sobre a especificação UEFI (Unified Extensible Firmware Interface) e atua estritamente como um EFI Boot Manager leve, delegando a responsabilidade de execução ao núcleo do sistema operacional através da arquitetura de binários portáveis do kernel Linux (EFISTUB).

A filosofia de design do systemd-boot contrasta radicalmente com a complexidade estrutural de bootloaders tradicionais como o GRUB2. Enquanto o GRUB2 opera como um quase-sistema operacional completo — contendo centenas de drivers de arquivo integrados (ext4, xfs, btrfs), linguagens de scripting internas e múltiplos estágios de carga em disco —, o systemd-boot não inclui nenhum driver de sistema de arquivos próprio. Ele depende integralmente do driver de sistema de arquivos (tipicamente FAT32 / VFAT) provido pelo próprio firmware UEFI do computador para acessar a Partição de Sistema EFI (EFI System Partition - ESP).

1. Arquitetura e Princípios de Design

A premissa fundamental do systemd-boot é eliminar a redundância de código entre o firmware da placa-mãe e o carregador de boot. Como os firmwares UEFI modernos possuem capacidades nativas de navegação em partições FAT32, leitura de variáveis NVRAM e execução de binários no formato PE/COFF (.efi), o systemd-boot abstrai a complexidade do menu de seleção sem duplicar as funções do firmware.

┌─────────────────────────────────────────────────────────────────────────┐
│                           FIRMWARE UEFI (Ring -2)                       │
│  - Leitura da NVRAM / Tabela GPT                                        │
│  - Carrega o Driver VFAT NATIVO                                         │
│  - Executa a aplicação EFI registrada                                   │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                    SYSTEMD-BOOT (/EFI/BOOT/BOOTX64.EFI)                 │
│  - Lê opções de /loader/loader.conf                                     │
│  - Processa os arquivos de entrada em /loader/entries/*.conf            │
│  - Exibe o menu estático ou aplica o timeout configurado                │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                    KERNEL LINUX COMO EFISTUB (PE/COFF)                  │
│  - O kernel (/vmlinuz-linux) é invocado DIRETAMENTE pela chamada UEFI   │
│  - Passa os parâmetros de boot e o ponteiro da imagem /initramfs-linux  │
│  - Assume o controle dos descritores de hardware e inicia o PID 1       │
└─────────────────────────────────────────────────────────────────────────┘

1.1. Principais Diferenças Arquiteturais: GRUB2 vs. systemd-boot

2. A Invocação Direta via Kernel EFISTUB

Para compreender a eficiência do systemd-boot, é necessário analisar a funcionalidade EFISTUB (EFI Boot Stub) do kernel Linux.

Desde a versão 3.3 do kernel, os compiladores do núcleo incorporam um cabeçalho PE/COFF (Portable Executable / Common Object File Format) diretamente na imagem compilada do binário do kernel (vmlinuz). Essa modificação estrutural faz com que o firmware UEFI enxergue o arquivo do kernel Linux não como uma imagem opaca de dados, mas como uma Aplicação EFI nativa e executável.

Quando o systemd-boot lê uma entrada de menu, ele não descompacta o kernel na RAM nem configura registradores de modo real de CPU x86 por conta própria. Ele invoca a função da API do UEFI StartImage() passando o caminho do /vmlinuz como parâmetro. O próprio firmware UEFI carrega a imagem do kernel na memória física, passa os parâmetros da linha de comando (kernel command line) e o ponteiro do initramfs, transferindo o fluxo de execução sem intermediários.

3. Dissecação do Sistema de Arquivos da ESP (EFI System Partition)

A Partição de Sistema EFI (ESP) é uma partição primária rotulada no esquema GPT com o UUID especial C12A7328-F81F-11D2-BA4B-00A0C93EC93B e formatada obrigatoriamente como FAT32 (VFAT).

Para que o systemd-boot opere de forma transparente, a ESP deve ser montada no sistema de arquivos em /boot ou /efi. A árvore de diretórios padrão sob a especificação do systemd-boot segue a estrutura abaixo:

/boot/ (ESP - Montada como VFAT)
├── EFI/
│   ├── BOOT/
│   │   └── BOOTX64.EFI              <-- Aplicação EFI padrão / fallback do firmware
│   └── systemd/
│       └── systemd-bootx64.efi      <-- Binário primário do systemd-boot
├── loader/
│   ├── loader.conf                  <-- Arquivo de configuração global do bootloader
│   ├── entries/
│   │   ├── arch.conf                <-- Entrada de boot do Kernel Principal
│   │   └── arch-fallback.conf       <-- Entrada de boot de Recuperação
│   └── random-seed                  <-- Semente de aleatoriedade para o RNG do kernel
├── vmlinuz-linux                    <-- Imagem do Kernel com EFISTUB
├── initramfs-linux.img              <-- Imagem da Initramfs Primária
└── initramfs-linux-fallback.img     <-- Imagem da Initramfs de Emergência

4. Arquivos de Configuração Declarativos

Ao contrário do arquivo /boot/grub/grub.cfg — que é uma estrutura ilegível de milhares de linhas gerada por scripts encadeados —, a configuração do systemd-boot segue o padrão de Arquivos de Entrada Independentes (Drop-in Entries), facilitando a automação e evitando a corrupção do menu durante atualizações do sistema.

4.1. O Arquivo Global /loader/loader.conf

Este arquivo controla o comportamento global da interface gráfica do menu do bootloader:

# /boot/loader/loader.conf
default  arch.conf
timeout  4
console-mode max
editor   yes
auto-entries 1
auto-firmware 1

Dicionário de Diretivas do loader.conf:

• default: Especifica qual arquivo contido dentro de /loader/entries/ será selecionado por padrão. Aceita máscaras genéricas (ex: arch-*.conf para pegar a entrada mais recente) ou a palavra-chave @saved para carregar a última opção escolhida manualmente pelo usuário.
• timeout: O tempo limite em segundos que o menu aguardará antes de disparar a entrada padrão. Se configurado como 0 ou menu-disabled, o menu é ocultado e a inicialização ocorre instantaneamente (pressionar a tecla Space ou Shift durante a energização força o menu a reaparecer).
• console-mode: Define a resolução da tela em modo texto UEFI. O valor max força o firmware a utilizar a maior resolução gráfica nativa suportada pelo monitor.
• editor: Chave booleana (yes/no). Determina se o usuário pode pressionar e no menu de boot para alterar temporariamente os parâmetros do kernel na linha de comando. Em ambientes de alta segurança, deve ser definido como no.
• auto-entries: Se ativado (1), inspeciona a partição e cria entradas dinâmicas automáticas para partições de recuperação do Windows (Windows Boot Manager) e seletores EFI de outras distribuições.
• auto-firmware: Se ativado (1), insere automaticamente uma opção no menu chamada Reboot Into Firmware Interface, permitindo reiniciar a máquina diretamente na tela de setup da BIOS/UEFI sem necessidade de pressionar atalhos físicos como F2 ou Del.

4.2. Os Arquivos de Entrada em /loader/entries/*.conf

Cada opção listada no menu de boot é representada por um arquivo de texto individual. Para adicionar um novo kernel ao sistema, basta criar um novo arquivo .conf no diretório /loader/entries/.

Exemplo de entrada para o Arch Linux (/loader/entries/arch.conf):

title   Arch Linux (Kernel Mainline)
version 6.12.1-arch1-1
linux   /vmlinuz-linux
initrd  /intel-ucode.img
initrd  /initramfs-linux.img
options root=UUID=4a3b2c1d-8e7f-4a5b-9c8d-7e6f5a4b3c2d rw quiet loglevel=3

Dissecação das Diretivas de Entrada:

• title: O nome descritivo que será exibido visualmente no menu de seleção.
• version: Versão do kernel (opcional). Utilizada para ordenação automática se o atributo default contiver máscaras.
• linux: O caminho do binário do kernel com suporte a EFISTUB. Nota de Caminho: O caminho deve ser relativo à raiz da Partição de Sistema EFI (/boot). Se a imagem do kernel está salva fisicamente em /boot/vmlinuz-linux, a instrução declara apenas /vmlinuz-linux.
• initrd: O caminho da imagem do sistema de arquivos temporário. Podem ser declaradas múltiplas linhas initrd. No exemplo acima, a primeira linha carrega o microcódigo do processador Intel (/intel-ucode.img) para correção de falhas de hardware no nível de CPU, e a segunda linha carrega o initramfs real da distribuição. O systemd-boot concatena os arquivos na memória em ordem estrita de declaração.
• options: Os parâmetros repassados diretamente para o kernel Linux. Substitui a linha linux /boot/vmlinuz... root=... do GRUB2. Define o volume raiz (root=UUID=...), as permissões de montagem inicial (rw) e os níveis de exibição de logs do kernel (quiet loglevel=3).

5. Instalação, Atualização e o Utilitário bootctl

O gerenciamento do systemd-boot no espaço do usuário é conduzido através da ferramenta nativa bootctl.

5.1. Instalação e Atualização Inicial

Para verificar se o sistema suporta o systemd-boot e se a ESP está montada corretamente:

bootctl status

Para instalar os binários do systemd-boot dentro da Partição de Sistema EFI e registrar a entrada do bootloader na NVRAM do firmware UEFI:

bootctl install

O que o comando bootctl install realiza internamente:

1. Localiza o ponto de montagem da Partição de Sistema EFI (inspecionando /boot ou /efi).
2. Copia o binário /usr/lib/systemd/boot/efi/systemd-bootx64.efi para /boot/EFI/systemd/systemd-bootx64.efi.
3. Copia o mesmo binário para o caminho de fallback padrão da especificação UEFI: /boot/EFI/BOOT/BOOTX64.EFI (garantindo boot caso a NVRAM seja resetada).
4. Cria a estrutura de diretórios /boot/loader/entries/ e o arquivo de configuração basilar /boot/loader/loader.conf.
5. Interage com o driver de variáveis de tempo de execução do kernel (efivarfs) para invocar a API do firmware UEFI e criar uma nova entrada na NVRAM chamada Linux Boot Manager, definindo-a como a primeira opção na ordem de boot (BootOrder).

Para atualizar os binários EFI após uma atualização do pacote systemd:

bootctl update

6. A Especificação de Boot sem Configuração (Type #1 e Type #2 / UKI)

O ecossistema systemd modernizou a inicialização UEFI através das especificações da iniciativa Boot Loader Specification (BLS) e Unified Kernel Image (UKI).

6.1. Unified Kernel Image (UKI) - A Imagem Unificada

A abordagem tradicional de manter o kernel (vmlinuz), o microcódigo (intel-ucode.img), o initramfs e a linha de comando (options) em arquivos separados na ESP possui uma vulnerabilidade de segurança: qualquer processo local rodando como root pode alterar o arquivo /loader/entries/arch.conf ou modificar o initramfs injetando binários maliciosos sem que o firmware perceba.

A arquitetura UKI (Unified Kernel Image) unifica todos os componentes de boot em um único binário PE/COFF compilado:

+-----------------------------------------------------------------------+
|                    UNIFIED KERNEL IMAGE (.EFI)                        |
|                                                                       |
|  [ Seção .efi   ] Binário de Boot do systemd-stub (Stub UEFI)       |
|  [ Seção .osrel ] Conteúdo de /etc/os-release                         |
|  [ Seção .cmdline] Parâmetros da linha de comando (root=UUID=... rw)  |
|  [ Seção .initrd ] Microcódigo + Initramfs concatenados               |
|  [ Seção .linux  ] Imagem do Kernel Linux (vmlinuz EFISTUB)           |
+-----------------------------------------------------------------------+

O binário final .efi resultante da unificação (gerado por ferramentas como ukify ou dracut --uefi) é assinado digitalmente por uma chave privada de Secure Boot.

Quando o systemd-boot detecta um arquivo UKI localizado no diretório /EFI/Linux/ dentro da ESP (ex: /boot/EFI/Linux/arch-linux-6.12.efi), ele cria automaticamente uma opção no menu de boot **sem precisar de nenhum arquivo .conf em /loader/entries/**.

Como o initramfs e os parâmetros de linha de comando estão selados dentro da assinatura digital da imagem .efi, o firmware UEFI valida o binário completo via Secure Boot antes da execução, impedindo qualquer injeção de malware em tempo de inicialização (rootkits / bootkits).

7. Análise Comparativa de Desempenho e Recursos