Interfaz de firmware extensible unificada ( UEFI , / ˈ juː ɪ f aɪ / o como acrónimo) [b] es una especificación que define la arquitectura del firmware de la plataforma utilizada para el arranque del hardware de la computadora y su interfaz para la interacción con el sistema operativo . Ejemplos de firmware que implementan la especificación son AMI Aptio , Phoenix SecureCore , TianoCore EDK II , InsydeH2O . UEFI reemplaza el BIOS que estaba presente en la ROM de arranque de todas las computadoras personales que son compatibles con IBM PC , [1] [2] aunque puede proporcionar compatibilidad con versiones anteriores del BIOS mediante el arranque CSM. Intel desarrolló la especificación original de interfaz de firmware extensible ( EFI ). Algunas de las prácticas y formatos de datos de EFI reflejan los de Microsoft Windows . [3] [4] En 2005, UEFI dejó de utilizar EFI 1.10 (la versión final de EFI).
UEFI es independiente de la plataforma y el lenguaje de programación, pero se utiliza C para la implementación de referencia TianoCore EDKII.
A diferencia de su predecesor BIOS, que es un estándar de facto creado originalmente por IBM como software propietario, UEFI es un estándar abierto mantenido por un consorcio industrial .
La motivación original para EFI surgió durante el desarrollo inicial de los primeros sistemas Intel-HP Itanium a mediados de la década de 1990. Las limitaciones del BIOS (como el modo real de 16 bits , 1 MB de espacio de memoria direccionable, [5] programación en lenguaje ensamblador y hardware PC AT ) se habían vuelto demasiado restrictivas para las plataformas de servidores más grandes a las que apuntaba Itanium. [6] El esfuerzo para abordar estas preocupaciones comenzó en 1998 y inicialmente se llamó Intel Boot Initiative . [7] Posteriormente se le cambió el nombre a Interfaz de firmware extensible (EFI). [8] [9]
La primera implementación UEFI de código abierto , Tiano, fue lanzada por Intel en 2004. Desde entonces, Tiano ha sido reemplazado por EDK [10] y EDK2 [11] y ahora lo mantiene la comunidad TianoCore. [12]
En julio de 2005, Intel dejó de desarrollar la especificación EFI en la versión 1.10 y la contribuyó al Foro Unificado EFI , que desarrolló la especificación como Interfaz de firmware extensible unificada (UEFI). La especificación EFI original sigue siendo propiedad de Intel, que proporciona licencias exclusivas para productos basados en EFI, pero la especificación UEFI es propiedad del Foro UEFI. [6] [13]
La versión 2.0 de la especificación UEFI se publicó el 31 de enero de 2006. Agregó criptografía y seguridad.
La versión 2.1 de la especificación UEFI se publicó el 7 de enero de 2007. Agregó autenticación de red y la arquitectura de interfaz de usuario ('Infraestructura de interfaz humana' en UEFI).
En octubre de 2018, Arm anunció Arm ServerReady, un programa de certificación de cumplimiento para implementar hipervisores y sistemas operativos genéricos disponibles en el mercado en servidores basados en Arm. El programa requiere que el firmware del sistema cumpla con los requisitos de arranque base del servidor (SBBR). SBBR requiere cumplimiento con UEFI, ACPI y SMBIOS . En octubre de 2020, Arm anunció la extensión del programa al mercado perimetral y de IoT . El nuevo nombre del programa es Arm SystemReady. Arm SystemReady definió la especificación Base Boot Requisitos (BBR) que actualmente proporciona tres recetas, dos de las cuales están relacionadas con UEFI: 1) SBBR: que requiere cumplimiento UEFI, ACPI y SMBIOS adecuado para entornos operativos de nivel empresarial como Windows, Red Hat Enterprise Linux y VMware ESXi; y 2) EBBR: que requiere el cumplimiento de un conjunto de interfaces UEFI según lo definido en los Requisitos de arranque base integrados (EBBR) adecuados para entornos integrados como Yocto. Muchas distribuciones de Linux y BSD pueden admitir ambas recetas.
En diciembre de 2018, Microsoft anunció Project Mu, una bifurcación de TianoCore EDK2 utilizada en los productos Microsoft Surface y Hyper-V . El proyecto promueve la idea de Firmware como Servicio . [14]
La última especificación UEFI, versión 2.10, se publicó en agosto de 2022. [15]
La interfaz definida por la especificación EFI incluye tablas de datos que contienen información de la plataforma y servicios de arranque y tiempo de ejecución que están disponibles para el cargador del sistema operativo y el sistema operativo. El firmware UEFI proporciona varias ventajas técnicas sobre un BIOS: [16]
A partir de la versión 2.5, existen enlaces de procesador para Itanium, x86, x86-64, ARM (AArch32) y ARM64 (AArch64). [19] Sólo se pueden admitir procesadores little-endian . [20] Se está desarrollando soporte UEFI no oficial para POWERPC64 mediante la implementación de TianoCore sobre OPAL, [21] la capa de abstracción OpenPOWER, ejecutándose en modo little-endian. [22] Existen proyectos similares para MIPS [23] y RISC-V . [24] A partir de UEFI 2.7, los enlaces de procesador RISC-V se han establecido oficialmente para los modos de 32, 64 y 128 bits. [25]
El BIOS de PC estándar está limitado a un modo de procesador de 16 bits y 1 MB de espacio de memoria direccionable, como resultado del diseño basado en el IBM 5150 que usaba un procesador Intel 8088 de 16 bits . [6] [26] En comparación, el modo del procesador en un entorno UEFI puede ser de 32 bits ( x86-32 , AArch32) o de 64 bits ( x86-64 , Itanium y AArch64). [6] [27] Las implementaciones de firmware UEFI de 64 bits admiten el modo largo , que permite que las aplicaciones en el entorno previo al arranque utilicen direccionamiento de 64 bits para obtener acceso directo a toda la memoria de la máquina. [28]
UEFI requiere que el tamaño del cargador (o kernel) del firmware y del sistema operativo coincida; es decir, una implementación de firmware UEFI de 64 bits puede cargar solo un cargador de arranque o kernel de sistema operativo (SO) de 64 bits (a menos que se utilice el arranque heredado basado en CSM) y lo mismo se aplica a 32 bits. Después de que el sistema pasa de "Servicios de arranque" a "Servicios de ejecución", el kernel del sistema operativo toma el control. En este punto, el kernel puede cambiar los modos del procesador si lo desea, pero esto impide el uso de los servicios de tiempo de ejecución (a menos que el kernel vuelva a cambiar). [29] : secciones 2.3.2 y 2.3.4 A partir de la versión 3.15, el kernel de Linux admite kernels de 64 bits que se inician en implementaciones de firmware UEFI de 32 bits que se ejecutan en CPU x86-64 , con soporte de transferencia UEFI desde un arranque UEFI. cargador como requisito. [30] El protocolo de transferencia UEFI deduplica el código de inicialización UEFI entre el kernel y los cargadores de arranque UEFI, dejando que la inicialización la realice únicamente el código auxiliar de arranque UEFI del kernel de Linux . [31] [32]
Además del esquema de partición de disco de PC estándar que utiliza un registro de arranque maestro (MBR), UEFI también funciona con el esquema de partición de tabla de particiones GUID (GPT), que está libre de muchas de las limitaciones de MBR. En particular, se relajan los límites del MBR en cuanto al número y tamaño de las particiones del disco (hasta cuatro particiones primarias por disco y hasta 2 TB (2 × 2 40 bytes ) por disco). [33] Más específicamente, GPT permite un tamaño máximo de disco y partición de 8 ZiB (8 × 2 70 bytes) . [34] [35]
La compatibilidad con GPT en Linux se habilita activando la opción CONFIG_EFI_PARTITION(Soporte de partición GUID EFI) durante la configuración del kernel. [36] Esta opción permite a Linux reconocer y utilizar discos GPT después de que el firmware del sistema pasa el control del sistema a Linux.
Para lograr compatibilidad inversa, Linux puede usar discos GPT en sistemas basados en BIOS tanto para el almacenamiento de datos como para el arranque, ya que tanto GRUB 2 como Linux son compatibles con GPT. Esta configuración suele denominarse BIOS-GPT . [37] [ ¿ fuente poco confiable? ] Como GPT incorpora el MBR protector, una computadora basada en BIOS puede arrancar desde un disco GPT utilizando un cargador de arranque compatible con GPT almacenado en el área de código de arranque del MBR protector . [35] En el caso de GRUB, dicha configuración requiere una partición de arranque de BIOS para que GRUB incruste su código de segunda etapa debido a la ausencia de la brecha posterior al MBR en los discos particionados GPT (que es asumida por el encabezado primario de GPT y Tabla de particiones primarias ). Normalmente tiene un tamaño de 1 MB , el identificador único global (GUID) de esta partición en el esquema GPT es 21686148-6449-6E6F-744E-656564454649 y GRUB lo utiliza solo en configuraciones BIOS-GPT. Desde la perspectiva de GRUB, no existe tal tipo de partición en el caso de la partición MBR. Esta partición no es necesaria si el sistema está basado en UEFI porque en ese caso no es necesario incrustar el código de la segunda etapa. [17] [35] [37]
Los sistemas UEFI pueden acceder a los discos GPT y arrancar directamente desde ellos, lo que permite a Linux utilizar métodos de arranque UEFI. Arrancar Linux desde discos GPT en sistemas UEFI implica la creación de una partición del sistema EFI (ESP), que contiene aplicaciones UEFI como cargadores de arranque, kernels del sistema operativo y software de utilidad. [38] [39] [40] [ ¿ fuente poco confiable? ] Esta configuración generalmente se conoce como UEFI-GPT , mientras que se recomienda que ESP tenga un tamaño mínimo de 512 MB y esté formateado con un sistema de archivos FAT32 para una máxima compatibilidad. [35] [37] [41] [ ¿ fuente poco confiable? ]
Para compatibilidad con versiones anteriores , algunas implementaciones UEFI también admiten el arranque desde discos particionados con MBR a través del Módulo de soporte de compatibilidad (CSM) que proporciona compatibilidad con BIOS heredado. [42] En ese caso, iniciar Linux en sistemas UEFI es el mismo que en sistemas heredados basados en BIOS.
Las versiones de 64 bits de Windows Vista SP1 y posteriores y las versiones de 32 bits de Windows 8 , 8.1 y 10 pueden arrancar desde un disco GPT de más de 2 TB .
EFI define dos tipos de servicios: servicios de arranque y servicios de tiempo de ejecución . Los servicios de arranque están disponibles sólo mientras el firmware es propietario de la plataforma (es decir, antes de la ExitBootServices()llamada) e incluyen consolas gráficas y de texto en varios dispositivos, y servicios de bus, bloques y archivos. Los servicios en tiempo de ejecución aún son accesibles mientras el sistema operativo está en ejecución; Incluyen servicios como fecha, hora y acceso a NVRAM .
Más allá de cargar un sistema operativo, UEFI puede ejecutar aplicaciones UEFI , que residen como archivos en la partición del sistema EFI . Se pueden ejecutar desde UEFI Shell, mediante el administrador de arranque del firmware o mediante otras aplicaciones UEFI. Las aplicaciones UEFI se pueden desarrollar e instalar independientemente de los fabricantes de equipos originales (OEM).
Un tipo de aplicación UEFI es un cargador de arranque del sistema operativo como GRUB , rEFInd , Gummiboot y Windows Boot Manager , que carga algunos archivos del sistema operativo en la memoria y los ejecuta. Además, un cargador de arranque del sistema operativo puede proporcionar una interfaz de usuario para permitir la selección de otra aplicación UEFI para ejecutar. Utilidades como UEFI Shell también son aplicaciones UEFI.
EFI define protocolos como un conjunto de interfaces de software utilizadas para la comunicación entre dos módulos binarios. Todos los conductores de EFI deben brindar servicios a otros a través de protocolos. Los protocolos EFI son similares a las llamadas de interrupción del BIOS .
Además de los controladores de dispositivo específicos de la arquitectura del conjunto de instrucciones estándar , EFI proporciona un controlador de dispositivo independiente de ISA almacenado en la memoria no volátil como código de bytes EFI o EBC . El firmware del sistema tiene un intérprete para imágenes EBC. En ese sentido, EBC es análogo a Open Firmware , el firmware independiente de ISA utilizado en computadoras Apple Macintosh y Sun Microsystems SPARC basadas en PowerPC , entre otras.
Algunos controladores EFI específicos de la arquitectura (que no son de código de bytes EFI) para algunos tipos de dispositivos pueden tener interfaces para que las utilice el sistema operativo. Esto permite que el sistema operativo dependa de EFI para que los controladores realicen funciones de red y gráficos básicos antes y si se cargan los controladores específicos del sistema operativo.
En otros casos, el controlador EFI puede ser un controlador de sistema de archivos que permite el arranque desde otros tipos de volúmenes de disco. Los ejemplos incluyen efifs para 37 sistemas de archivos (basados en código GRUB2 ), [46] utilizados por Rufus para cargar en cadena ESP NTFS. [47]
La especificación EFI 1.0 definió un protocolo UGA (adaptador gráfico universal) como una forma de admitir funciones gráficas. UEFI no incluyó UGA y lo reemplazó con GOP (Protocolo de salida de gráficos) . [48]
UEFI 2.1 definió una "Infraestructura de interfaz humana" (HII) para administrar la entrada del usuario, cadenas localizadas, fuentes y formularios (en el sentido HTML ). Estos permiten a los fabricantes de equipos originales (OEM) o proveedores de BIOS independientes (IBV) diseñar interfaces gráficas para la configuración previa al arranque.
La mayoría de las primeras implementaciones de firmware UEFI se basaban en consolas. Hoy en día, muchas implementaciones de firmware UEFI están basadas en GUI.
Una partición del sistema EFI, a menudo abreviada como ESP, es una partición de dispositivo de almacenamiento de datos que se utiliza en computadoras que cumplen con la especificación UEFI. Al que accede el firmware UEFI cuando se enciende una computadora, almacena las aplicaciones UEFI y los archivos que estas aplicaciones necesitan para ejecutarse, incluidos los cargadores de arranque del sistema operativo . Los esquemas de tablas de particiones admitidos incluyen MBR y GPT , así como volúmenes de El Torito en discos ópticos. [29] : sección 2.6.2 Para uso en ESP, UEFI define una versión específica del sistema de archivos FAT , que se mantiene como parte de la especificación UEFI e independientemente de la especificación FAT original, que abarca los sistemas de archivos FAT32 , FAT16 y FAT12. . [29] : sección 12.3 [49] [50] [51] El ESP también proporciona espacio para un sector de arranque como parte de la compatibilidad con versiones anteriores del BIOS. [42]
A diferencia del BIOS de PC heredado, UEFI no se basa en sectores de arranque , sino que define un administrador de arranque como parte de la especificación UEFI. Cuando se enciende una computadora, el administrador de arranque verifica la configuración de arranque y, según su configuración, luego ejecuta el cargador de arranque del sistema operativo o el kernel del sistema operativo especificado (generalmente el cargador de arranque [52] ). La configuración de arranque está definida por variables almacenadas en NVRAM , incluidas variables que indican las rutas del sistema de archivos a los cargadores del sistema operativo o los núcleos del sistema operativo.
UEFI puede detectar automáticamente los cargadores de arranque del sistema operativo, lo que permite un arranque sencillo desde dispositivos extraíbles, como unidades flash USB . Esta detección automática se basa en rutas de archivos estandarizadas al cargador de arranque del sistema operativo, y la ruta varía según la arquitectura de la computadora . El formato de la ruta del archivo se define como <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI ; por ejemplo, la ruta del archivo al cargador del sistema operativo en un sistema x86-64 es \efi\boot\bootx64.efi , [29] y \efi\boot\bootaa64.efi en la arquitectura ARM64.
El arranque de sistemas UEFI desde discos particionados por GPT se denomina comúnmente arranque UEFI-GPT . A pesar de que la especificación UEFI requiere que las tablas de particiones MBR sean totalmente compatibles, [29] algunas implementaciones de firmware UEFI cambian inmediatamente al arranque CSM basado en BIOS dependiendo del tipo de tabla de particiones del disco de arranque, lo que impide efectivamente que el arranque UEFI se realice desde Partición del sistema EFI en discos particionados con MBR. [42] Este esquema de arranque se denomina comúnmente UEFI-MBR .
También es común que un administrador de arranque tenga una interfaz de usuario textual para que el usuario pueda seleccionar el sistema operativo (o utilidad de configuración) deseado de una lista de opciones de arranque disponibles.
Para garantizar la compatibilidad con versiones anteriores, las implementaciones de firmware UEFI en máquinas tipo PC podrían admitir el arranque en modo BIOS heredado desde discos particionados con MBR a través del Módulo de soporte de compatibilidad (CSM) que proporciona compatibilidad con BIOS heredado. En este escenario, el arranque se realiza de la misma manera que en los sistemas heredados basados en BIOS, ignorando la tabla de particiones y confiando en el contenido de un sector de arranque . [42]
El arranque estilo BIOS desde discos particionados por MBR se denomina comúnmente BIOS-MBR , independientemente de que se realice en sistemas UEFI o basados en BIOS heredados. Además, también es posible arrancar sistemas heredados basados en BIOS desde discos GPT, y dicho esquema de arranque se denomina comúnmente BIOS-GPT .
El módulo de soporte de compatibilidad permite seguir utilizando sistemas operativos heredados y algunas ROM opcionales heredadas que no son compatibles con UEFI. [53] También proporciona la funcionalidad requerida del Modo de administración del sistema (SMM) heredada, llamada CompatibilitySmm , como una adición a las funciones proporcionadas por UEFI SMM. Un ejemplo de una funcionalidad SMM heredada es proporcionar soporte USB heredado para teclado y mouse, emulando sus contrapartes PS/2 clásicas. [53]
En noviembre de 2017, Intel anunció que planeaba eliminar gradualmente el soporte para CSM para 2020. [54]
En julio de 2022, Kaspersky Labs publicó información sobre un Rootkit diseñado para iniciar en cadena código malicioso en máquinas que utilizan el chipset H81 de Intel y el módulo de soporte de compatibilidad de las placas base afectadas. [55]
La especificación UEFI incluye soporte para el arranque a través de la red a través del entorno de ejecución previa al arranque (PXE). Los protocolos de red de arranque PXE incluyen el Protocolo de Internet ( IPv4 e IPv6 ), el Protocolo de datagramas de usuario (UDP), el Protocolo de configuración dinámica de host (DHCP), el Protocolo trivial de transferencia de archivos (TFTP) e iSCSI . [29] [56]
Las imágenes del sistema operativo se pueden almacenar de forma remota en redes de área de almacenamiento (SAN), con Internet Small Computer System Interface (iSCSI) y Fibre Channel over Ethernet (FCoE) como protocolos compatibles para acceder a las SAN. [29] [57] [58]
La versión 2.5 de la especificación UEFI agrega soporte para acceder a imágenes de arranque a través de HTTP . [59]
La especificación UEFI define un protocolo conocido como Arranque seguro , que puede proteger el proceso de arranque impidiendo la carga de controladores UEFI o cargadores de arranque del sistema operativo que no estén firmados con una firma digital aceptable . No se especifican los detalles mecánicos de con qué precisión se deben firmar estos controladores. [60] Cuando el arranque seguro está habilitado, inicialmente se coloca en modo "configuración", lo que permite escribir una clave pública conocida como "clave de plataforma" (PK) en el firmware. Una vez escrita la clave, Secure Boot ingresa al modo "Usuario", donde el firmware solo puede cargar los controladores UEFI y los cargadores de arranque del sistema operativo firmados con la clave de la plataforma. Se pueden agregar "claves de intercambio de claves" (KEK) adicionales a una base de datos almacenada en la memoria para permitir el uso de otros certificados, pero aún deben tener una conexión con la parte privada de la clave de la plataforma. [61] El arranque seguro también se puede colocar en modo "Personalizado", donde se pueden agregar claves públicas adicionales al sistema que no coinciden con la clave privada. [62]
El arranque seguro es compatible con Windows 8 y 8.1 , Windows Server 2012 y 2012 R2, Windows 10 , Windows Server 2016 , 2019 y 2022 , y Windows 11 , VMware vSphere 6.5 [63] y varias distribuciones de Linux , incluido Fedora (desde la versión 18), openSUSE (desde la versión 12.3), RHEL (desde la versión 7), CentOS (desde la versión 7 [64] ), Debian (desde la versión 10), [65] , Ubuntu (desde la versión 12.04.2) y Linux Mint ( desde la versión 21.3). [66] [67] A partir de enero de 2024 [actualizar], el soporte de FreeBSD se encuentra en una etapa de planificación. [68]
UEFI proporciona un entorno de shell , que se puede utilizar para ejecutar otras aplicaciones UEFI, incluidos los cargadores de arranque UEFI . [40] Aparte de eso, los comandos disponibles en el shell UEFI se pueden usar para obtener otra información sobre el sistema o el firmware, incluida la obtención del mapa de memoria ( memmap), la modificación de las variables del administrador de arranque ( bcfg), la ejecución de programas de partición ( diskpart), la carga. Controladores UEFI y edición de archivos de texto ( edit). [69] [ ¿ fuente poco confiable? ] [70] [71]
El código fuente para un shell UEFI se puede descargar desde el proyecto TianoCore UDK/EDK2 de Intel . [72] También está disponible un ShellBinPkg prediseñado. [73] Shell v2 funciona mejor en sistemas UEFI 2.3+ y se recomienda sobre Shell v1 en esos sistemas. Shell v1 debería funcionar en todos los sistemas UEFI. [69] [74] [75]
Los métodos utilizados para iniciar UEFI shell dependen del fabricante y modelo de la placa base del sistema . Algunos de ellos ya ofrecen una opción directa en la configuración del firmware para el inicio; por ejemplo, la versión compilada x86-64 del shell debe estar disponible como archivo <EFI_SYSTEM_PARTITION>/SHELLX64.EFI. Algunos otros sistemas tienen un shell UEFI ya integrado que se puede iniciar presionando las combinaciones de teclas adecuadas. [76] [ ¿ fuente poco confiable? ] [77] Para otros sistemas, la solución es crear una unidad flash USB adecuada o agregar manualmente ( bcfg) una opción de arranque asociada con la versión compilada del shell. [71] [76] [78] [ ¿ fuente poco confiable? ] [79] [ ¿ fuente poco confiable? ]
La siguiente es una lista de comandos admitidos por el shell EFI. [70]
Las extensiones de UEFI se pueden cargar desde prácticamente cualquier dispositivo de almacenamiento no volátil conectado a la computadora. Por ejemplo, un fabricante de equipos originales (OEM) puede distribuir sistemas con una partición del sistema EFI en el disco duro, lo que agregaría funciones adicionales al firmware UEFI estándar almacenado en la ROM de la placa base .
UEFI Capsule define una interfaz de actualización de firmware a sistema operativo, comercializada como moderna y segura. [80] Windows 8 , Windows 8.1 , Windows 10 , [81] y Fwupd para Linux son compatibles con UEFI Capsule.
Al igual que BIOS , UEFI inicializa y prueba los componentes de hardware del sistema (por ejemplo, entrenamiento de memoria, entrenamiento de enlace PCIe, entrenamiento de enlace USB) y luego carga el cargador de arranque desde un dispositivo de almacenamiento masivo o mediante una conexión de red . En los sistemas x86 , el firmware UEFI generalmente se almacena en el chip flash NOR de la placa base. [82]
Las máquinas UEFI pueden tener una de las siguientes clases, que se utilizaron para ayudar a facilitar la transición a UEFI: [83]
A partir del Intel Core de décima generación, Intel ya no proporciona BIOS de video heredado para la iGPU ( tecnología de gráficos Intel ). El arranque heredado con esas CPU requiere un BIOS de video heredado, que aún puede ser proporcionado por una tarjeta de video. [ cita necesaria ]
Esta es la primera etapa del arranque UEFI, pero puede tener un código binario específico de la plataforma precedido. (p. ej., Intel ME , AMD PSP , microcódigo de CPU ). Consiste en un código mínimo escrito en lenguaje ensamblador para la arquitectura específica. Inicializa una memoria temporal (a menudo caché de la CPU como RAM, o SRAM en chip SoC, CAR) y sirve como raíz de confianza del software del sistema con la opción de verificar PEI antes de la transferencia.
La segunda etapa del arranque UEFI consiste en un despachador consciente de las dependencias que carga y ejecuta módulos PEI (PEIM) para manejar las primeras tareas de inicialización del hardware, como la inicialización de la memoria principal y las operaciones de recuperación del firmware. Además, es responsable de descubrir el modo de inicio actual y de manejar muchas operaciones de ACPI S3. En el caso de la reanudación de ACPI S3, es responsable de restaurar muchos registros de hardware a un estado anterior al modo de suspensión. PEI también utiliza CAR.
Esta etapa consta de módulos C y un despachador consciente de las dependencias. Con la memoria principal ahora disponible, la CPU, el chipset, la placa base y otros dispositivos de E/S se inicializan en DXE y BDS.
BDS es parte del DXE. [85] [86] En esta etapa, los dispositivos de arranque se inicializan, los controladores UEFI o las ROM opcionales de los dispositivos PCI se ejecutan de acuerdo con la configuración del sistema y se procesan las opciones de arranque.
Esta es la etapa entre la selección del dispositivo de arranque y la transferencia al sistema operativo. En este punto, uno puede ingresar al shell UEFI o ejecutar una aplicación UEFI como el cargador de arranque del sistema operativo.
La UEFI pasa al sistema operativo (SO) después de ejecutar ExitBootServices() . Un sistema operativo compatible con UEFI ahora es responsable de salir de los servicios de arranque, lo que activa el firmware para descargar todos los códigos y datos que ya no son necesarios, dejando solo el código/datos de los servicios de tiempo de ejecución, por ejemplo, SMM y ACPI . [87] Un sistema operativo moderno típico preferirá utilizar sus propios programas (como controladores del kernel ) para controlar los dispositivos de hardware.
Cuando se utiliza un sistema operativo heredado, CSM manejará esta llamada asegurando que el sistema sea compatible con las expectativas del BIOS heredado.
La implementación de EFI por parte de Intel es Intel Platform Innovation Framework , cuyo nombre en código es Tiano . Tiano se ejecuta en los procesadores Intel XScale , Itanium , x86-32 y x86-64 , y es software propietario, aunque una parte del código se ha publicado bajo la licencia BSD o Eclipse Public License (EPL) como TianoCore EDK II . TianoCore se puede utilizar como carga útil para coreboot . [88]
La implementación de UEFI de Phoenix Technologies se denomina SecureCore Technology (SCT). [89] American Megatrends ofrece su propia implementación de firmware UEFI conocida como Aptio, [90] mientras que Insyde Software ofrece InsydeH2O, [91] y Byosoft ofrece ByoCore.
En diciembre de 2018, Microsoft lanzó una versión de código abierto de su implementación UEFI basada en TianoCore EDK2 de la línea Surface , Project Mu . [92]
En 2017 se introdujo una implementación de la API UEFI en Universal Boot Loader ( Das U-Boot ) . [93] En la arquitectura ARMv8 , las distribuciones de Linux utilizan la implementación U-Boot UEFI junto con GNU GRUB para el arranque (por ejemplo, SUSE Linux [ 94] ), lo mismo es válido para OpenBSD. [95] Para arrancar desde iSCSI, iPXE se puede utilizar como una aplicación UEFI cargada por U-Boot. [96]
Las primeras estaciones de trabajo y servidores Itanium de Intel , lanzadas en 2000, implementaron EFI 1.02.
Los primeros sistemas Itanium 2 de Hewlett-Packard , lanzados en 2002, implementaron EFI 1.10; pudieron arrancar Windows , Linux , FreeBSD y HP-UX ; OpenVMS añadió capacidad UEFI en junio de 2003.
En enero de 2006, Apple Inc. envió sus primeras computadoras Macintosh basadas en Intel . Estos sistemas utilizaban EFI en lugar de Open Firmware , que se había utilizado en sus sistemas anteriores basados en PowerPC. [97] El 5 de abril de 2006, Apple lanzó por primera vez Boot Camp , que produce un disco de controladores de Windows y una herramienta de partición no destructiva para permitir la instalación de Windows XP o Vista sin necesidad de reinstalar Mac OS X (ahora macOS). También se lanzó una actualización de firmware que agregó compatibilidad de BIOS a su implementación EFI. Los modelos posteriores de Macintosh se enviaron con el firmware más nuevo. [98]
Durante 2005, más de un millón de sistemas Intel se enviaron con la implementación UEFI de Intel. [99] [ verificación fallida ] Nuevos productos móviles, de escritorio y de servidor, que utilizan la implementación de UEFI de Intel, comenzaron a distribuirse en 2006. Por ejemplo, las placas que utilizan la serie de chipsets Intel 945 utilizan la implementación de firmware UEFI de Intel.
Desde 2005, EFI también se ha implementado en arquitecturas que no son de PC, como sistemas integrados basados en núcleos XScale . [99]
El EDK (EFI Developer Kit) incluye un destino NT32, que permite que el firmware EFI y las aplicaciones EFI se ejecuten dentro de una aplicación de Windows . Pero EDK NT32 no permite el acceso directo al hardware. Esto significa que el destino EDK NT32 solo puede ejecutar un subconjunto de aplicaciones y controladores EFI.
En 2008, más sistemas x86-64 adoptaron UEFI. Si bien muchos de estos sistemas todavía permiten iniciar solo los sistemas operativos basados en BIOS a través del Módulo de soporte de compatibilidad (CSM) (por lo que al usuario no le parecen basados en UEFI), otros sistemas comenzaron a permitir el inicio de sistemas operativos basados en UEFI. Por ejemplo, servidor IBM x3450, placas base MSI con ClickBIOS, computadoras portátiles HP EliteBook.
En 2009, IBM envió máquinas System x (x3550 M2, x3650 M2, iDataPlex dx360 M2) y BladeCenter HS22 con capacidad UEFI. Dell envió servidores PowerEdge T610, R610, R710, M610 y M710 con capacidad UEFI. En un documento técnico de UEFI se mencionan más sistemas disponibles comercialmente. [100]
En 2011, los principales proveedores (como ASRock , Asus , Gigabyte y MSI ) lanzaron varias placas base orientadas al consumidor que utilizaban el chipset Intel LGA 1155 de la serie 6 y los chipsets AMD 9 Series AM3+ con UEFI. [101]
Con el lanzamiento de Windows 8 en octubre de 2012, los requisitos de certificación de Microsoft ahora exigen que las computadoras incluyan firmware que implemente la especificación UEFI. Además, si la computadora admite la función " Espera conectada " de Windows 8 (que permite que los dispositivos tengan una administración de energía comparable a la de los teléfonos inteligentes , con un regreso casi instantáneo del modo de espera), entonces no se permite que el firmware contenga un módulo de soporte de compatibilidad ( CSM). Como tal, los sistemas que admiten Connected Standby no pueden iniciar sistemas operativos Legacy BIOS. [102] [103]
En octubre de 2017, Intel anunció que eliminaría la compatibilidad con BIOS de PC heredados de todos sus productos para 2020, a favor de UEFI Clase 3. [104]
Un sistema operativo que se puede iniciar desde un (U)EFI se denomina sistema operativo compatible con (U)EFI, definido por la especificación (U)EFI. Aquí el término iniciado desde un (U)EFI significa iniciar directamente el sistema utilizando un cargador del sistema operativo (U)EFI almacenado en cualquier dispositivo de almacenamiento. La ubicación predeterminada para el cargador del sistema operativo es , <EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFIdonde el nombre corto del tipo de máquina puede ser IA32, X64, o . [29] Algunos proveedores de sistemas operativos pueden tener sus propios cargadores de arranque. También pueden cambiar la ubicación de inicio predeterminada.IA64ARMAA64
El kit de desarrollo de aplicaciones (EADK) EDK2 permite utilizar funciones de biblioteca C estándar en aplicaciones UEFI. EADK se puede descargar gratuitamente desde el proyecto SourceForge TianoCore UDK/EDK2 de Intel . Como ejemplo, un puerto del intérprete de Python está disponible como aplicación UEFI mediante el uso de EADK. [141] El desarrollo se ha trasladado a GitHub desde UDK2015. [142]
Un programa C minimalista " hola, mundo " escrito con EADK se parece a su contraparte habitual en C :
#include <Uefi.h> #include <Biblioteca/UefiLib.h> #include <Biblioteca/ShellCEntryLib.h> EFI_STATUS EFIAPI ShellAppMain ( EN UINTN Argc , EN CHAR16 ** Argv ) { Imprimir ( L "hola mundo \n " ); devolver EFI_SUCCESS ; } Numerosos activistas de derechos digitales han protestado contra la UEFI. Ronald G. Minnich, coautor de coreboot , y Cory Doctorow , activista de derechos digitales, han criticado a UEFI como un intento de eliminar la capacidad del usuario de controlar verdaderamente la computadora. [143] [144] No resuelve los problemas de larga data del BIOS de requerir dos controladores diferentes, uno para el firmware y otro para el sistema operativo, para la mayoría del hardware. [145]
El proyecto de código abierto TianoCore también proporciona UEFI. [146] TianoCore carece de controladores especializados que inicializan las funciones del chipset, que en cambio son proporcionados por coreboot , del cual TianoCore es una de las muchas opciones de carga útil. El desarrollo de coreboot requiere la cooperación de los fabricantes de chipsets para proporcionar las especificaciones necesarias para desarrollar controladores de inicialización.
En 2011, Microsoft anunció que las computadoras certificadas para ejecutar su sistema operativo Windows 8 debían enviarse con la clave pública de Microsoft registrada y el arranque seguro habilitado. Tras el anuncio, la empresa fue acusada por críticos y defensores del software libre/código abierto (incluida la Free Software Foundation ) de intentar utilizar la funcionalidad de arranque seguro de UEFI para obstaculizar o impedir por completo la instalación de sistemas operativos alternativos como Linux . Microsoft negó que el requisito de arranque seguro tuviera como objetivo servir como una forma de bloqueo y aclaró sus requisitos al afirmar que los sistemas basados en x86 certificados para Windows 8 deben permitir que el arranque seguro entre en modo personalizado o se deshabilite, pero no en los sistemas. utilizando la arquitectura ARM . [62] [147] Windows 10 permite a los OEM decidir si los usuarios de sus sistemas x86 pueden administrar o no el arranque seguro. [148]
Otros desarrolladores expresaron preocupaciones sobre las cuestiones legales y prácticas de implementar soporte para Secure Boot en sistemas Linux en general. El ex desarrollador de Red Hat, Matthew Garrett, señaló que las condiciones de la Licencia Pública General GNU versión 3 pueden impedir el uso del cargador de arranque unificado GNU GRand sin que el desarrollador de la distribución revele la clave privada (sin embargo, la Free Software Foundation ha aclarado su posición desde entonces, asegurando que la responsabilidad de hacer que las claves estuvieran disponibles recaía en el fabricante del hardware), [149] [107] y que también sería difícil para los usuarios avanzados crear núcleos personalizados que pudieran funcionar con el Arranque seguro habilitado sin autofirmarlos. [147] Otros desarrolladores sugirieron que se podrían proporcionar versiones firmadas de Linux con otra clave, pero señalaron que sería difícil persuadir a los OEM para que enviaran sus computadoras con la clave requerida junto con la clave de Microsoft. [2]
Varias distribuciones importantes de Linux han desarrollado diferentes implementaciones para el arranque seguro. El propio Garrett desarrolló un gestor de arranque mínimo conocido como shim, que es un gestor de arranque firmado y precompilado que permite al usuario confiar individualmente en las claves proporcionadas por las distribuciones de Linux. [150] Ubuntu 12.10 usa una versión anterior de shim [ ¿cuál? ] preconfigurado para usar con la propia clave de Canonical que verifica solo el gestor de arranque y permite cargar núcleos sin firmar; Los desarrolladores creían que la práctica de firmar solo el gestor de arranque es más factible, ya que un kernel confiable es efectivo para proteger solo el espacio del usuario , y no el estado previo al arranque para el cual Secure Boot está diseñado para agregar protección. Esto también permite a los usuarios crear sus propios kernels y utilizar módulos de kernel personalizados , sin la necesidad de reconfigurar el sistema. [107] [151] [152] Canonical también mantiene su propia clave privada para firmar instalaciones de Ubuntu precargadas en computadoras OEM certificadas que ejecutan el sistema operativo, y también planea imponer un requisito de arranque seguro, que requiere tanto un Canonical clave y una clave de Microsoft (por razones de compatibilidad) que se incluirán en su firmware. Fedora también usa shim, [ ¿cuál? ] pero requiere que tanto el kernel como sus módulos también estén firmados. [151]
Se ha discutido si el núcleo del sistema operativo y sus módulos también deben estar firmados; Si bien las especificaciones UEFI no lo requieren, Microsoft ha afirmado que sus requisitos contractuales sí lo requieren y que se reserva el derecho de revocar cualquier certificado utilizado para firmar código que pueda usarse para comprometer la seguridad del sistema. [152] En Windows, si el arranque seguro está habilitado, todos los controladores del kernel deben estar firmados digitalmente; Es posible que se rechace la carga de controladores que no sean WHQL. En febrero de 2013, otro desarrollador de Red Hat intentó enviar un parche al kernel de Linux que le permitiría analizar la firma del código de autenticación de Microsoft utilizando una clave maestra X.509 integrada en archivos PE firmados por Microsoft. Sin embargo, la propuesta fue criticada por el creador de Linux, Linus Torvalds , quien atacó a Red Hat por apoyar el control de Microsoft sobre la infraestructura de Secure Boot. [153]
El 26 de marzo de 2013, el grupo español de desarrollo de software libre Hispalinux presentó una queja formal ante la Comisión Europea , sosteniendo que los requisitos de arranque seguro de Microsoft en sistemas OEM eran "obstructivos" y anticompetitivos . [154]
En la conferencia Black Hat en agosto de 2013, un grupo de investigadores de seguridad presentó una serie de exploits en implementaciones de UEFI de proveedores específicos que podrían usarse para explotar Secure Boot. [155]
En agosto de 2016, se informó que dos investigadores de seguridad habían encontrado la clave de seguridad "llave de oro" que Microsoft utiliza para firmar sistemas operativos. [156] Técnicamente, no se expuso ninguna clave, sin embargo, sí se expuso un binario explotable firmado por la clave. Esto permite que cualquier software se ejecute como si estuviera genuinamente firmado por Microsoft y expone la posibilidad de ataques de rootkits y bootkits . Esto también hace que sea imposible parchear la falla, ya que cualquier parche puede ser reemplazado (degradado) por el binario explotable (firmado). Microsoft respondió en un comunicado que la vulnerabilidad sólo existe en la arquitectura ARM y dispositivos Windows RT , y ha lanzado dos parches; sin embargo, los parches no eliminan (ni pueden) eliminar la vulnerabilidad, lo que requeriría reemplazos de claves en el firmware del usuario final para corregirla. [ cita necesaria ]
El 1 de marzo de 2023, investigadores de la firma de ciberseguridad ESET informaron sobre "El primer kit de arranque UEFI salvaje que pasa por alto el arranque seguro UEFI" llamado 'BlackLotus' en los resultados de sus análisis públicos que describen la teoría detrás de su mecánica que explota los parches que "no ( y no puede) eliminar la vulnerabilidad”. [157] [158]
Muchas distribuciones de Linux ahora admiten UEFI Secure Boot, como RHEL (RHEL 7 y posteriores), CentOS (CentOS 7 y posteriores [159] ), Ubuntu , Fedora , Debian (Debian 10 y posteriores [160] ), OpenSUSE , SUSE Linux . [161]
La creciente importancia del firmware UEFI en los dispositivos también ha provocado una serie de problemas técnicos atribuidos a sus respectivas implementaciones. [162]
Tras el lanzamiento de Windows 8 a finales de 2012, se descubrió que ciertos modelos de computadoras Lenovo con arranque seguro tenían firmware codificado para permitir que solo se cargaran ejecutables llamados " Windows Boot Manager " o " Red Hat Enterprise Linux ", independientemente de cualquier otro. configuración. [163] Varios modelos de portátiles Toshiba con arranque seguro encontraron otros problemas a los que les faltaban ciertos certificados necesarios para su correcto funcionamiento. [162]
En enero de 2013, se publicó un error relacionado con la implementación UEFI en algunas computadoras portátiles Samsung , lo que provocó que se bloquearan después de instalar una distribución de Linux en modo UEFI. Si bien inicialmente se culparon a posibles conflictos con un módulo del kernel diseñado para acceder a las funciones del sistema en las computadoras portátiles Samsung (lo que también llevó a los mantenedores del kernel a desactivar el módulo en los sistemas UEFI como medida de seguridad), Matthew Garrett descubrió que el error en realidad se desencadenó al almacenar demasiados UEFI. variables a la memoria, y que el error también podría activarse en Windows bajo ciertas condiciones. En conclusión, determinó que el módulo del kernel infractor había provocado que se escribieran volcados de mensajes del kernel en el firmware, lo que desencadenó el error. [44] [164] [165]
P: ¿Cuál es la relación entre EFI y UEFI?
R: La especificación UEFI se basa en la especificación EFI 1.10 publicada por Intel con correcciones y cambios administrados por el Unified EFI Forum.
Intel todavía posee los derechos de autor de la especificación EFI 1.10, pero los ha contribuido al Foro para que éste pueda desarrollarlos.
No habrá versiones futuras de la especificación EFI, pero los clientes que obtengan la licencia aún podrán usarla según los términos de su licencia de Intel.
La licencia de la Especificación Unificada EFI proviene del Foro, no de Intel
El sistema de archivos admitido por la interfaz de firmware extensible se basa en el sistema de archivos FAT.
EFI define una versión específica de FAT que está explícitamente documentada y comprobable.
La conformidad con la especificación EFI y sus documentos de referencia asociados es la única definición de FAT que debe implementarse para admitir EFI.
Para diferenciar el sistema de archivos EFI de FAT puro, se ha definido un nuevo tipo de sistema de archivos de partición.
System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby... Las plataformas deben ser UEFI Clase Tres (consulte UEFI Industry Group, Evaluación de UEFI utilizando plataformas y soluciones disponibles comercialmente, versión 0.3, para obtener una definición) sin módulo de soporte de compatibilidad instalado o instalable.
La emulación de BIOS y el arranque de PC/AT heredado deben estar deshabilitados.
Microsoft determinó que los proveedores no tendrían ningún interés en producir firmware UEFI nativo de 32 bits debido al estado actual de los costos de la plataforma y la informática de 64 bits.
Por lo tanto, Microsoft originalmente no incluía soporte para implementaciones UEFI de 32 bits.
