Un viaje a través de los secretos del firmware: desde la BIOS/UEFI hasta el sistema operativo

¿Alguna vez te has preguntado qué sucede en el momento en que presionas el botón de encendido de tu computadora? Detrás de esa breve pausa, antes de que se encienda tu pantalla, se están llevando a cabo una serie compleja de procesos. Este artículo se sumergirá en el fascinante , explorando cómo . mundo del firmware interactúan los diferentes componentes durante el proceso de arranque Al comprender estas conexiones, obtendrá una imagen más clara de los elementos fundamentales que dan vida a su sistema. Nos centraremos principalmente en la , pero muchos principios también se aplican a otras arquitecturas. arquitectura Intel x86 Si te perdiste la primera parte de nuestra serie, para ponerte al día. haz clic aquí Ahora, descubramos los misterios detrás del firmware. Tabla de contenido: Definiciones Arquitectura general del firmware Cargador de arranque de primera etapa (FSBL) BIOS (fase POST) Inicialización de la plataforma UEFI (PI) arranque del núcleo Otras soluciones Cargador de arranque de segunda etapa (SSBL) BIOS UEFI Cargador de arranque del sistema operativo Definiciones : un tipo especializado de software integrado en el hardware, que proporciona control de bajo nivel y permite que el hardware funcione correctamente e interactúe con otros componentes del sistema. Firmware : firmware heredado (creado originalmente para ) responsable de la inicialización del hardware después de encender la plataforma. En la actualidad, se lo suele denominar vagamente como el conjunto completo de firmware. Sistema básico de entrada y salida (BIOS) IBM PC : nombre general para el firmware que se encarga de arrancar una computadora. Se utiliza como un concepto moderno en lugar de y suele proporcionar un con código de arranque para inicializar el procesador y el chipset, así como interfaces para que terceros (por ejemplo, desarrolladores de placas base) realicen una inicialización específica de la plataforma. Cargador de arranque BIOS marco : software que se ejecuta cuando finaliza el gestor de arranque. Puede ser un gestor de arranque de segunda etapa, un sistema operativo, una aplicación BIOS/UEFI, etc. Normalmente se encarga del flujo de arranque según el diseño del firmware. Carga útil El uso de los términos y puede ser confuso, ya que sus significados dependen del contexto. Sin embargo, cuando alguien menciona , o , generalmente se refiere . BIOS bootloader firmware BIOS bootloader al conjunto completo de firmware que se ejecuta entre el sistema operativo y el hardware vs. : La fue la especificación original desarrollada por Intel. La es la sucesora de , creada por el para estandarizar y ampliar la especificación original. En la mayoría de los casos, y se utilizan indistintamente. EFI UEFI interfaz de firmware extensible (EFI) interfaz de firmware extensible unificada (UEFI) EFI foro UEFI EFI UEFI Arquitectura general del firmware Para entender cómo interactúan los componentes del firmware, exploraremos toda la arquitectura con todas sus partes conectadas. El flujo de ejecución, que se muestra en el diagrama a continuación, comienza desde el , que forma parte del . A partir de allí, avanza a través de varias etapas del firmware: vector de reinicio cargador de arranque de primera etapa El firmware o BIOS generalmente se puede dividir en dos partes principales, con una interfaz típicamente mínima entre ellas: : Responsable de inicializar los componentes de hardware del sistema. Inicialización de hardware : proporciona las interfaces necesarias para el sistema operativo y el usuario. Interfaz con el sistema operativo y el usuario El diseño del firmware de la plataforma puede ser , combinando la inicialización del hardware y la funcionalidad de arranque, o puede seguir un y por etapas. La elección del diseño depende de los requisitos del sistema y puede ser preferible para determinados dispositivos. monolítico flujo de arranque modular El siguiente diagrama ilustra cómo interactúan los diferentes componentes del firmware y cómo pueden usarse juntos para respaldar el proceso de arranque (las flechas indican la secuencia de ejecución): Si estos diagramas te parecen complejos ahora, no te preocupes. Vuelve a revisarlos después de leer este artículo y te resultarán más claros. Cargador de arranque de primera etapa (FSBL) Este firmware está diseñado para inicializar computadoras y sistemas integrados con un : hacer solo lo que es absolutamente necesario y luego pasar el control al para iniciar el sistema operativo. El no carga sistemas operativos desde medios de almacenamiento que no sean el . Dado que solo inicializa el hardware subyacente y no maneja medios de arranque como discos duros, SSD o unidades flash USB, se requiere otra pieza de software para iniciar realmente un . enfoque en la inicialización mínima del hardware cargador de arranque de segunda etapa FSBL chip flash sistema operativo : Responsabilidades clave de FSBL : Cambio del de 16 bits al de 32 bits ( : o en en el caso del BIOS). CPU modo real modo protegido nota modo virtual 8086 : llamar para configurar para el Utilización de caché a FSP-T Cache-As-RAM entorno C. : inicializa el puerto de depuración configurado llamando a los métodos de inicialización específicos de la placa. Puerto de depuración : invocar para inicializar la memoria principal del sistema y guardar información crucial de la memoria del sistema. Inicialización de memoria FSP-M : configuración de pines de entrada/salida de propósito general (GPIO) para interactuar con dispositivos externos. GPIO : realización de la inicialización temprana de la plataforma y uso de para completar la inicialización del chipset, la CPU y el controlador IO. Silicio FSP-S : enumeración de dispositivos PCI y asignación de recursos como direcciones de memoria e IRQ. Enumeración PCI : configuración de las tablas y , incluida la información de preparación (tablas coreboot, HOB) que debe pasarse a la carga útil. Preparación de la carga útil SMBIOS ACPI : Carga y transferencia de control a la carga útil. Carga y transferencia BIOS (fase POST) En los primeros tiempos de la informática, el software de código abierto no era muy popular y la mayoría de las implementaciones de BIOS eran propietarias. Solo hay unas pocas soluciones abiertas disponibles que proporcionan código fuente de BIOS POST, como y . Estos proyectos fueron diseñados para funcionar en sistemas IBM 5150/5155/5160 y la mayoría de los clones XT. Super PC/Turbo XT BIOS GLaBIOS Sin embargo, las implementaciones de BIOS de código abierto más conocidas, como y , no realizan la inicialización del hardware porque no están diseñadas para ejecutarse en hardware desnudo. Pero se usan ampliamente como y se ejecutan de forma nativa en entornos virtuales como QEMU y Bochs. OpenBIOS SeaBIOS cargadores de arranque de segunda etapa En cualquier caso, es poco probable que necesites trabajar directamente con estas primeras BIOS o profundizar en sus particularidades. Pero si te interesa explorar, los repositorios mencionados son un buen punto de partida. En cuanto a las tendencias de desarrollo actuales, no parece haber un desarrollo continuo de soluciones BIOS propietarias, y dichos proyectos se han vuelto obsoletos frente a las alternativas modernas. Inicialización de la plataforma UEFI (PI) El proceso de arranque sigue un flujo escalonado, que comienza desde la izquierda y avanza hacia la derecha en la siguiente figura. La línea de tiempo del proceso de arranque de la plataforma se divide en las siguientes fases, como se indica mediante cuadros amarillos: : La primera fase después de un , su función principal es configurar la RAM temporal (CPU o SRAM). Seguridad (SEC) vector de reinicio Cache-As-RAM : esta fase envía controladores especializados denominados . Estos módulos se encargan de la inicialización esencial del hardware, como la configuración de la CPU y el chipset y la configuración de . Inicialización previa a EFI (PEI) módulos de inicialización previa a EFI (PEIM) la memoria principal (DRAM) : en esta fase se realiza el resto de la inicialización del sistema. La fase DXE proporciona y admite varios protocolos y controladores necesarios para el funcionamiento del sistema. Entorno de ejecución del controlador (DXE) servicios UEFI : esta fase implementa la política de arranque de la plataforma, determinando la secuencia de arranque y seleccionando el dispositivo/cargador de arranque adecuado. Selección de dispositivo de arranque (BDS) : durante esta fase, el sistema ejecuta aplicaciones que utilizan los servicios UEFI para preparar el SO. Incluye la transición del entorno UEFI al sistema operativo y concluye con la llamada . Carga transitoria del sistema (TSL) ExitBootServices() : En esta fase, el sistema operativo está completamente operativo, gestionando el sistema bajo su control. Tiempo de Ejecución (RT) : esta fase se ocupa de situaciones en las que el hardware o el sistema operativo fallan, se apagan o se reinician. El firmware puede intentar realizar acciones de recuperación; sin embargo, la especificación UEFI PI no define requisitos ni comportamientos específicos para esta fase. After Life (AL) Este proceso y sus fases de ejecución están contemplados en la . Sin embargo, también existe la (indicada por la línea azul en negrita en la imagen), que no forma parte del documento anterior y se describe en la . Aunque los nombres y el uso frecuente de pueden resultar confusos, estos dos documentos tienen enfoques diferentes: Especificación de Inicialización de la Plataforma UEFI (PI) Interfaz UEFI Especificación UEFI UEFI : se centra en las interfaces entre los componentes de firmware de bajo nivel y detalla cómo estos módulos interactúan para inicializar la plataforma. Especificación UEFI PI : define las interfaces para la interacción entre el sistema operativo (OS) y el firmware. Esto se analizará más a fondo en el contexto de . Tenga en cuenta que la especificación UEFI se basa en la especificación PI. Especificación UEFI Cargador de arranque de segunda etapa Básicamente, ambas especificaciones tratan sobre interfaces, pero a diferentes niveles. Para obtener información detallada, puede acceder a ambas especificaciones en el . sitio web del Foro UEFI se diseñó inicialmente como una solución de firmware unificada, sin tener en cuenta la distinción entre cargadores de arranque de primera y segunda etapa. Sin embargo, cuando nos referimos a como , incluye las fases , y . La razón por la que dividimos DXE en etapas y se debe a sus diferentes funciones en el proceso de inicialización. UEFI PI UEFI cargador de arranque de primera etapa SEC PEI DXE temprana tempranas tardías En la fase , los controladores suelen realizar la inicialización esencial de la CPU/PCH/placa y también generan , que ayudan a aislar la fase de DXE del hardware específico de la plataforma. encapsulan los detalles específicos de la plataforma, lo que permite que la fase funcione independientemente de las especificaciones del hardware. inicial de DXE protocolos arquitectónicos (AP) de DXE Los AP tardía de DXE Arranque básico Próximamente publicaré artículos detallados sobre cómo funciona Coreboot. ¡Sigue mis redes sociales, se publicarán muy pronto! Otras soluciones : cargador de arranque puro de primera etapa que proporciona únicamente la inicialización de los componentes de hardware principales, seguida de la carga de la carga útil. Sin embargo, y no es compatible con AMD x86 u otras arquitecturas. Intel Slim Bootloader (SBL) funciona únicamente en plataformas Intel x86 : es un gestor de arranque de primera y segunda etapa. Sin embargo, la compatibilidad con el arranque directo desde el x86 de la plataforma (conocido como modo básico) es limitada en comparación con otros firmware. Es más popular en sistemas integrados y dispositivos basados en ARM. Como gestor de arranque de segunda etapa, U-Boot implementa un pero se centra en los sistemas integrados. Das U-Boot vector de reinicio subconjunto de la UEFI Cargador de arranque de segunda etapa (SSBL) Una vez finalizada la configuración inicial del hardware, entra en juego la , cuya función principal es configurar una , garantizando que el SO pueda administrar los recursos del sistema e interactuar con los componentes del hardware. segunda etapa interfaz de software entre el sistema operativo y el firmware de la plataforma El objetivo es tanto como sea posible, simplificando el desarrollo de sistemas operativos y aplicaciones al manejar la mayoría de las interfaces a nivel de hardware. Esta abstracción permite a los desarrolladores centrarse en funcionalidades de nivel superior sin preocuparse por las diferencias de hardware subyacentes. de SSBL ocultar las variaciones de hardware : Responsabilidades clave de SSBL : obtiene información específica de la plataforma , incluido el mapeo de memoria, SMBIOS, tablas ACPI, flash SPI, etc. Recuperación de información de la plataforma del cargador de arranque de primera etapa : incluye controladores para SMM, SPI, PCI, SCSI/ATA/IDE/DISK, USB, ACPI, interfaces de red, etc. Ejecutar controladores independientes de la plataforma : proporciona un conjunto de servicios que facilitan la comunicación entre el sistema operativo y los componentes de hardware. Implementación de servicios (también conocida como interfaz) : ofrece un menú de configuración para la configuración del sistema, permitiendo a los usuarios ajustar configuraciones relacionadas con el orden de arranque, preferencias de hardware y otros parámetros del sistema. Menú de configuración : mecanismo para localizar y cargar la carga útil (probablemente el sistema operativo) desde el medio de arranque disponible. Lógica de arranque BIOS La interfaz del BIOS se conoce como . Estas funciones proporcionan un conjunto de rutinas para el acceso al hardware, pero los detalles específicos de cómo se ejecutan en el hardware particular del sistema están ocultos para el usuario. servicios/funciones/llamadas de interrupción del BIOS En 16 bits, se puede acceder a ellos fácilmente invocando una interrupción de software mediante una instrucción en lenguaje ensamblador x86. En de 32 bits, casi todos los servicios del BIOS no están disponibles debido a la forma diferente en que se manejan los valores . el modo real de INT el modo protegido de los segmentos Tomemos como ejemplo ( ), que proporciona servicios de lectura y escritura de discos duros y disquetes basados en sectores mediante el direccionamiento , como ejemplo de cómo se puede utilizar esta interfaz. Supongamos que queremos leer 2 sectores (1024 bytes) y cargarlos en la dirección de memoria ; en ese caso, se podría ejecutar el siguiente código: 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 Si está interesado en cómo está escrito este servicio en SeaBios, eche un vistazo a . src/disk.c Fase de arranque Comienza a buscar un (puede ser un disco duro, un CD-ROM, un disquete, etc.) leyendo el (sector cero) de los dispositivos. dispositivo de arranque primer sector de 512 bytes La secuencia de arranque en el BIOS carga el primer válido que encuentra en la memoria física de la computadora en la dirección (pista: y se refieren a la misma dirección física). registro de arranque maestro (MBR) física 0x7C00 0x0000:0x7c00 0x7c0:0x0000 El BIOS transfiere el control a los de la carga útil. Este , que es demasiado pequeño para contener todo el código de la carga útil, sirve para cargar el resto de la carga útil desde el . En este punto, la carga útil puede utilizar la interfaz expuesta por el BIOS. primeros 512 bytes sector cargado dispositivo de arranque Cabe destacar que en los primeros tiempos . La BIOS es un : funciona de la misma manera que en las computadoras IBM reales, en la década de 1980. El resto de los fabricantes simplemente y crearon BIOS compatibles con IBM. Como resultado, no había ninguna regulación que impidiera a los fabricantes de BIOS inventar nuevas funciones de BIOS o tener funcionalidades superpuestas. no existían especificaciones de BIOS estándar de facto hicieron ingeniería inversa Interfaz de firmware extensible unificada (UEFI) Como se mencionó anteriormente, UEFI en sí es solo una especificación y tiene muchas implementaciones. La más utilizada es , una de código abierto de las especificaciones UEFI y PI. Si bien EDKII por sí solo no es suficiente para crear un firmware de arranque completamente funcional, proporciona una base sólida para la mayoría de las soluciones comerciales. TianoCore EDK II implementación de referencia Para admitir distintos y proporcionar una interfaz UEFI, se utiliza el proyecto . Se basa en la configuración inicial realizada y en la información de la plataforma proporcionada por el firmware de arranque para preparar el sistema para el entorno UEFI. cargadores de arranque de primera etapa UEFI Payload La carga útil UEFI utiliza las fases y , que están diseñadas para ser independientes de la plataforma. Ofrece una carga útil genérica que puede adaptarse a diferentes plataformas. En la mayoría de los casos, no requiere ninguna personalización ni ajustes específicos de la plataforma y se puede utilizar tal como está consumiendo información de la plataforma desde el . DXE BDS cargador de arranque de primera etapa : Variantes de la carga útil UEFI : requiere una biblioteca de análisis para extraer la información necesaria de la plataforma específica de la implementación. Si el gestor de arranque actualiza su API, también se debe actualizar la carga útil. Carga útil UEFI heredada : sigue la , y utiliza o como formato de imagen común. En lugar de analizarlos por sí mismo, espera recibir los en la entrada de la carga útil. Carga útil de UEFI universal especificación de firmware escalable universal (USF) el formato ejecutable y enlazable (ELF) el árbol de imágenes planas (FIT) bloques de transferencia (HOB) Si bien la funciona bien, la comunidad EDK2 está intentando cambiar la industria hacia la . La elección entre cargas útiles depende de los componentes de su firmware. Por ejemplo, no es posible ejecutar la en sin . Por otro lado, usar la con coreboot requiere una capa de corrección para traducir en , una característica que solo está disponible en la . carga útil UEFI heredada carga útil UEFI universal carga útil heredada con soporte SMM Slim Bootloader mi parche carga útil universal las tablas de coreboot HOB bifurcación EDK2 de StarLabs Interfaz Cada sistema compatible con UEFI proporciona una que se pasa a cada código que se ejecuta en el entorno UEFI (controladores, aplicaciones, cargadores de SO). Esta estructura de datos permite que un ejecutable UEFI acceda a , como , y una colección de . tabla de sistema las tablas de configuración del sistema ACPI SMBIOS servicios UEFI La estructura de la tabla se describe en : 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; Los servicios incluyen los siguientes tipos: , y . Servicios de arranque Servicios de tiempo de ejecución Servicios proporcionados por protocolos UEFI abstrae el acceso al dispositivo mediante la configuración de . Estos y se identifican mediante un que permite que otros módulos los localicen y los utilicen. Se pueden descubrir a través de los Servicios de arranque. los Protocolos UEFI protocolos son estructuras de datos que contienen punteros de función Identificador único global (GUID) Un produce estos protocolos y las funciones reales (¡no los punteros!) están contenidas dentro del propio controlador. Este mecanismo permite que los diferentes componentes dentro del entorno UEFI se comuniquen entre sí y garantiza que el sistema operativo pueda interactuar con los dispositivos antes de cargar sus propios controladores. controlador UEFI Si bien algunos protocolos están predefinidos y descritos en la especificación UEFI, los proveedores de firmware también pueden para ampliar la funcionalidad de una plataforma. crear sus propios protocolos personalizados Servicios de arranque Proporcionar funciones que se puedan utilizar durante el arranque. Estos servicios permanecen disponibles hasta que se llama a la función ( ). únicamente EFI_BOOT_SERVICES.ExitBootServices() MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c Los punteros a todos los servicios de arranque se almacenan en la ( ): tabla de servicios de arranque 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; Servicios en tiempo de ejecución Un conjunto mínimo de servicios sigue estando accesible mientras el sistema operativo está en funcionamiento. A diferencia de los servicios de arranque, estos servicios siguen siendo válidos después de que cualquier carga útil (por ejemplo, el cargador de arranque del sistema operativo) haya tomado el control de la plataforma mediante una llamada a . EFI_BOOT_SERVICES.ExitBootServices() Los punteros a todos los servicios de tiempo de ejecución se almacenan en la ( ): tabla de servicios de tiempo de ejecución 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; La siguiente imagen muestra la línea de tiempo de los servicios de arranque y tiempo de ejecución, para que pueda ver exactamente cuándo está activo cada uno. Fase de selección de dispositivo de arranque (BDS) La especificación UEFI define un motor de políticas de arranque denominado . Intentará cargar en un orden específico. Este orden y otras configuraciones se pueden configurar modificando . Analicemos las más importantes: gestor de arranque UEFI las aplicaciones UEFI las variables globales de NVRAM (memoria de acceso aleatorio no volátil) ( se reemplaza por un valor hexadecimal único): una opción de arranque/carga. Boot#### #### : la opción de arranque utilizada para iniciar el sistema que se está ejecutando actualmente. BootCurrent : la opción de arranque solo para el siguiente arranque. Reemplaza solo para un arranque y el administrador de arranque la elimina después del primer uso. Esto le permite cambiar el comportamiento del siguiente arranque sin cambiar . BootNext BootOrder BootOrder : lista ordenada de carga de opciones de arranque. El administrador de arranque intenta arrancar la primera opción activa de esta lista. Si no lo logra, prueba con la siguiente opción, y así sucesivamente. BootOrder : los tipos de opciones de arranque compatibles con el administrador de arranque. BootOptionSupport : el tiempo de espera de los administradores de arranque del firmware, en segundos, antes de elegir automáticamente el valor de inicio de o . Timeout BootNext BootOrder Estas variables se pueden obtener fácilmente desde 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 Echemos un vistazo al arranque basándonos en el fragmento de código anterior. UEFI comenzará a iterar la lista . Para cada entrada de la lista, busca una variable correspondiente: para 0000, para 2003, y así sucesivamente. Si la variable no existe, continúa con la siguiente entrada. Si la variable existe, lee el contenido de la variable. Cada variable de opción de arranque contiene un descriptor que es un búfer lleno de bytes de campos de longitud variable (es solo la estructura de datos). BootOrder Boot#### Boot0000 Boot2003 EFI_LOAD_OPTION La estructura de datos se describe en [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; En este punto, el firmware examinará una ( ). En la mayoría de los casos, nuestra computadora se inicia desde un dispositivo de almacenamiento (disco duro/SSD/NVMe/etc.). Por lo tanto, la contendría el nodo . ruta de dispositivo EFI_DEVICE_PATH_PROTOCOL ruta del dispositivo HD(Partition Number, Type, Signature, Start sector, Size in sectors) : indica el formato utilizado para el esquema de partición con las palabras clave (1) o (2). Tipo MBR GPT : una firma MBR de 4 bytes si el tipo es , o un de 16 bytes si el tipo es . Firma MBR UUID GPT : Si está interesado en saber cómo traducir otras rutas, lea . Nota la Especificación UEFI v2.10, Referencia de nodo de dispositivo de texto 10.6.1.6 UEFI examinará el disco y verá si tiene una partición que coincida con el nodo. Si existe, debe estar etiquetada con un específico que la marque como la . Esta está formateada con un sistema de archivos cuya especificación se basa en la versión específica del y se denomina ; en realidad, es simplemente un normal. identificador único global (GUID) partición del sistema EFI (ESP) sistema de archivos FAT sistema de archivos EFI FAT12/16/32 : si la contiene una ruta explícita al , UEFI buscará ese archivo específico. Por ejemplo, la opción contiene . Arranque nativo ruta del dispositivo File(\Path\To\The\File.efi) Boot0000 File(\EFI\ARCHLINUX\grubx64.efi) : si la simplemente apunta a un disco, entonces, en tales situaciones, el firmware utilizará una que se basa en la arquitectura: ( para o para / ). Este mecanismo permite que los (por ejemplo, una unidad USB) funcionen en UEFI; solo utilizan una . Por ejemplo, la opción utilizará este mecanismo. Arranque de respaldo ruta del dispositivo ruta de arranque de respaldo \EFI\BOOT\BOOT{arch}.EFI BOOTx64.EFI amd64 BOOTia32.EFI i386 IA32 medios extraíbles de arranque ruta de arranque de respaldo Boot0002 Todas las opciones mencionadas anteriormente se refieren a las opciones de arranque que se muestran en la salida de ejemplo de . Nota: Boot#### efibootmgr En ambos casos, el cargará la (puede ser , el shell UEFI, el software de utilidad, la configuración del sistema, etc.) en la memoria. En este momento, el control se transfiere al punto de entrada de la . A diferencia del , la puede devolver el control al firmware (además de la situación en la que la aplicación toma el control del sistema). Si esto sucede o algo sale mal, el pasa a la siguiente entrada y sigue exactamente el mismo proceso. gestor de arranque UEFI aplicación UEFI el gestor de arranque del sistema operativo aplicación UEFI BIOS aplicación UEFI gestor de arranque Boot#### La especificación menciona que el puede mantener automáticamente las variables de la base de datos. Esto incluye la eliminación de las variables de opciones de carga que no están referenciadas o que no se pueden analizar. Además, puede reescribir cualquier lista ordenada para eliminar cualquier opción de carga sin las variables de opciones de carga correspondientes. gestor de arranque El texto anterior describe el . Además, el firmware UEFI puede ejecutarse en modo que emula un BIOS. arranque UEFI Módulo de soporte de compatibilidad (CSM) Cargador de arranque del sistema operativo Un programa que se inicia con el firmware (normalmente ) y que utiliza su interfaz para . Puede ser tan complejo como un sistema operativo y ofrecer funciones como: el cargador de arranque de segunda etapa cargar el núcleo del sistema operativo Lectura desde varios sistemas de archivos (HFS+, ext4, XFS, etc.) Interactuar a través de una red (por ejemplo, TFTP, HTTP) Arranque de kernels compatibles con Multiboot Carga en cadena Cargando los discos RAM iniciales ( ) initrd ¡Y más! Los diseños más comunes de estos programas quedan fuera del alcance de este artículo. Para obtener una comparación detallada de los cargadores de arranque de sistemas operativos más populares, puede consultar la y el . wiki de ArchLinux artículo de Wikipedia El sistema Windows utiliza su propio gestor de arranque del sistema operativo conocido como . Administrador de arranque de Windows (BOOTMGR) El firmware ya no es un fragmento de código, sino una , y las tendencias actuales no hacen más que contribuir a ello. Podemos ejecutar , y muchas otras aplicaciones interesantes en él. pequeño y complejo enorme cantidad de código complejo Doom Twitter Comprender la arquitectura general ayuda a organizar estos componentes en la mente. Al examinar el diseño del firmware existente, se obtiene una idea del fascinante proceso que se desarrolla cada vez que se enciende una computadora. Esta perspectiva de arriba hacia abajo no solo aclara el papel de cada parte, sino que también destaca la naturaleza sofisticada y evolutiva de los sistemas de firmware modernos. Recursos Especificación UEFI versión 2.10 Especificación de inicialización de la plataforma UEFI versión 1.8 (Erratas A) Documentación del EDK II Documentación del proyecto Slim Bootloader Arranque UEFI: ¿cómo funciona realmente? Comprender el arranque de la plataforma moderna basada en UEFI Anatomía de la secuencia de arranque UEFI en Intel Galileo Nota muy simple sobre las "rutas" de los dispositivos de disco en algunas arquitecturas comunes. Cómo se inician las computadoras

Un viaje a través de los secretos del firmware: desde la BIOS/UEFI hasta el sistema operativo

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps