Uma jornada pelos segredos do firmware: do BIOS/UEFI ao sistema operacional

Você já se perguntou o que acontece no momento em que você aperta o botão de energia do seu computador? Por trás dessa breve pausa, antes que sua tela acenda, uma série complexa de processos está ocorrendo. Este artigo vai mergulhar no fascinante , explorando como . mundo do firmware diferentes componentes interagem durante o processo de inicialização Ao entender essas conexões, você terá uma imagem mais clara dos elementos fundamentais que dão vida ao seu sistema. Nosso foco principal será a , mas muitos princípios se aplicam a outras arquiteturas também. arquitetura Intel x86 Se você perdeu a primeira parte da nossa série, para recuperar o atraso. clique aqui Agora, vamos desvendar os mistérios por trás do firmware. Índice: Definições Arquitetura geral do firmware Carregador de inicialização de primeiro estágio (FSBL) BIOS (fase POST) Inicialização da plataforma UEFI (PI) inicialização do núcleo Outras soluções Carregador de inicialização de segundo estágio (SSBL) BIOS UEFI Carregador de inicialização do sistema operacional Definições : um tipo especializado de software incorporado ao hardware, que fornece controle de baixo nível e permite que o hardware funcione corretamente e interaja com outros componentes do sistema. Firmware : um firmware legado (originalmente criado para o ) responsável pela inicialização do hardware após a inicialização da plataforma. Hoje em dia, é frequentemente vagamente chamado de conjunto completo de firmware. Basic Input/Output System (BIOS) IBM PC : um nome geral para firmware que é responsável por inicializar um computador. É usado como um conceito moderno no lugar do , frequentemente fornecendo uma com código bootstrap para inicializar o processador e o chipset, bem como interfaces para terceiros (por exemplo, desenvolvedores de placas-mãe) para executar inicialização específica da plataforma. Bootloader BIOS estrutura : Um software a ser executado quando o bootloader sai. Pode ser um bootloader de segundo estágio, sistema operacional, aplicativo BIOS/UEFI, etc. Geralmente cuida do fluxo de bootstrapping de acordo com o design do firmware. Payload O uso dos termos e pode ser confuso, pois seus significados dependem do contexto. No entanto, quando alguém menciona , ou , geralmente está se referindo . BIOS bootloader firmware BIOS bootloader ao conjunto completo de firmware em execução entre o sistema operacional e o hardware vs. : A foi a especificação original desenvolvida pela Intel. A é a sucessora da , criada pelo para padronizar e estender a especificação original. Na maioria dos casos, e são usados de forma intercambiável. EFI UEFI Extensible Firmware Interface (EFI) Unified Extensible Firmware Interface (UEFI) EFI UEFI Forum EFI UEFI Arquitetura geral do firmware Para entender como os componentes do firmware interagem, exploraremos toda a arquitetura com todas as suas partes conectadas. O fluxo de execução, mostrado no diagrama abaixo, começa a partir do , que faz parte do . A partir daí, ele progride por vários estágios de firmware: vetor de reinicialização First-Stage Bootloader O firmware ou BIOS geralmente pode ser dividido em duas partes principais, com uma interface tipicamente mínima entre elas: : responsável por inicializar os componentes de hardware do sistema. Inicialização de hardware : fornece as interfaces necessárias para o sistema operacional e o usuário. Interface para o sistema operacional e o usuário O design do firmware da plataforma pode ser , combinando inicialização de hardware e funcionalidade de boot, ou pode seguir um e em estágios. A escolha do design depende dos requisitos do sistema e pode ser preferível para certos dispositivos. monolítico fluxo de boot modular O diagrama a seguir ilustra como diferentes componentes de firmware interagem e podem ser usados juntos para dar suporte ao processo de inicialização (as setas indicam a sequência de execução): Se esses diagramas parecem complexos agora, não se preocupe. Revise-os novamente depois de ler este artigo, e eles ficarão mais claros. Carregador de inicialização de primeiro estágio (FSBL) Este pedaço de firmware é projetado para inicializar computadores e sistemas embarcados com : fazer apenas o que é absolutamente necessário e, em seguida, passar o controle para o para inicializar o sistema operacional. O não carrega sistemas operacionais de mídia de armazenamento diferente do . Como ele inicializa apenas o hardware subjacente e não manipula mídia de inicialização como discos rígidos, SSDs ou unidades flash USB, outro pedaço de software é necessário para realmente inicializar um . foco na inicialização mínima de hardware Second-Stage Bootloader FSBL chip flash sistema operacional : Principais responsabilidades da FSBL : Alternando do de 16 bits para de 32 bits ( : ou no no caso do BIOS). CPU Modo Real o Modo Protegido observação modo Virtual 8086 : Chamando para configurar para o Utilização de cache FSP-T Cache-As-RAM ambiente C. : Inicializar a porta de depuração configurada chamando métodos de inicialização específicos da placa. Porta de depuração : invocar para inicializar a memória principal do sistema e salvar informações cruciais da memória do sistema. Inicialização de memória o FSP-M : Configurando pinos de entrada/saída de uso geral (GPIO) para interface com dispositivos externos. GPIO : Executando a inicialização inicial da plataforma e usando para concluir a inicialização do chipset, CPU e controlador de E/S. Silício FSP-S : enumeração de dispositivos PCI e alocação de recursos, como endereços de memória e IRQs. Enumeração PCI : configuração de tabelas e , incluindo as informações de preparação (tabelas de coreboot, HOBs) necessárias para serem passadas para a carga útil. Preparação da carga útil SMBIOS ACPI : Carregamento e transferência de controle para a carga útil. Carregamento e transferência BIOS (fase POST) Nos primórdios da computação, o software de código aberto não era muito popular, e a maioria das implementações de BIOS eram proprietárias. Existem apenas algumas soluções abertas disponíveis fornecendo código-fonte BIOS POST, como e . Esses projetos foram projetados para funcionar em sistemas IBM 5150/5155/5160 e na maioria dos clones XT. Super PC/Turbo XT BIOS GLaBIOS No entanto, as implementações de BIOS de código aberto mais conhecidas, como e , não realizam inicialização de hardware porque não são destinadas a rodar em hardware puro. Mas são amplamente usadas como e rodam nativamente em ambientes virtuais como QEMU e Bochs. OpenBIOS SeaBIOS Second-Stage Bootloaders Em todo caso, há pouca chance de que você precise trabalhar diretamente com esses BIOSes iniciais ou se aprofundar profundamente em suas especificidades. Mas se você estiver interessado em explorar, os repositórios mencionados são um bom ponto de partida. No que diz respeito às tendências atuais de desenvolvimento, parece não haver desenvolvimento contínuo de soluções de BIOS proprietárias, e tais projetos se tornaram obsoletos diante de alternativas modernas. Inicialização da plataforma UEFI (PI) O processo de inicialização segue um fluxo em estágios, começando da esquerda e movendo-se para a direita na próxima figura. A linha do tempo do processo de inicialização da plataforma é dividida nas seguintes frases, conforme indicado pelas caixas amarelas: : A primeira fase após um , sua função principal é configurar a RAM temporária (CPU ou SRAM). Segurança (SEC) vetor de reinicialização Cache-As-RAM : Esta fase despacha drivers especializados chamados . Esses módulos lidam com inicialização de hardware essencial, como configuração da CPU e chipset e configuração . Inicialização Pré-EFI (PEI) Módulos de Inicialização Pré-EFI (PEIMs) da memória principal (DRAM) : Nesta fase, o restante da inicialização do sistema é executado. A fase DXE fornece e suporta vários protocolos e drivers necessários para a operação do sistema. Driver Execution Environment (DXE) serviços UEFI : esta fase implementa a política de inicialização da plataforma, determinando a sequência de inicialização e selecionando o dispositivo/carregador de inicialização apropriado. Seleção de dispositivo de inicialização (BDS) : Durante esta fase, o sistema executa aplicativos usando serviços UEFI para preparar o SO. Inclui a transição do ambiente UEFI para o sistema operacional, concluindo com a chamada . Transient System Load (TSL) ExitBootServices() : Nesta fase, o sistema operacional está totalmente operacional, gerenciando o sistema sob seu controle. Tempo de execução (RT) : Esta fase lida com cenários em que o hardware ou o SO trava/desliga/reinicializa. O firmware pode tentar ações de recuperação, no entanto, a especificação UEFI PI não define requisitos ou comportamentos específicos para esta fase. After Life (AL) Este processo e suas fases de execução são cobertos pela . No entanto, há também a (indicada pela linha azul em negrito na imagem), que não faz parte do documento anterior e é descrita na . Embora os nomes e o uso frequente de possam ser confusos, esses dois documentos têm focos diferentes: UEFI Platform Initialization (PI) Specification UEFI Interface UEFI Specification UEFI : concentra-se nas interfaces entre componentes de firmware de baixo nível e detalha como esses módulos interagem para inicializar a plataforma. Especificação UEFI PI : Define as interfaces para interação entre o Sistema Operacional (SO) e o firmware. Isso será discutido mais adiante no contexto do . Observe que a UEFI Specification depende da PI Specification. UEFI Spec Second-Stage Bootloader Essencialmente, ambas as especificações são sobre interfaces, mas em níveis diferentes. Para informações detalhadas, você pode acessar ambas as especificações no . site do UEFI Forum foi inicialmente projetado como uma solução de firmware unificada, não considerando a distinção entre bootloaders de primeiro e segundo estágios. No entanto, quando nos referimos ao como , ele inclui as fases , e . A razão pela qual dividimos o DXE em e stages é devido às suas diferentes funções no processo de inicialização. O UEFI PI UEFI First-Stage Bootloader SEC PEI early DXE early late Na fase , os drivers geralmente realizam a inicialização essencial da CPU/PCH/placa e também produzem , que ajudam a isolar a fase do DXE do hardware específico da plataforma. encapsulam os detalhes específicos da plataforma, permitindo que a fase opere independentemente das especificações do hardware. inicial do DXE Protocolos Arquitetônicos (APs) do DXE Os APs final do DXE Inicialização do núcleo Artigos detalhados sobre como o Coreboot funciona em breve. Siga minhas mídias sociais – eles serão publicados muito em breve! Outras soluções : bootloader puro de primeiro estágio que fornece apenas a inicialização dos componentes de hardware principais, seguido pelo carregamento do payload. No entanto, ele e não suporta AMD x86 ou outras arquiteturas. Intel Slim Bootloader (SBL) funciona apenas em plataformas Intel x86 : um bootloader de primeiro e segundo estágios. No entanto, o suporte para inicialização direta do x86 da plataforma (conhecido como modo bare) é limitado em comparação a outros firmwares. É mais popular em sistemas embarcados e dispositivos baseados em ARM. Como um bootloader de segundo estágio, o U-Boot implementa um mas se concentra em sistemas embarcados. Das U-Boot vetor de redefinição subconjunto do UEFI, Carregador de inicialização de segundo estágio (SSBL) Após a conclusão da configuração inicial do hardware, o entra em ação. Sua função principal é configurar uma , garantindo que o SO possa gerenciar recursos do sistema e interagir com componentes de hardware. segundo estágio interface de software entre o sistema operacional e o firmware da plataforma O visa o máximo possível, simplificando o desenvolvimento de SO e aplicativos ao lidar com a maioria das interfaces de nível de hardware. Essa abstração permite que os desenvolvedores se concentrem em funcionalidades de nível mais alto sem se preocupar com as diferenças de hardware subjacentes. SSBL esconder variações de hardware : Principais responsabilidades do SSBL : obtém informações específicas da plataforma do , incluindo mapeamento de memória, SMBIOS, tabelas ACPI, flash SPI, etc. Recuperação de informações da plataforma First-Stage Bootloader : inclui drivers para SMM, SPI, PCI, SCSI/ATA/IDE/DISK, USB, ACPI, interfaces de rede e assim por diante. Execute drivers independentes de plataforma : fornece um conjunto de serviços que facilitam a comunicação entre o sistema operacional e os componentes de hardware. Implementação de serviços (também conhecida como interface) : oferece um menu de configuração do sistema, permitindo que os usuários ajustem as configurações relacionadas à ordem de inicialização, preferências de hardware e outros parâmetros do sistema. Menu de configuração : Mecanismo para localizar e carregar a carga útil (provavelmente o sistema operacional) da mídia de inicialização disponível. Lógica de inicialização BIOS A interface no BIOS é conhecida como . Essas funções fornecem um conjunto de rotinas para acesso ao hardware, mas os detalhes específicos de como elas são executadas no hardware específico do sistema são ocultados do usuário. BIOS services/functions/interrupt calls No 16 bits, eles podem ser facilmente acessados invocando uma interrupção de software via instrução de linguagem assembly x86. No de 32 bits, quase todos os serviços do BIOS ficam indisponíveis devido à maneira diferente como os valores são manipulados. Modo Real de INT Modo Protegido de segmento Vamos tomar como exemplo ( ), que fornece serviços de leitura e gravação de disco rígido e disquete baseados em setor usando endereçamento , como um exemplo de como essa interface pode ser usada. Digamos que queremos ler 2 setores (1024 bytes) e carregá-los no endereço de memória , então o seguinte código poderia ser executado: o Disk Services INT 13h Cylinder-Head-Sector (CHS) 0x9020 mov $0x02, %ah # Set BIOS read sector routine mov $0x00, %ch # Select cylinder 0 mov $0x00, %dh # Select head 0 [has a base of 0] mov $0x02, %cl # Select sector 2 (next after the # boot sector) [has a base of 1] mov $0x02, %al # Read 2 sectors mov $0x00, %bx # Set BX general register to 0 mov %bx, %es # Set ES segment register to 0 mov $0x9020, %bx # Load sectors to ES:BX (0:0x9020) int $0x13 # Start reading from drive jmp $0x9020 # Jump to loaded code Se você estiver interessado em como esse serviço é escrito no SeaBios, dê uma olhada em . src/disk.c Fase de inicialização Inicia a busca por um (pode ser um disco rígido, CD-ROM, disquete, etc.) lendo o (setor zero) dos dispositivos. dispositivo inicializável primeiro setor de 512 bytes A sequência de bootstrap no BIOS carrega o primeiro válido que encontra na memória física do computador no endereço (dica: e referem-se ao mesmo endereço físico). Master Boot Record (MBR) físico 0x7C00 0x0000:0x7c00 0x7c0:0x0000 O BIOS transfere o controle para os do payload. Este , que é muito pequeno para conter todo o código do payload, serve ao propósito de carregar o restante do payload do . Neste ponto, o payload pode usar a interface exposta pelo BIOS. primeiros 512 bytes setor carregado dispositivo inicializável Vale ressaltar que nos primeiros dias. O BIOS é um - ele funciona da mesma forma que funcionava nos PCs IBM reais, na década de 1980. O resto dos fabricantes apenas e tornaram os BIOS compatíveis com IBM. Como resultado, não havia regulamentação para impedir que os fabricantes de BIOS inventassem novas funções do BIOS ou tivessem funcionalidades sobrepostas. as especificações do BIOS não existiam padrão de fato fizeram engenharia reversa Interface de Firmware Extensível Unificada (UEFI) Como mencionado antes, o UEFI em si é apenas uma especificação e tem muitas implementações. O mais amplamente usado é , uma de código aberto das especificações UEFI e PI. Embora o EDKII sozinho não seja suficiente para criar um firmware de inicialização totalmente funcional, ele fornece uma base sólida para a maioria das soluções comerciais. o TianoCore EDK II implementação de referência Para dar suporte a diferentes e fornecer uma interface UEFI, o projeto é usado. Ele depende da configuração inicial feita e das informações de plataforma fornecidas pelo firmware de inicialização para preparar o sistema para o ambiente UEFI. First-Stage Bootloaders UEFI Payload O UEFI Payload usa as fases e , que são projetadas para serem independentes de plataforma. Ele oferece um payload genérico que pode se adaptar a diferentes plataformas. Na maioria dos casos, ele não requer nenhuma personalização ou ajustes específicos de plataforma e pode ser usado como está, consumindo informações de plataforma do . DXE BDS First-Stage Bootloader : Variantes do UEFI Payload : requer uma biblioteca de análise para extrair informações de plataforma específicas da implementação necessárias. Se o bootloader atualizar sua API, o payload também deverá ser atualizado. Legacy UEFI Payload : segue a , usando ou como um formato de imagem comum. Em vez de analisá-los ele mesmo, ele espera receber os na entrada do payload. Universal UEFI Payload especificação Universal Scalable Firmware (USF) Executable and Linkable Format (ELF) Flat Image Tree (FIT) Hand Off Blocks (HOBs) Enquanto o funciona bem, a comunidade EDK2 está tentando mudar a indústria para o . A escolha entre os payloads depende dos seus componentes de firmware. Por exemplo, não é possível executar o no sem . Por outro lado, usar o com coreboot requer uma camada shim para traduzir em , um recurso disponível apenas no . Legacy UEFI Payload Universal UEFI Payload Legacy Payload com suporte a SMM Slim Bootloader meu patch Universal Payload tabelas coreboot HOBs fork do StarLabs EDK2 Interface Cada sistema compatível com UEFI fornece uma que é passada para cada código em execução no ambiente UEFI (drivers, aplicativos, carregadores de SO). Essa estrutura de dados permite que um executável UEFI acesse , como , e uma coleção de . System Table tabelas de configuração do sistema ACPI SMBIOS serviços UEFI A estrutura da tabela é descrita em : MdePkg/Include/Uefi/UefiSpec.h typedef struct { EFI_TABLE_HEADER Hdr; CHAR16 *FirmwareVendor; UINT32 FirmwareRevision; EFI_HANDLE ConsoleInHandle; EFI_SIMPLE_TEXT_INPUT_PROTOCOL *ConIn; EFI_HANDLE ConsoleOutHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *ConOut; EFI_HANDLE StandardErrorHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *StdErr; // // A pointer to the EFI Runtime Services Table. // EFI_RUNTIME_SERVICES *RuntimeServices; // // A pointer to the EFI Boot Services Table. // EFI_BOOT_SERVICES *BootServices; UINTN NumberOfTableEntries; EFI_CONFIGURATION_TABLE *ConfigurationTable; } EFI_SYSTEM_TABLE; Os serviços incluem os seguintes tipos: , e . Serviços de inicialização Serviços de tempo de execução Serviços fornecidos por protocolos O UEFI abstrai o acesso ao dispositivo configurando . Esses e são identificados por um que permite que outros módulos os localizem e os utilizem. Eles podem ser descobertos por meio de Boot Services. Protocolos UEFI protocolos são estruturas de dados que contêm ponteiros de função Globally Unique IDentifier (GUID) Um produz esses protocolos, e as funções reais (não ponteiros!) estão contidas no próprio driver. Esse mecanismo permite que diferentes componentes dentro do ambiente UEFI se comuniquem entre si e garante que o SO possa interagir com dispositivos antes de carregar seus próprios drivers. driver UEFI Embora alguns protocolos sejam predefinidos e descritos na especificação UEFI, os fornecedores de firmware também podem para estender a funcionalidade de uma plataforma. criar seus próprios protocolos personalizados Serviços de inicialização Fornece funções que podem ser usadas durante o tempo de inicialização. Esses serviços permanecem disponíveis até que a função seja chamada ( ). somente EFI_BOOT_SERVICES.ExitBootServices() MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c Ponteiros para todos os serviços de inicialização são armazenados na ( ): Tabela de Serviços de Inicialização MdePkg/Include/Uefi/UefiSpec.h typedef struct { EFI_TABLE_HEADER Hdr; ... EFI_GET_MEMORY_MAP GetMemoryMap; EFI_ALLOCATE_POOL AllocatePool; EFI_FREE_POOL FreePool; ... EFI_HANDLE_PROTOCOL HandleProtocol; ... EFI_EXIT_BOOT_SERVICES ExitBootServices; ... } EFI_BOOT_SERVICES; Serviços de tempo de execução Um conjunto mínimo de serviços ainda é acessível enquanto o Sistema Operacional está em execução. Diferentemente dos Serviços de Inicialização, esses serviços ainda são válidos após qualquer payload (por exemplo, bootloader do SO) ter assumido o controle da plataforma por meio de uma chamada para . EFI_BOOT_SERVICES.ExitBootServices() Ponteiros para todos os serviços de tempo de execução são armazenados na ( ): Tabela de Serviços de Tempo de Execução MdePkg/Include/Uefi/UefiSpec.h typedef struct { EFI_TABLE_HEADER Hdr; ... EFI_GET_TIME GetTime; EFI_SET_TIME SetTime; ... EFI_GET_VARIABLE GetVariable; EFI_GET_NEXT_VARIABLE_NAME GetNextVariableName; EFI_SET_VARIABLE SetVariable; ... EFI_GET_NEXT_HIGH_MONO_COUNT GetNextHighMonotonicCount; EFI_RESET_SYSTEM ResetSystem; ... } EFI_RUNTIME_SERVICES; A imagem abaixo mostra a linha do tempo dos serviços de inicialização e tempo de execução, para que você possa ver exatamente quando cada um está ativo. Fase de seleção de dispositivo de inicialização (BDS) A especificação UEFI define um mecanismo de política de inicialização chamado . Ele tentará carregar em uma ordem específica. Essa ordem e outras configurações podem ser configuradas modificando . Vamos discutir as mais importantes delas: gerenciador de inicialização UEFI aplicativos UEFI as variáveis globais NVRAM (nonvolatile random-access memory) ( é substituído por um valor hexadecimal exclusivo) — uma opção de inicialização/carregamento. Boot#### #### — a opção de inicialização usada para iniciar o sistema em execução no momento. BootCurrent — a opção de inicialização somente para a próxima inicialização. Isso substitui somente para uma inicialização e é excluído pelo gerenciador de inicialização após o primeiro uso. Isso permite que você altere o comportamento da próxima inicialização sem alterar . BootNext BootOrder BootOrder — a lista de carregamento de opções de inicialização ordenada. O gerenciador de inicialização tenta inicializar a primeira opção ativa nesta lista. Se não for bem-sucedido, ele tenta a próxima opção, e assim por diante. BootOrder — os tipos de opções de inicialização suportadas pelo gerenciador de inicialização. BootOptionSupport — o tempo limite dos gerenciadores de inicialização do firmware, em segundos, antes de escolher automaticamente o valor de inicialização entre ou . Timeout BootNext BootOrder Essas variáveis podem ser facilmente obtidas do Linux usando : efibootmgr(8) [root@localhost ~]# efibootmgr BootCurrent: 0000 Timeout: 5 seconds BootOrder: 0000,0001,2001,2002,2003 Boot0000* ARCHLINUX HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000)/File(\EFI\ARCHLINUX\grubx64.efi) Boot0001* Windows Boot Manager HD(1,GPT,6f185443-09fc-4f15-afdf-01c523565e52,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)57a94e544f5753000100000088900100780000004200430044039f0a42004a004500430054003d007b00390064006500610038003600320063002d1139006300640064002d0034006500370030102d0061006300630031002d006600330032006200330034003400640034003700390035007d00000033000300000710000000040000007fff0400 Boot0002* ARCHLINUX HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000) Boot2001* EFI USB Device RC Boot2002* EFI DVD/CDROM RC Boot2003* EFI Network RC Vamos dar uma olhada na inicialização confiando no trecho de código acima. O UEFI começará a iterar a lista . Para cada entrada na lista, ele procura uma variável correspondente — para 0000, para 2003 e assim por diante. Se a variável não existir, ele continua para a próxima entrada. Se a variável existir, ele lê o conteúdo da variável. Cada variável de opção de inicialização contém um descritor que é um buffer compactado em bytes de campos de comprimento variável (é apenas a estrutura de dados). BootOrder Boot#### Boot0000 Boot2003 EFI_LOAD_OPTION A estrutura de dados é descrita em [MdePkg/Include/Uefi/UefiSpec.h][ ) https://github.com/tianocore/edk2/blob/edk2-stable202405/MdePkg/Include/Uefi/UefiSpec.h#L2122 typedef struct _EFI_LOAD_OPTION { /// The attributes for this load option entry. UINT32 Attributes; /// Length in bytes of the FilePathList. UINT16 FilePathListLength; /// The user readable description for the load option. /// Example: 'ARCHLINUX' / 'Windows Boot Manager' / `EFI USB Device` // CHAR16 Description[]; /// A packed array of UEFI device paths. /// Example: 'HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000)/File(\EFI\ARCHLINUX\grubx64.efi)' // EFI_DEVICE_PATH_PROTOCOL FilePathList[]; /// The remaining bytes in the load option descriptor are a binary data buffer that is passed to the loaded image. /// Example: '57a9...0400' in Boot0001 variable // UINT8 OptionalData[]; } EFI_LOAD_OPTION; Neste ponto, o firmware examinará um ( ). Na maioria dos casos, nosso computador é inicializado a partir de um dispositivo de armazenamento (Hard Drive/SSD/NVMe/etc). Então, o conteria . Device Path EFI_DEVICE_PATH_PROTOCOL Device path HD(Partition Number, Type, Signature, Start sector, Size in sectors) — indica o formato usado para o esquema de particionamento com as palavras-chave (1) ou (2). Tipo MBR GPT — uma assinatura MBR de 4 bytes se o Tipo for , ou um de 16 bytes se o Tipo for . Assinatura MBR UUID GPT : se você estiver interessado em como traduzir outros caminhos, leia . Observação a Referência de nó de dispositivo de texto da especificação UEFI v2.10, 10.6.1.6 O UEFI examinará o disco e verá se ele tem uma partição que corresponde ao nó. Se existir, ele deve ser rotulado com um específico que o marca como . Este é formatado com um sistema de arquivos cuja especificação é baseada na versão específica do e é chamado ; na verdade, é apenas um regular . Globally Unique IDentifier (GUID) EFI System Partition (ESP) sistema de arquivos FAT EFI File System FAT12/16/32 : se o contiver um caminho explícito para o arquivo , então o UEFI procurará por esse arquivo específico. Por exemplo, a opção contém . Inicialização nativa Device Path File(\Path\To\The\File.efi) Boot0000 File(\EFI\ARCHLINUX\grubx64.efi) : se o simplesmente apontar para um disco, então, em tais situações, o firmware usará um que é baseado na arquitetura — ( para ou para / ). Este mecanismo permite que a (por exemplo, uma unidade USB) funcione em UEFI; eles apenas usam um . Por exemplo, a opção usará este mecanismo. Inicialização de fallback Device Path caminho de inicialização de fallback \EFI\BOOT\BOOT{arch}.EFI BOOTx64.EFI amd64 BOOTia32.EFI i386 IA32 mídia removível inicializável caminho de inicialização de fallback Boot0002 Todas as opções mencionadas acima referem-se às opções de inicialização exibidas na saída de exemplo do . Nota: Boot#### efibootmgr Em ambos os casos, o carregará o (pode ser , o UEFI Shell, o software utilitário, a configuração do sistema e o que for) na memória. Neste momento, o controle é então transferido para o ponto de entrada do . Ao contrário , o pode retornar o controle para o firmware (além da situação em que o aplicativo assume o controle do sistema). Se isso acontecer ou algo der errado, o passa para a próxima entrada e segue exatamente o mesmo processo. UEFI Boot Manager aplicativo UEFI o bootloader do SO aplicativo UEFI do BIOS aplicativo UEFI Boot Manager Boot#### A especificação menciona que o pode manter automaticamente as variáveis do banco de dados. Isso inclui remover variáveis de opção de carregamento que não são referenciadas ou não podem ser analisadas. Além disso, ele pode reescrever qualquer lista ordenada para remover quaisquer opções de carregamento sem variáveis de opção de carregamento correspondentes. gerenciador de boot O texto acima descreve a . Além disso, o firmware UEFI pode ser executado no modo que emula um BIOS. inicialização UEFI Compatibility Support Module (CSM) Carregador de inicialização do sistema operacional Um pedaço de software iniciado pelo firmware (geralmente ) e usando sua interface para . Pode ser tão complexo quanto um SO, oferecendo recursos como: Second-Stage Bootloader carregar o kernel do SO Leitura de vários sistemas de arquivos (HFS+, ext4, XFS, etc) Interagindo em uma rede (por exemplo, TFTP, HTTP) Inicializando kernels compatíveis com Multiboot Carregamento em cadeia Carregando ramdisks iniciais ( ) initrd E muito mais! Os designs comuns desses programas estão além do escopo deste artigo. Para uma comparação detalhada de bootloaders de SO populares, você pode consultar o e o . wiki do ArchLinux artigo da Wikipedia O sistema Windows usa seu bootloader proprietário conhecido como . Windows Boot Manager (BOOTMGR) Firmware não é mais um pedaço de código. Ele se tornou uma , e as tendências atuais só contribuem para isso. Podemos rodar , e muitos outros aplicativos interessantes nele. pequeno e complexo enorme quantidade de código complexo Doom Twitter Entender a arquitetura geral ajuda a organizar esses componentes em sua mente. Ao examinar o design do firmware existente, você ganha insights sobre o fascinante processo que se desenrola cada vez que um computador é ligado. Essa perspectiva de cima para baixo não apenas esclarece o papel de cada parte, mas também destaca a natureza sofisticada e evolutiva dos sistemas de firmware modernos. Recursos Especificação UEFI versão 2.10 Especificação de inicialização da plataforma UEFI versão 1.8 (Errata A) Documentação do EDK II Documentação do Projeto Slim Bootloader Inicialização UEFI: como isso realmente funciona? Compreendendo a inicialização de plataforma moderna baseada em UEFI Anatomia da sequência de inicialização UEFI no Intel Galileo Uma observação muito simples sobre "caminhos" de dispositivos de disco em algumas arquiteturas comuns. Como os computadores inicializam