Anteriormente, ya analizamos la secuencia de inicio del servidor utilizando el ejemplo heredado. Ahora es el momento de conocer mejor UEFI.
La primera versión de lo que ahora se conoce como la Interfaz de firmware extensiva unificada (UEFI) se desarrolló en los años 90 del último milenio específicamente para los sistemas Intel® Itanium® y se denominó Intel Boot Initiative y, más tarde, EFI.
Se esperaba el deseo de "actualizar" el proceso de arranque. PC-BIOS , ahora llamado Legacy, ofrece trabajar en modo real de 16 bits, direcciona solo 1 MB de RAM, y el gestor de arranque junto con la tabla de particiones deben ubicarse en los primeros 512 bytes de la unidad. Además, PC-BIOS transfiere el control al primer cargador de arranque encontrado sin la posibilidad de regresar. En este caso, el manejo de casos con varios sistemas operativos se coloca sobre los hombros del gestor de arranque.
La limitación de tamaño del cargador de arranque dicta el uso del marcado Master Boot Record (MBR), que apareció en 1983. El MBR no está estandarizado, pero muchos proveedores son "tradicionales". MBR tiene serias limitaciones: solo 4 particiones son compatibles de forma predeterminada y la capacidad de almacenamiento no supera los 2,2 TB.
En diciembre de 2000, se publicó la primera especificación EFI generalizada con la versión 1.02. Cinco años después, Intel transfirió EFI al Foro UEFI, agregando Unified al título para resaltar el cambio. La especificación UEFI está disponible públicamente y consta de varios documentos:
- Especificación ACPI;
- Especificación UEFI;
- Especificación UEFI Shell;
- Especificación de inicialización de la plataforma UEFI;
- Especificación de empaquetado de distribución de inicialización de plataforma UEFI.
La diversión comienza en la Especificación de inicialización de la plataforma UEFI , que describe todas las fases de carga de la plataforma.
UEFI es universal, pero en este artículo nos basaremos en el estándar, mirando hacia los procesadores en la arquitectura x86_64.
¡Despierta, Neo!
Después de que se inicia el encendido de la plataforma, la fuente de alimentación espera hasta que se completen los transitorios y luego establece la señal en la línea Power_Good . Y el primero en comenzar a operar no es el procesador central, sino el Intel® Management Engine (ME) independienteo AMD Secure Technology (ST) similar. Este subsistema realiza sus propias operaciones y luego prepara y lanza el primer núcleo de un solo procesador, llamado Bootstrap Processor (BSP) .
De acuerdo con la terminología aceptada, el hilo de núcleo / procesador se denominará en lo sucesivo procesador de arranque o procesador de aplicaciones.Como en Legacy, el procesador comienza a ejecutar la primera instrucción al final del espacio de direcciones en 0xFFFFFFF0 . Esta instrucción es un salto a la primera fase de inicialización de la plataforma: SEC.
Fase SEC (seguridad)
En esta fase se deben resolver las siguientes tareas:
- manejar el evento de habilitación;
- inicializar suficiente memoria para la siguiente fase;
- establecer la raíz de la confianza en el sistema;
- transferencia de la información y el control necesarios a la siguiente fase.
Los procesadores x86_64 se inician en modo real de 16 bits y, durante la inicialización inicial, el BSP se coloca en modo protegido de 32 bits . Luego, se actualiza el microcódigo de todos los procesadores disponibles.
El siguiente es el procesamiento del evento de habilitación. Esto significa la agregación de información sobre el estado del equipo para que en la siguiente fase algunos módulos puedan sacar conclusiones sobre el "estado" y el estado general de la plataforma.
Durante la fase SEC, no se produce ninguna inicialización de RAM. En cambio, el caché del procesador libre se marca como no desechable y se convierte en RAM temporal. Este modo se llama modo sin desalojo (NEM)... Se crea una pila en la memoria asignada, lo que permitirá que los módulos de las siguientes fases utilicen lenguajes de programación de pila antes de inicializar la RAM principal.
Luego, todos los procesadores de aplicaciones (procesadores de aplicaciones, AP) se inicializan con una secuencia especial de interrupciones entre procesadores (interrupción entre procesadores, IPI) que se les envía. La secuencia Init IPI - Start-up IPI - despierta el procesador de la aplicación e inicia la autoprueba integrada (BIST) en él . Los resultados de las pruebas se registran y se envían para su análisis.
Al final de la fase de seguridad, debe encontrar la sección Volumen de firmware de arranque (BFV), en la que se encuentra el código ejecutable de la siguiente fase, así como, si es posible, encontrar otras secciones menores con el código (Firmware Volume, FV).
Para justificar el nombre de la fase de Seguridad y convertirse en una raíz de confianza, durante la ejecución de esta fase, se puede verificar el código al que planeamos transferir el control para detectar cambios no autorizados y partes maliciosas del programa.
Al final de la ejecución de la SEC, se recopila la siguiente información:
- tamaño y dirección del volumen de firmware de arranque (BFV);
- el tamaño y las direcciones de otros volúmenes de firmware (FV);
- tamaño y dirección de la RAM temporal;
- el tamaño y la dirección de la pila.
Luego comienza la siguiente etapa: inicialización previa a EFI.
Fase de PEI (inicialización previa a EFI)
El propósito de la fase de inicialización previa a EFI es recopilar información sobre los dispositivos conectados y preparar la cantidad mínima de hardware necesaria para ejecutar el proceso de inicialización completo.
Por diseño, la fase PEI debería ser ligera, ya que la memoria caché del procesador es limitada. Además, la fase PEI puede recuperarse de una falla, por lo que es necesario colocar el código de la fase PEI en un almacenamiento más resistente.
Esta fase consta de un núcleo llamado PEI Foundation y los complementos del módulo PEI (PEIM) . La parte central del kernel es el administrador de módulos, PEI Dispatcher, que controla el orden de ejecución de los módulos y también organiza la interacción entre módulos (interfaz PEIM a PEIM, PPI).
Tenga en cuenta que la fase SEC se ejecutó desde la memoria flash en la placa base, y solo al comienzo de PEI, el código ejecutable necesario para esta fase se copia en la RAM temporal.
Luego viene el despachador de PEI. Lanza los módulos PEI en un orden específico: primero, módulos sin dependencias, luego dependiente del primero y así sucesivamente hasta que se agoten los módulos.
La arquitectura de la fase PEI le permite desarrollar sus propios módulos que pueden transferir los resultados de sus actividades a la siguiente fase. La transferencia de información se produce a través de una estructura de datos especial de Hand-off Block (HOB) .
En el proceso de lanzamiento de módulos PEI, tenga en cuenta lo siguiente:
- CPU PEIM : inicialización del procesador;
- Plataforma PEIM : inicialización de los puentes norte (incluido el concentrador de controlador de memoria) y sur (concentrador de controlador de E / S);
- Memory Initialization PEIM : inicialización de la RAM principal y transferencia de datos de la memoria temporal a la RAM.
Previamente, la inclusión se recibió de la fase SEC. Si el evento de encendido es S3 Resume , a continuación se ejecuta S3 BootScript , que restaura el estado guardado de los procesadores y todos los dispositivos conectados, y luego transfiere el control directamente al sistema operativo.
El estado S3 (Suspend to RAM) es un estado de suspensión en el que el procesador y parte del chipset se apagan con una pérdida de contexto. Al despertar de este estado, el procesador comienza a ejecutarse como si fuera un encendido normal. Pero en lugar de una inicialización completa y pasar todas las pruebas, el sistema se limita a restaurar el estado de todos los dispositivos.Cuando se inicia desde cualquier otro estado, el control se transfiere a la fase del entorno de ejecución del controlador.
Fase DXE (Entorno de ejecución del controlador)
Fase DXE Inicialización de AHCI La fase del entorno de ejecución del controlador (DXE) se centra en la inicialización de los dispositivos restantes. Para cuando comienza la fase DXE, el procesador y la memoria principal están listos para funcionar y los controladores DXE no están sujetos a límites estrictos de recursos.
Al igual que la Fundación PEI, esta fase tiene su propio núcleo: la Fundación DXE . El kernel crea las interfaces necesarias y carga tres tipos de servicios DXE:
- Servicios de arranque UEFI : servicios de tiempo de arranque;
- Servicios de tiempo de ejecución UEFI : servicios de tiempo de ejecución ;
- Los servicios DXE son servicios especiales requeridos por el núcleo DXE.
Una vez inicializados los servicios, DXE Dispatcher comienza a funcionar . Encuentra y carga los controladores DXE que, a su vez, completan la inicialización del hardware.
En UEFI, no hay una fase dedicada en la que el hardware pase POST (autoprueba de encendido). En cambio, cada módulo de fase PEI y DXE lleva a cabo su propio conjunto de pruebas y lo comunica mediante códigos POST al usuario y mediante HOB en las siguientes fases.Entre los muchos controladores cargados en los procesadores x86_64, vale la pena prestar atención al controlador System Management Mode Init (SMM Init). Este controlador prepara todo para que funcione el modo de administración del sistema (SMM) . SMM es un modo privilegiado especial que le permite suspender la ejecución del código actual (incluido el sistema operativo) y ejecutar el programa desde el área protegida de SMRAM en su propio contexto.
SMM se considera extraoficialmente como el anillo de protección -2. El kernel del sistema operativo se ejecuta en el anillo 0 y los anillos de protección más restringidos están numerados del 1 al 3. Oficialmente, el anillo cero se considera el más privilegiado. Sin embargo, un hipervisor virtualizado por hardware se denomina convencionalmente anillo -1, e Intel ME y AMD ST se denominan anillo -3.Además, observamos el Módulo de soporte de compatibilidad (CSM) , que proporciona compatibilidad heredada y le permite iniciar el sistema operativo sin soporte UEFI. Veremos este módulo con más detalle más adelante.
Después de inicializar todo el equipo, es hora de seleccionar un dispositivo de arranque.
Fase BDS (selección de dispositivo de arranque)
La fase de selección de dispositivo de arranque implementa la política de arranque de la aplicación UEFI. Aunque esta es una fase separada, todos los servicios, incluido el despachador, creados durante la fase DXE siguen estando disponibles.
El propósito de la fase BDS es realizar las siguientes tareas:
- inicialización de dispositivos de consola;
- busque dispositivos desde los que pueda arrancar;
- un intento de arrancar desde los dispositivos encontrados en orden de prioridad.
tarjeta adicional LSI El Administrador de arranque busca áreas de arranque en los dispositivos. Algunas tarjetas de expansión, como las tarjetas de red y los controladores RAID, pueden tener su propio "BIOS" llamado Option ROM u OpROM . El contenido de los dispositivos OpROM se inicia inmediatamente después de la detección y, después de la ejecución, el control vuelve al Administrador de arranque.
Todas las particiones que contienen áreas de descarga se almacenan en la memoria del administrador de arranque y se ordenan según el orden de arranque. Si no se encuentran aplicaciones, Boot Manager puede llamar al despachador DXE, en caso de que el despachador haya cargado controladores adicionales durante la búsqueda y se puedan "abrir" nuevos dispositivos en el gestor de arranque.
Como se señaló anteriormente, el uso del marcado Master Boot Record impone restricciones sobre el tamaño de las particiones y su número en la unidad, y también causa ciertos inconvenientes en el mantenimiento de varios sistemas operativos. La solución a todos estos problemas es parte de la especificación UEFI - Tabla de particiones GUID.
GPT (tabla de particiones GUID)
La tabla de particiones GUID es un formato de diseño de tabla de particiones estandarizado que reemplaza el MBR heredado.
Primero, GPT usa el direccionamiento de bloque lógico (LBA) en lugar del direccionamiento de cilindro, cabezal, sector (CHS). Cambiar el método de direccionamiento permite que GPT funcione con unidades de hasta 9,4 ZB (9,4 * 10 21 bytes) frente a 2,2 TB para MBR.
En segundo lugar, la tabla de particiones ha sufrido cambios, y ahora puede crear hasta 2 64 particiones dentro de una sola unidad , aunque los sistemas operativos no admiten más de 128 en el caso de Microsoft Windows y 256 en el caso de Linux.
En tercer lugar, cada sección tiene su propio identificador de tipo, que describe el propósito de la sección. Entonces, por ejemplo, el identificador C12A7328-F81F-11D2-BA4B-00A0C93EC93B apunta de manera única a la partición del sistema EFI (ESP) desde la cual Boot Manager puede intentar cargar la aplicación.
Durante el desarrollo de GPT, la compatibilidad con MBR no se escatimó. Es posible que las utilidades de disco no reconozcan el disco GPT y lo borren. Para evitar esto, durante la partición GPT, los primeros 512 bytes se llenan con Protective MBR (Protective MBR) : una partición de una partición para toda la unidad con el identificador de sistema 0xEE. Este enfoque permite que UEFI comprenda que no es un MBR real frente a él, sino un software antiguo sin soporte GPT, para ver una partición con datos de un tipo desconocido.
GPT ha abandonado el área de arranque en favor de las particiones ESP, que se reconocen como arrancables. Boot Manager recopila información sobre todos los ESP en el disco, lo que le permite tener varios cargadores de arranque en la unidad sin conflictos, uno para cada ESP.
Cargando el sistema operativo
Después de sondear todos los dispositivos y buscar áreas de arranque, Boot Manager comienza a arrancar en orden de prioridad de arranque. En general, el control se transfiere a la aplicación UEFI, que comienza a ejecutar su lógica. Sin embargo, para sistemas con compatibilidad con el modo Legacy, puede haber un MBR en la lista del área de arranque y tendrá que ir al CSM, el módulo de soporte de compatibilidad.
El CSM le permite ejecutar sistemas operativos que no son compatibles con UEFI. Para cargar dichos sistemas operativos, el módulo CSM emula el entorno en el que cae el sistema operativo "clásico":
- carga el controlador heredado;
- carga BIOS heredado;
- pone la salida de video en modo compatible con Legacy;
- Crea estructuras de datos necesarias para Legacy en la memoria que no están disponibles en UEFI;
- carga el controlador CompatibilitySmm para que SMM funcione en Legacy.
Recuerde que en el modo Legacy, el sistema operativo se inicia en el modo de 16 bits, mientras que en UEFI todo funciona en el modo de 32 bits. CSM inicia el cargador de arranque heredado en modo de 16 bits y proporciona comunicación con controladores UEFI de 32 bits según sea necesario.
Fase RT (tiempo de ejecución)
El inicio del sistema operativo o del cargador de arranque heredado conduce al inicio de la fase de tiempo de ejecución. En esta fase, todos los servicios DXE (excepto UEFI Runtime Services) ya no están disponibles.
El contenido de la fase RT puede variar. Puede haber un cargador de SO familiar de Legacy, por ejemplo, GRUB2 o Windows Boot Manager, que pone el procesador en modo de 64 bits e inicia el SO. Pero puede haber aplicaciones independientes o simplemente el kernel del sistema operativo.
El kernel de Linux a partir de la versión 3.3, si está presente el indicador CONFIG_EFI_STUB, se convierte en una aplicación UEFI normal y se puede iniciar desde UEFI sin utilizar cargadores de arranque de terceros.
Como en el caso del Legacy, el gestor de arranque o el propio kernel necesita poner el procesador en modo de 64 bits, cargar todos los controladores, configurar el programador y ejecutar init. Init, a su vez, inicia procesos en el espacio de usuario, después de lo cual aparece la ventana de inicio de sesión del SO.
Conclusión
Arrancar en UEFI es un proceso más complejo, pero estandarizado y en gran parte universal. Las similitudes con Legacy se observan solo en términos generales, y el diablo, como saben, está en los detalles.
¿Qué tan pronto crees que será posible dejar Legacy por completo?
Escribe tu opinión en los comentarios.