Boot via Rede (PXE)

PXE (Preboot eXecution Environment) é uma alternativa baseada em rede a carregar um bootloader de disco. O PCI já menciona a ROM de expansão de uma placa de rede como o lugar onde o código de boot PXE vive; este artigo cobre como esse código de fato coloca um bootloader rodando pela rede antes de qualquer disco sequer ser tocado.

O firmware roda o próprio código de ROM da NIC

Durante sua própria enumeração de dispositivo de boot, o firmware descobre uma placa de rede expondo uma ROM de expansão capaz de PXE da mesma forma que descobre qualquer dispositivo inicializável, e, se o boot PXE for selecionado (pela ordem de boot, escolha do usuário, ou falta de qualquer outro dispositivo inicializável), o firmware carrega e executa o próprio código dessa ROM diretamente, antes de sequer tocar num controlador de disco. Isso é o que torna PXE fundamentalmente diferente de todo outro caminho de boot que esta wiki cobre: o código que de fato implementa os protocolos de rede abaixo roda a partir da própria imagem de firmware da NIC, não de qualquer coisa que o kernel ou um instalador de SO forneça, e o papel do firmware se limita a localizar e rodar esse código de ROM, não implementar o PXE em si.

DHCP, estendido para boot

O primeiro trabalho da ROM PXE é DHCP padrão, requisitando um endereço IP da mesma forma que qualquer cliente DHCP numa rede comum faria, mas com opções específicas de PXE incluídas na requisição: o cliente se identifica como capaz de PXE, e um servidor DHCP corretamente configurado (ou um servidor PXE proxy DHCP complementar rodando ao lado de um servidor DHCP comum e de outra forma não modificado) responde com a configuração de IP usual mais duas informações adicionais, o endereço de um servidor TFTP e o nome de arquivo do bootloader a requisitar dele.

DHCPDISCOVER (cliente, opções PXE definidas)
    -> DHCPOFFER (servidor): endereço IP, subnet, gateway,
                              next-server = 10.0.0.5,
                              filename = "pxelinux.0"

Algumas redes dividem isso entre duas trocas DHCP distintas em vez de uma, um servidor DHCP comum fornecendo configuração de endereço e um servidor proxyDHCP separado fornecendo só os campos específicos de PXE, especificamente para que uma infraestrutura DHCP existente sem consciência alguma de PXE possa ser pareada com suporte a boot PXE adicionado à parte, sem reconfigurar o próprio serviço DHCP primário.

TFTP: a transferência real

Com o endereço do servidor de boot e o nome de arquivo do bootloader em mãos, a ROM PXE requisita esse arquivo via TFTP (Trivial File Transfer Protocol), um protocolo deliberadamente mínimo construído sobre UDP, trocando o bootloader em blocos pequenos e individualmente reconhecidos (512 bytes cada na especificação original) em vez de qualquer coisa parecida com um protocolo de transferência de arquivo completo.

RRQ "pxelinux.0" octet          (cliente -> servidor, porta 69)
DATA bloco 1 (512 bytes)        (servidor -> cliente)
ACK bloco 1                     (cliente -> servidor)
DATA bloco 2 (512 bytes)
ACK bloco 2
...
DATA bloco N (< 512 bytes)      -- sinaliza fim da transferência
ACK bloco N

A simplicidade do TFTP é deliberada, não uma limitação que vale a pena contornar: precisa ser implementável inteiramente dentro da ROM de expansão restrita de uma NIC, sem sistema de arquivos, sem estado de conexão além do número do bloco atual, e sem autenticação, trocando todo recurso que um protocolo de transferência de propósito geral poderia oferecer por uma implementação pequena e simples o suficiente para caber onde o PXE de fato precisa rodar.

Depois da transferência, o boot prossegue normalmente

Uma vez que o TFTP copiou o bootloader para a memória, a ROM PXE transfere controle a ele exatamente da forma que o processo de boot já descreve controle passando para um bootloader carregado de disco: mesmo estado de CPU, mesmas expectativas sobre o que esse código faz em seguida. A partir desse ponto, nada do resto do boot é específico de PXE: o bootloader baixado pode ele mesmo usar TFTP para buscar uma imagem de kernel e arquivos adicionais (um padrão comum para boot em rede de um instalador Linux completo, por exemplo) ou simplesmente prosseguir exatamente como teria prosseguido se tivesse sido carregado de um disco local desde o início.

Notas de implementação

Um ambiente capaz de PXE para desenvolvimento de kernel é direto de configurar sob o QEMU sem hardware de rede real algum: -netdev combinado com um diretório raiz TFTP e uma opção de nome de arquivo de boot permite que a própria pilha de rede virtual do QEMU sirva DHCP e TFTP diretamente, permitindo a um desenvolvedor testar um caminho de boot em rede sem configurar servidores DHCP e TFTP físicos separados. Como o espaço de código da ROM PXE é limitado, e como ela não tem consciência alguma de sistema de arquivos ou tabela de partição, o arquivo que ela busca é quase sempre um estágio de bootloader pequeno e dedicado (pxelinux.0, ou equivalente) em vez de um kernel completo diretamente, espelhando o mesmo padrão de carregamento em estágios que Bootloaders já cobre para boot baseado em disco.

Referências

^ Intel e Systemsoft, Preboot Execution Environment (PXE) Specification: a especificação formal que define as extensões de DHCP e o fluxo de boot baseado em TFTP descritos acima.

Ver também

PCI: a ROM de expansão onde o código de boot PXE de uma NIC de fato vive.
The Boot Process: uma vez que o bootloader baixado assume o controle, o resto do boot prossegue exatamente como um baseado em disco.