Como o servidor inicia: UEFI



Anteriormente, já analisamos a sequência de inicialização do servidor usando o Legacy legado como exemplo. Agora é a hora de conhecer melhor a UEFI.



A primeira versão do que hoje é conhecido como Unified Extensive Firmware Interface (UEFI) foi desenvolvida na década de 90 do último milênio especificamente para sistemas Intel® Itanium® e foi chamada de Intel Boot Initiative e posteriormente - EFI.



O desejo de "atualizar" o processo de inicialização era esperado. PC-BIOS , agora chamado de Legacy, oferece para trabalhar em modo real de 16 bits, endereça apenas 1 MB de RAM, e o bootloader junto com a tabela de partição deve estar localizado nos primeiros 512 bytes do drive. Além disso, o PC-BIOS transfere o controle para o primeiro bootloader encontrado, sem a possibilidade de retornar. Neste caso, o tratamento de casos com vários sistemas operacionais é colocado sobre os ombros do bootloader.



A limitação do tamanho do bootloader dita o uso da marcação Master Boot Record (MBR), que apareceu em 1983. O MBR não é padronizado, mas muitos fornecedores são "tradicionais". O MBR tem sérias limitações: apenas 4 partições são suportadas por padrão e a capacidade de armazenamento não é superior a 2,2 TB.



Em dezembro de 2000, a primeira especificação EFI difundida foi lançada sob a versão 1.02. Cinco anos depois, a Intel transferiu a EFI para o UEFI Forum, adicionando Unified ao título para destacar a mudança. A especificação UEFI está disponível publicamente e consiste em vários documentos:



  • Especificação ACPI;
  • Especificação UEFI;
  • Especificação UEFI Shell;
  • Especificação de inicialização da plataforma UEFI;
  • Especificação de empacotamento de distribuição de inicialização de plataforma UEFI.


A diversão começa na UEFI Platform Initialization Specification , que descreve todas as fases de carregamento da plataforma.



A UEFI é universal, mas neste artigo vamos nos basear no padrão, visando processadores na arquitetura x86_64.



Acorde, Neo!



Sequência de fase de inicialização UEFI (fonte UEFI Platform Initialization Specification )

Após a inicialização da plataforma, a fonte de alimentação espera até que os transientes sejam concluídos e, em seguida, define o sinal para a linha Power_Good . E o primeiro a começar a operar não é o processador central, mas o subsistema autônomo Intel® Management Engine (ME) ou AMD Secure Technology (ST) semelhante a ele. Esse subsistema executa suas próprias operações e, em seguida, prepara e inicia o primeiro núcleo de um único processador, denominado Bootstrap Processor (BSP) .

De acordo com a terminologia aceita, o thread de núcleo / processador será doravante referido como o processador de bootstrap ou processador de aplicativo.
Como no Legacy, o processador começa a executar a primeira instrução no final do espaço de endereço em 0xFFFFFFF0 . Esta instrução é um salto para a primeira fase de inicialização da plataforma - SEC.



Fase SEC (segurança)



Nesta fase, as seguintes tarefas devem ser resolvidas:



  • manipulando o evento enable;
  • inicializar memória suficiente para a próxima fase;
  • estabelecer a raiz de confiança no sistema;
  • transferência das informações e controle necessários para a próxima fase.


Os processadores X86_64 iniciam no modo real de 16 bits e, durante a inicialização, o BSP é colocado no modo protegido de 32 bits . Em seguida, o microcódigo de todos os processadores disponíveis é atualizado.



Em seguida, é o processamento do evento de ativação. Isto significa agregar informações sobre o estado do equipamento para que na próxima fase alguns módulos possam tirar conclusões sobre o "estado" e o estado geral da plataforma.



Durante a fase SEC, nenhuma inicialização de RAM ocorre. Em vez disso, o cache do processador livre é marcado como não lavável e é convertido em RAM temporária. Este modo é chamado de modo sem despejo (NEM)... Uma pilha é criada na memória alocada, o que permitirá que os módulos das próximas fases usem as linguagens de programação da pilha antes de inicializar a RAM principal.



Além disso, todos os processadores de aplicativos (Application Processors, AP) são inicializados com uma sequência especial de interrupções entre processadores (Inter-Processor Interrupt, IPI) enviada a eles. A sequência Init IPI - Start-up IPI - ativa o processador do aplicativo e inicia o autoteste integrado (BIST) nele . Os resultados dos testes são registrados e repassados ​​para análise.



No final da fase de segurança, você precisa encontrar a seção Boot Firmware Volume (BFV), na qual está localizado o código executável da próxima fase, bem como, se possível, encontre outras seções menores com o código (Firmware Volume, FV).



Para justificar o nome da fase de Segurança e se tornar uma raiz de confiança, durante a execução desta fase, o código para o qual planejamos transferir o controle pode ser verificado quanto a alterações não autorizadas e partes maliciosas do programa.



No final da execução da SEC, as seguintes informações são coletadas:



  • tamanho e endereço do Boot Firmware Volume (BFV);
  • o tamanho e os endereços de outros Volumes de Firmware (FV);
  • tamanho e endereço da RAM temporária;
  • o tamanho e o endereço da pilha.


Em seguida, o próximo estágio começa - Pré-inicialização EFI.



Fase PEI (Pré-inicialização EFI)



A fase PEI em uma placa-mãe SuperMicro

O objetivo da fase de pré-inicialização EFI é coletar informações sobre os dispositivos conectados e preparar a quantidade mínima necessária de hardware para executar o processo de inicialização completo.



Por design, a fase PEI deve ser leve, uma vez que a memória cache do processador é limitada. Além disso, a fase PEI pode se recuperar de uma falha, portanto, é necessário colocar o código da fase PEI em um armazenamento mais resiliente.



Esta fase consiste em um kernel denominado PEI Foundation e os plug-ins PEI Module (PEIM) . A parte central do kernel é o gerenciador de módulo, PEI Dispatcher, que controla a ordem de execução dos módulos e também organiza a interação entre os módulos (Interface PEIM-para-PEIM, PPI).



Observe que a fase SEC foi executada a partir da memória flash da placa-mãe, e somente no início do PEI o código executável necessário para esta fase é copiado para a RAM temporária.



Em seguida, vem o PEI Dispatcher. Ele inicia os módulos PEI em uma ordem específica: primeiro, módulos sem dependências, depois dependentes do primeiro e assim por diante até que os módulos acabem.



A arquitetura da fase PEI permite que você desenvolva seus próprios módulos que podem transferir os resultados de suas atividades para a próxima fase. A transferência de informações ocorre por meio de uma estrutura de dados de Bloco de transferência especial (HOB) .



No processo de inicialização dos módulos PEI, observe o seguinte:



  • CPU PEIM - inicialização do processador;
  • Plataforma PEIM - inicialização das pontes Norte (incluindo Memory Controller Hub) e Sul (I / O Controller Hub);
  • Inicialização de memória PEIM - inicialização da RAM principal e transferência de dados da memória temporária para a RAM.


Anteriormente, a inclusão era recebida da fase da SEC. Se o evento de inicialização for S3 Resume , o S3 BootScript será executado em seguida , o que restaura o estado salvo dos processadores e de todos os dispositivos conectados e, em seguida, transfere o controle diretamente para o SO.

O estado S3 (Suspender para RAM) é um estado de hibernação no qual o processador e parte do chipset são desligados com perda de contexto. Ao despertar desse estado, o processador começa a executar como se fosse uma inicialização normal. Mas, em vez de uma inicialização completa e passar em todos os testes, o sistema se limita a restaurar o estado de todos os dispositivos.
Quando iniciado a partir de qualquer outro estado, o controle é transferido para a fase Driver Execution Environment.



Fase DXE (Driver eXecution Environment)





Fase DXE Inicialização AHCI A fase Driver Execution Environment (DXE) concentra - se na inicialização dos dispositivos restantes. No momento em que a fase DXE começa, o processador e a memória principal estão prontos para funcionar e os drivers DXE não estão sujeitos a limites estritos de recursos.



Semelhante à Fundação PEI, esta fase tem seu próprio núcleo - a Fundação DXE . O kernel cria as interfaces necessárias e carrega três tipos de serviços DXE:



  • UEFI Boot Services - serviços de tempo de inicialização;
  • UEFI Runtime Services - serviços de tempo de execução ;
  • Os serviços DXE são serviços especiais exigidos pelo núcleo DXE.


Depois que os serviços são inicializados, o DXE Dispatcher começa a funcionar . Ele encontra e carrega os drivers DXE, que, por sua vez, completam a inicialização do hardware.

Na UEFI, não há fase dedicada onde o hardware passa no POST (Power-On Self-Test). Em vez disso, cada módulo de fase PEI e DXE conduz seu próprio conjunto de testes e comunica isso por meio de códigos POST ao usuário e por meio de HOBs nas fases seguintes.
Entre os muitos drivers carregados em processadores x86_64, vale a pena prestar atenção ao driver System Management Mode Init (SMM Init). Este driver prepara tudo para o modo de gerenciamento do sistema (SMM) funcionar . SMM é um modo privilegiado especial que permite suspender a execução do código atual (incluindo o sistema operacional) e executar o programa a partir da área protegida de SMRAM em seu próprio contexto.

SMM não é oficialmente considerado o anel de proteção -2. O kernel do sistema operacional roda no anel 0, e os anéis de proteção mais restritos são numerados de 1 a 3. Oficialmente, o anel zero é considerado o mais privilegiado. No entanto, um hipervisor virtualizado por hardware é convencionalmente chamado de anel -1, e Intel ME e AMD ST são chamados de anel -3.
Além disso, observamos o Compatibility Support Module (CSM) , que garante compatibilidade com o Legacy e permite que você inicialize o sistema operacional sem suporte UEFI. Veremos este módulo com mais detalhes posteriormente.



Após inicializar todos os equipamentos, é hora de selecionar um dispositivo de boot.



Fase BDS (Boot Device Select)



A fase Boot Device Select implementa a política de inicialização do aplicativo UEFI. Embora esta seja uma fase separada, todos os serviços, incluindo o despachante, criados durante a fase DXE permanecem disponíveis.



O objetivo da fase BDS é realizar as seguintes tarefas:



  • inicialização de dispositivos de console;
  • procure dispositivos a partir dos quais você possa inicializar;
  • uma tentativa de inicializar a partir de dispositivos encontrados em ordem de prioridade.


BIOS PCIe da

placa adicional LSI O Gerenciador de inicialização procura áreas inicializáveis ​​nos dispositivos. Algumas placas de expansão, como placas de rede e controladores RAID, podem ter seu próprio "BIOS", denominado Option ROM ou OpROM . O conteúdo dos dispositivos OpROM é iniciado imediatamente após a detecção e, após a execução, o controle retorna ao Boot Manager.



Todas as partições contendo áreas de download são armazenadas na memória do gerenciador de inicialização e são ordenadas de acordo com a ordem de inicialização. Se nenhum aplicativo for encontrado, o Boot Manager pode chamar o gerenciador DXE, caso o gerenciador tenha carregado drivers adicionais durante a pesquisa e novos dispositivos possam "abrir" no gerenciador de boot.



Conforme observado anteriormente, o uso da marcação Master Boot Record impõe restrições sobre o tamanho das partições e seu número na unidade, além de causar alguns inconvenientes na manutenção de vários sistemas operacionais. A solução para todos esses problemas faz parte da especificação UEFI - GUID Partition Table.



GPT (tabela de partição GUID)



Tabela de partição GUID é um formato de tabela de partição padronizado que substitui o MBR herdado.



Primeiro, o GPT usa endereçamento de bloco lógico (LBA) em vez de endereçamento de cilindro, cabeça, setor (CHS). Alterar o método de endereçamento permite que o GPT funcione com unidades de até 9,4 ZB (9,4 * 10 21 bytes) versus 2,2 TB para MBR.



Em segundo lugar, a tabela de partição sofreu alterações e agora você pode criar até 2 64 partições em uma única unidade , embora os sistemas operacionais suportem não mais que 128 no caso do Microsoft Windows e 256 no caso do Linux.



Em terceiro lugar, cada seção tem seu próprio identificador de tipo, que descreve a finalidade da seção. Portanto, por exemplo, o identificador C12A7328-F81F-11D2-BA4B-00A0C93EC93B aponta exclusivamente para a partição do sistema EFI (ESP) a partir da qual o gerenciador de inicialização pode tentar carregar o aplicativo.



Durante o desenvolvimento do GPT, a compatibilidade com o MBR não foi poupada. Os utilitários de disco podem não reconhecer o disco GPT e apagá-lo. Para evitar isso, durante o particionamento GPT, os primeiros 512 bytes são preenchidos com MBR de proteção (MBR de proteção) - uma partição de uma partição para toda a unidade com o identificador de sistema 0xEE. Esta abordagem permite que a UEFI entenda que não é um MBR real à sua frente, mas um software antigo sem suporte de GPT - para ver uma partição com dados de um tipo desconhecido.



O GPT trocou a área de inicialização em favor de partições ESP, que são reconhecidas como inicializáveis. O Boot Manager coleta informações sobre todos os ESPs no disco, o que permite que você tenha vários bootloaders na unidade sem conflitos, um para cada ESP.



Carregando o sistema operacional



Após pesquisar todos os dispositivos e procurar áreas de inicialização, o Boot Manager começa a inicializar na ordem de prioridade de inicialização. Em geral, o controle é transferido para o aplicativo UEFI, que inicia a execução de sua lógica. Porém, para sistemas com compatibilidade de modo Legacy, pode haver um MBR na lista da área de boot e você terá que ir para o CSM, o módulo de suporte de compatibilidade.



O CSM permite que você execute sistemas operacionais que não suportam UEFI. Para carregar esses sistemas operacionais, o módulo CSM emula o ambiente no qual o sistema operacional "clássico" se enquadra:



  • carrega o driver Legacy;
  • carrega o BIOS legado;
  • coloca a saída de vídeo no modo compatível com Legacy;
  • Cria estruturas de dados necessárias para Legacy na memória que não estão disponíveis na UEFI;
  • carrega o driver CompatibilitySmm para SMM para funcionar no Legacy.


Lembre-se de que no modo Legacy, o SO é inicializado no modo de 16 bits, enquanto no UEFI tudo funciona no modo de 32 bits. CSM inicia o carregador de inicialização Legacy no modo de 16 bits e fornece comunicação com drivers UEFI de 32 bits conforme necessário.



Fase RT (tempo de execução)



O início da inicialização do sistema operacional ou do carregador de inicialização Legacy leva ao início da fase de tempo de execução. Nesta fase, todos os serviços DXE (exceto UEFI Runtime Services) não estão mais disponíveis.



O conteúdo da fase RT pode variar. Pode haver um carregador de SO familiar do Legacy - por exemplo, GRUB2 ou Windows Boot Manager, que coloca o processador no modo de 64 bits e inicia o SO. Mas pode haver aplicativos independentes ou apenas o kernel do sistema operacional.



O kernel Linux a partir da versão 3.3, se o sinalizador CONFIG_EFI_STUB estiver presente, se transforma em um aplicativo UEFI regular e pode ser iniciado a partir do UEFI sem usar carregadores de inicialização de terceiros.



Como no caso do Legacy, o bootloader ou o próprio kernel precisa colocar o processador no modo 64 bits, carregar todos os drivers, configurar o agendador e executar o init. O Init, por sua vez, inicia processos no espaço do usuário, após o qual a janela de login do SO aparece.



Conclusão



A inicialização na UEFI é um processo mais complexo, mas padronizado e amplamente universal. As semelhanças com o Legacy são observadas apenas em termos gerais, e o diabo, como você sabe, está nos detalhes.



Em quanto tempo você acha que será possível sair completamente do Legacy?

Escreva sua opinião nos comentários.



All Articles