Interfaz de firmware extensible unificada ( UEFI , / ˈjuːɪfaɪ / o como acrónimo) [ c ] es una especificación que define una arquitectura para el firmware de la plataforma utilizada para arrancar el hardware de una computadora y su interfaz para la interacción con el sistema operativo . Algunos ejemplos de firmware que implementan la especificación son AMI Aptio , Phoenix SecureCore , TianoCore EDK II , InsydeH2O .
UEFI reemplaza al BIOS que estaba presente en la ROM de arranque de todas las computadoras personales compatibles con IBM PC , [4] [5] aunque puede proporcionar compatibilidad con versiones anteriores del BIOS mediante el arranque CSM. 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 .
Intel desarrolló la especificación original de la Interfaz de firmware extensible ( EFI ). La última versión de Intel de EFI fue la 1.10, publicada en 2005. Las versiones posteriores fueron desarrolladas como UEFI por el Foro Unificado de EFI .
UEFI es independiente de la plataforma y del lenguaje de programación, pero se utiliza C para la implementación de referencia TianoCore EDKII.
La motivación original para EFI surgió durante el desarrollo temprano 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 , el espacio de memoria direccionable de 1 MB, [6] la programación en lenguaje ensamblador y el hardware PC AT ) se habían vuelto demasiado restrictivas para las plataformas de servidores más grandes a las que apuntaba Itanium. [7] El esfuerzo para abordar estas preocupaciones comenzó en 1998 y inicialmente se llamó Intel Boot Initiative . [8] Más tarde se renombró como Interfaz de firmware extensible (EFI). [9] [10]
La primera implementación UEFI de código abierto , Tiano, fue lanzada por Intel en 2004. Desde entonces, Tiano ha sido reemplazado por EDK [11] y EDK II [12] y ahora es mantenido por la comunidad TianoCore. [13]
En julio de 2005, Intel cesó el desarrollo de la especificación EFI en la versión 1.10 y la contribuyó al Unified EFI Forum , 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 exclusivamente para productos basados en EFI, pero la especificación UEFI es propiedad del UEFI Forum. [7] [14]
La versión 2.0 de la especificación UEFI se publicó el 31 de enero de 2006. Añadió criptografía y seguridad.
La versión 2.1 de la especificación UEFI se publicó el 7 de enero de 2007. Añadió la autenticación de red y la arquitectura de la 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 instalar sistemas operativos e hipervisores genéricos listos para usar 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 el cumplimiento de UEFI, ACPI y SMBIOS . En octubre de 2020, Arm anunció la extensión del programa al mercado de IoT y edge . El nuevo nombre del programa es Arm SystemReady. Arm SystemReady definió la especificación de Requisitos de arranque base (BBR) que actualmente proporciona tres recetas, dos de las cuales están relacionadas con UEFI: 1) SBBR: que requiere el cumplimiento de 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 como se define 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 EDK II utilizada en los productos Microsoft Surface y Hyper-V . El proyecto promueve la idea del firmware como servicio . [15]
La última especificación UEFI, la versión 2.10, se publicó en agosto de 2022. [16]
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 SO y el SO. El firmware UEFI ofrece varias ventajas técnicas sobre un BIOS: [17]
Con UEFI, es posible almacenar claves de producto para sistemas operativos como Windows, en el firmware UEFI del dispositivo. [20] [21] [22] UEFI es necesario para dispositivos que se envían con Windows 8 [23] [24] y superior.
También es posible que los sistemas operativos accedan a los datos de configuración de UEFI. [25]
A partir de la versión 2.5, existen enlaces de procesador para Itanium, x86, x86-64, ARM (AArch32) y ARM64 (AArch64). [26] Solo se pueden admitir procesadores little-endian . [27] Se está desarrollando un soporte UEFI no oficial para POWERPC64 mediante la implementación de TianoCore sobre OPAL, [28] la capa de abstracción OpenPOWER, que se ejecuta en modo little-endian. [29] Existen proyectos similares para MIPS [30] y RISC-V . [31] A partir de UEFI 2.7, se han establecido oficialmente enlaces de procesador RISC-V para modos de 32, 64 y 128 bits. [32]
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 . [7] [33] En comparación, el modo de procesador en un entorno UEFI puede ser de 32 bits ( IA-32 , AArch32) o de 64 bits ( x86-64 , Itanium y AArch64). [7] [34] Las implementaciones de firmware UEFI de 64 bits admiten el modo largo , que permite que las aplicaciones en el entorno de prearranque usen direccionamiento de 64 bits para obtener acceso directo a toda la memoria de la máquina. [35]
UEFI requiere que el firmware y el cargador del sistema operativo (o kernel) coincidan en tamaño; es decir, una implementación de firmware UEFI de 64 bits puede cargar solo un cargador de arranque o kernel de sistema operativo (OS) de 64 bits (a menos que se use el arranque heredado basado en CSM ) y lo mismo se aplica a 32 bits. Después de que el sistema pasa de los servicios de arranque a los servicios de tiempo 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 prohíbe el uso de los servicios de tiempo de ejecución (a menos que el kernel vuelva a cambiar). [36] : secciones 2.3.2 y 2.3.4 A partir de la versión 3.15, el kernel de Linux admite que los kernels de 64 bits se inicien en implementaciones de firmware UEFI de 32 bits que se ejecutan en CPU x86-64 , con soporte de transferencia UEFI desde un cargador de arranque UEFI como requisito. [37] 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 solo el stub de arranque UEFI del kernel de Linux . [38] [39]
Además del esquema de partición de disco estándar de PC que utiliza un registro de arranque maestro (MBR), UEFI también funciona con el esquema de partición GUID Partition Table (GPT), que está libre de muchas de las limitaciones de MBR. En particular, los límites de MBR en el número y tamaño de las particiones de disco (hasta cuatro particiones primarias por disco y hasta 2 TB (2 × 2 40 bytes ) por disco) se relajan. [40] Más específicamente, GPT permite un tamaño máximo de disco y partición de 8 ZiB (8 × 2 70 bytes) . [41] [42]
La compatibilidad con GPT en Linux se habilita activando la opción CONFIG_EFI_PARTITION(Compatibilidad con particiones EFI GUID) durante la configuración del kernel. [43] Esta opción permite que Linux reconozca y use discos GPT después de que el firmware del sistema pasa el control del sistema a Linux.
Para compatibilidad inversa, Linux puede usar discos GPT en sistemas basados en BIOS tanto para almacenamiento de datos como para arranque, ya que tanto GRUB 2 como Linux son compatibles con GPT. Este tipo de configuración se conoce normalmente como BIOS-GPT . [44] [ ¿ fuente no fiable? ] 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 . [42] En el caso de GRUB, esta configuración requiere una partición de arranque BIOS para que GRUB incorpore su código de segunda etapa debido a la ausencia del espacio posterior al MBR en los discos particionados con GPT (que es asumido por el encabezado primario y la tabla de particiones primarias de GPT ). Esta partición, que normalmente tiene un tamaño de 1 MB , tiene un identificador único global (GUID) en el esquema GPT de 21686148-6449-6E6F-744E-656564454649 y GRUB la utiliza solo en configuraciones BIOS-GPT. Desde la perspectiva de GRUB, no existe ese tipo de partición en el caso de particionamiento MBR. Esta partición no es necesaria si el sistema está basado en UEFI porque en ese caso no se necesita incrustar el código de segunda etapa. [18] [42] [44]
Los sistemas UEFI pueden acceder a 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 de sistema EFI (ESP), que contiene aplicaciones UEFI como cargadores de arranque, núcleos del sistema operativo y software de utilidad. [45] [46] [47] [ ¿ fuente poco confiable? ] Esta configuración suele denominarse UEFI-GPT , mientras que se recomienda que ESP tenga un tamaño de al menos 512 MB y esté formateada con un sistema de archivos FAT32 para una máxima compatibilidad. [42] [44] [48] [ ¿ fuente poco confiable? ]
Para compatibilidad con versiones anteriores , algunas implementaciones de UEFI también admiten el arranque desde discos particionados MBR a través del Módulo de soporte de compatibilidad (CSM) que proporciona compatibilidad con BIOS heredados. [49] En ese caso, arrancar Linux en sistemas UEFI es lo mismo que en sistemas basados en BIOS heredados.
Algunas de las prácticas y formatos de datos de EFI reflejan los de Microsoft Windows . [50] [51]
Las versiones de 64 bits de Windows Vista SP1 y posteriores y las versiones de 64 bits de Windows 8 , 8.1 , 10 y 11 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 solo mientras el firmware es propietario de la plataforma (es decir, antes de la ExitBootServices()llamada), e incluyen consolas de texto y gráficas en varios dispositivos, y servicios de bus, bloque y archivo. Los servicios de tiempo de ejecución siguen siendo accesibles mientras el sistema operativo está en ejecución; incluyen servicios como fecha, hora y acceso a NVRAM .
Además 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 que permita seleccionar otra aplicación UEFI para ejecutar. Las utilidades como UEFI Shell también son aplicaciones UEFI.
EFI define los protocolos como un conjunto de interfaces de software utilizadas para la comunicación entre dos módulos binarios. Todos los controladores EFI deben proporcionar 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 dispositivos específicos de la arquitectura del conjunto de instrucciones estándar , EFI proporciona un controlador de dispositivo independiente de ISA almacenado en 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 los ordenadores Apple Macintosh basados en PowerPC y SPARC de Sun Microsystems , entre otros.
Algunos controladores EFI específicos de la arquitectura (código de bytes no EFI) para algunos tipos de dispositivos pueden tener interfaces para que las use el sistema operativo. Esto permite que el sistema operativo dependa de EFI para que los controladores realicen funciones básicas de gráficos y red antes de que se carguen 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. Algunos ejemplos incluyen efifs para 37 sistemas de archivos (basados en código GRUB2 ), [55] utilizados por Rufus para la carga en cadena de ESP NTFS. [56]
La especificación EFI 1.0 definió un protocolo UGA (Universal Graphic Adapter) como una forma de soportar funciones gráficas. UEFI no incluyó UGA y lo reemplazó con GOP (Graphics Output Protocol) . [57]
UEFI 2.1 definió una "Infraestructura de interfaz humana" (HII) para gestionar la entrada del usuario, las cadenas localizadas, las fuentes y los formularios (en el sentido HTML ). Esto permite a los fabricantes de equipos originales (OEM) o a los proveedores independientes de BIOS (IBV) diseñar interfaces gráficas para la configuración previa al arranque. UEFI utiliza UTF-16 para codificar cadenas de forma predeterminada.
La mayoría de las primeras implementaciones de firmware UEFI se basaban en consolas. Hoy en día, muchas implementaciones de firmware UEFI se basan en GUI.
Una partición de sistema EFI, a menudo abreviada como ESP, es una partición de dispositivo de almacenamiento de datos que se utiliza en computadoras que se adhieren a la especificación UEFI. Accede al firmware UEFI cuando se enciende una computadora, almacena aplicaciones UEFI y los archivos que estas aplicaciones necesitan para ejecutarse, incluidos los cargadores de arranque del sistema operativo . Los esquemas de tabla de particiones admitidos incluyen MBR y GPT , así como volúmenes El Torito en discos ópticos. [36] : sección 2.6.2 Para su 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 . [36] : sección 12.3 [58] [59] [60] La ESP también proporciona espacio para un sector de arranque como parte de la compatibilidad con versiones anteriores del BIOS. [49]
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, en función de sus configuraciones, ejecuta el cargador de arranque del SO especificado o el núcleo del sistema operativo (generalmente boot loader [61] ). La configuración de arranque está definida por variables almacenadas en NVRAM , incluidas las variables que indican las rutas del sistema de archivos a los cargadores del SO o los núcleos del SO.
Los cargadores de arranque del SO pueden ser detectados automáticamente por UEFI, lo que permite un arranque sencillo desde dispositivos extraíbles como unidades flash USB . Esta detección automática se basa en rutas de archivo estandarizadas al cargador de arranque del SO, y la ruta varía según la arquitectura de la computadora . El formato de la ruta de archivo se define como <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI ; por ejemplo, la ruta de archivo al cargador del SO en un sistema x86-64 es \efi\boot\bootx64.efi , [36] y \efi\boot\bootaa64.efi en la arquitectura ARM64.
El arranque de sistemas UEFI desde discos particionados con 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, [36] algunas implementaciones de firmware UEFI cambian inmediatamente al arranque CSM basado en BIOS según el tipo de tabla de particiones del disco de arranque, lo que evita de manera efectiva que el arranque UEFI se realice desde la Partición del sistema EFI en discos particionados con MBR. [49] 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 deseado (o utilidad de configuración) de una lista de opciones de arranque disponibles.
Para garantizar la compatibilidad con versiones anteriores, las implementaciones de firmware UEFI en máquinas de clase PC podrían admitir el arranque en modo BIOS heredado desde discos particionados en MBR a través del Módulo de soporte de compatibilidad (CSM) que proporciona compatibilidad con BIOS heredados. En este escenario, el arranque se realiza de la misma manera que en los sistemas basados en BIOS heredados, ignorando la tabla de particiones y confiando en el contenido de un sector de arranque . [49]
El arranque al estilo BIOS desde discos con particiones MBR se denomina comúnmente BIOS-MBR , independientemente de que se realice en sistemas basados en UEFI o BIOS heredados. Además, también es posible arrancar sistemas basados en BIOS heredados desde discos GPT, y este esquema de arranque se denomina comúnmente BIOS-GPT .
El módulo de soporte de compatibilidad permite que los sistemas operativos heredados y algunas ROM de opción heredadas que no son compatibles con UEFI sigan utilizándose. [62] También proporciona la funcionalidad del modo de administración del sistema (SMM) heredada requerida, llamada CompatibilitySmm , como una adición a las características proporcionadas por el SMM UEFI. Un ejemplo de dicha funcionalidad heredada del SMM es proporcionar soporte heredado USB para teclado y mouse, emulando sus contrapartes clásicas PS/2 . [62]
En noviembre de 2017, Intel anunció que planeaba eliminar gradualmente el soporte de CSM para plataformas cliente para 2020. [63]
En julio de 2022, Kaspersky Labs publicó información sobre un rootkit diseñado para arrancar 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. [64]
En agosto de 2023, Intel anunció que planeaba eliminar gradualmente el soporte de CSM para plataformas de servidores para 2024. [65]
A partir de hoy, todas las computadoras basadas en plataformas Intel ya no tienen soporte para CSM.
La especificación UEFI incluye soporte para el arranque a través de la red mediante el entorno de ejecución de prearranque (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 . [36] [66]
Las imágenes del sistema operativo se pueden almacenar de forma remota en redes de área de almacenamiento (SAN), con la Interfaz de sistema de computadora pequeña de Internet (iSCSI) y Canal de fibra sobre Ethernet (FCoE) como protocolos compatibles para acceder a las SAN. [36] [67] [68]
La versión 2.5 de la especificación UEFI agrega soporte para acceder a imágenes de arranque a través de HTTP . [69]
La especificación UEFI define un protocolo conocido como Arranque seguro , que puede asegurar el proceso de arranque al evitar la carga de controladores UEFI o cargadores de arranque del SO que no estén firmados con una firma digital aceptable . Los detalles mecánicos de cómo se firmarán estos controladores no se especifican. [70] Cuando se habilita el Arranque seguro, inicialmente se coloca en modo "configuración", que permite escribir una clave pública conocida como "clave de plataforma" (PK) en el firmware. Una vez que se escribe la clave, el Arranque seguro ingresa al modo "Usuario", donde solo los controladores UEFI y los cargadores de arranque del SO firmados con la clave de plataforma pueden ser cargados por el firmware. Se pueden agregar "claves de intercambio de claves" (KEK) adicionales a una base de datos almacenada en la memoria para permitir que se usen otros certificados, pero aún deben tener una conexión con la parte privada de la clave de plataforma. [71] El Arranque seguro también se puede colocar en modo "Personalizado", donde se pueden agregar claves públicas adicionales al sistema que no coincidan con la clave privada. [72]
Secure Boot 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 [73] y varias distribuciones de Linux , incluidas 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 [74] ), Debian (desde la versión 10), [75] Ubuntu (desde la versión 12.04.2), Linux Mint (desde la versión 21.3), [76] [77] y AlmaLinux OS (desde la versión 8.4 [78] ). A partir de enero de 2024 [actualizar], el soporte de FreeBSD está en una etapa de planificación. [79]
UEFI proporciona un entorno de shell , que se puede utilizar para ejecutar otras aplicaciones UEFI, incluidos los cargadores de arranque UEFI . [47] Aparte de eso, los comandos disponibles en el shell UEFI se pueden utilizar para obtener otra información sobre el sistema o el firmware, incluyendo obtener el mapa de memoria ( memmap), modificar las variables del administrador de arranque ( bcfg), ejecutar programas de particionamiento ( diskpart), cargar controladores UEFI y editar archivos de texto ( edit). [80] [ ¿ fuente no confiable? ] [81] [82]
El código fuente de un shell UEFI se puede descargar del proyecto TianoCore UDK/EDK2 de Intel . [83] También está disponible un ShellBinPkg precompilado. [84] Shell v2 funciona mejor en sistemas UEFI 2.3+ y se recomienda en lugar de Shell v1 en esos sistemas. Shell v1 debería funcionar en todos los sistemas UEFI. [80] [85] [86]
Los métodos utilizados para iniciar el shell UEFI dependen del fabricante y el modelo de la placa base del sistema . Algunos de ellos ya proporcionan una opción directa en la configuración del firmware para el lanzamiento, por ejemplo, la versión x86-64 compilada del shell debe estar disponible como <EFI_SYSTEM_PARTITION>/SHELLX64.EFI. Algunos otros sistemas ya tienen un shell UEFI integrado que se puede iniciar mediante combinaciones de teclas adecuadas. [87] [ ¿ fuente no confiable? ] [88] 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. [82] [87] [89] [ ¿ fuente no confiable? ] [90] [ ¿ fuente no confiable? ]
La siguiente es una lista de comandos compatibles con el shell EFI. [81]
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 de 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 de Firmware a SO, comercializada como moderna y segura. [91] Windows 8 , Windows 8.1 , Windows 10 , [92] y Fwupd para Linux admiten UEFI Capsule.
Al igual que el BIOS , la UEFI inicializa y prueba los componentes de hardware del sistema (por ejemplo, entrenamiento de memoria, entrenamiento de enlace PCIe, entrenamiento de enlace USB en sistemas x86 típicos) 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. [93] [94] En algunos dispositivos Android basados en ARM, el cargador de arranque UEFI se almacena en la memoria flash eUFS .
Las máquinas UEFI pueden tener una de las siguientes clases, que se utilizaron para facilitar la transición a UEFI: [95]
A partir de los procesadores Intel Core de décima generación, Intel ya no ofrece BIOS de video heredados para la iGPU ( tecnología de gráficos Intel ). El arranque heredado con esas CPU requiere un BIOS de video heredados, que aún puede proporcionar una tarjeta de video. [ cita requerida ]
Esta es la primera etapa del arranque UEFI, pero puede tener un código binario específico de la plataforma que la precede (por ejemplo, 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 CPU como RAM, o SRAM en chip SoC, CAR) y funciona 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 que reconoce dependencias y que carga y ejecuta módulos PEI (PEIM) para manejar las tareas de inicialización temprana del hardware, como la inicialización de la memoria principal (inicializar el controlador de memoria y la DRAM ) y las operaciones de recuperación del firmware. Además, es responsable del descubrimiento del modo de arranque actual y de manejar muchas operaciones ACPI S3. En el caso de la reanudación ACPI S3, es responsable de restaurar muchos registros de hardware a un estado previo al reposo. PEI también utiliza CAR. La inicialización en esta etapa implica la creación de estructuras de datos en la memoria y el establecimiento de valores predeterminados dentro de estas estructuras. [97]
Esta etapa consta de módulos C y un despachador que reconoce dependencias. Una vez que la memoria principal está disponible, la CPU, el chipset, la placa base y otros dispositivos de E/S se inicializan en DXE y BDS. La inicialización en esta etapa implica asignar rutas de dispositivos EFI al hardware conectado a la placa base y transferir datos de configuración al hardware. [98]
BDS es parte del DXE. [99] [100] En esta etapa, se inicializan los dispositivos de arranque, se ejecutan los controladores UEFI o las ROM opcionales de los dispositivos PCI según 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 SO. En este punto, se puede ingresar al shell UEFI o ejecutar una aplicación UEFI, como el cargador de arranque del SO.
La UEFI entrega el control al sistema operativo (OS) después de que se ejecuta ExitBootServices() . Un SO compatible con UEFI ahora es responsable de salir de los servicios de arranque, lo que hace que el firmware descargue todo el código y los 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 . [101] Un SO moderno típico preferirá usar sus propios programas (como los controladores del kernel ) para controlar los dispositivos de hardware.
Cuando se utiliza un sistema operativo heredado, CSM manejará esta llamada para garantizar que el sistema sea compatible con las expectativas del BIOS heredado.
La implementación de EFI por parte de Intel es el Intel Platform Innovation Framework , cuyo nombre en código es Tiano . Tiano se ejecuta en los procesadores XScale , Itanium , IA-32 y x86-64 de Intel , y es un 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 . [102]
La implementación de UEFI de Phoenix Technologies se conoce como SecureCore Technology (SCT). [103] American Megatrends ofrece su propia implementación de firmware UEFI conocida como Aptio, [104] mientras que Insyde Software ofrece InsydeH2O, [105] 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 . [106]
En 2017 se introdujo una implementación de la API UEFI en el cargador de arranque universal ( Das U-Boot ). [107] En la arquitectura ARMv8, las distribuciones de Linux utilizan la implementación UEFI de U-Boot junto con GNU GRUB para el arranque (por ejemplo, SUSE Linux [108] ), lo mismo se aplica a OpenBSD. [109] Para arrancar desde iSCSI, se puede utilizar iPXE como una aplicación UEFI cargada por U-Boot. [110]
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; podían arrancar Windows , Linux , FreeBSD y HP-UX ; OpenVMS agregó capacidad UEFI en junio de 2003.
En enero de 2006, Apple Inc. envió sus primeras computadoras Macintosh basadas en Intel . Estos sistemas usaban EFI en lugar de Open Firmware , que se había usado en sus sistemas anteriores basados en PowerPC. [111] 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 requerir una reinstalación de Mac OS X (ahora macOS). También se lanzó una actualización de firmware que agregó compatibilidad con BIOS a su implementación EFI. Los modelos Macintosh posteriores se enviaron con el firmware más nuevo. [112]
Durante 2005, más de un millón de sistemas Intel se entregaron con la implementación de UEFI de Intel. [113] [ verificación fallida ] Nuevos productos móviles, de escritorio y servidores, que utilizan la implementación de UEFI de Intel, comenzaron a entregarse 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 PC, como sistemas integrados basados en núcleos XScale . [113]
El EDK (EFI Developer Kit) incluye un objetivo NT32 que permite ejecutar aplicaciones y firmware EFI dentro de una aplicación de Windows . Sin embargo, el EDK NT32 no permite el acceso directo al hardware. Esto significa que el objetivo 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 arrancar solo los sistemas operativos basados en BIOS a través del módulo de soporte de compatibilidad (CSM) (por lo que no aparecen como basados en UEFI para el usuario), otros sistemas comenzaron a permitir el arranque de sistemas operativos basados en UEFI. Por ejemplo, el servidor IBM x3450, las placas base MSI con ClickBIOS y las 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 informe técnico sobre UEFI se mencionan más sistemas disponibles comercialmente. [114]
En 2011, los principales proveedores (como ASRock , Asus , Gigabyte y MSI ) lanzaron varias placas base orientadas al consumidor que utilizaban el chipset Intel serie 6 LGA 1155 y los chipsets AMD serie 9 AM3+ con UEFI. [115]
Con el lanzamiento de Windows 8 en octubre de 2012, los requisitos de certificación de Microsoft ahora requieren que las computadoras incluyan firmware que implemente la especificación UEFI. Además, si la computadora admite la función " Connected Standby " 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 retorno casi instantáneo del modo de espera), entonces el firmware no puede contener un Módulo de soporte de compatibilidad (CSM). Como tal, los sistemas que admiten Connected Standby son incapaces de arrancar sistemas operativos Legacy BIOS. [116] [117]
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. [118] Para 2019, todas las computadoras basadas en plataformas Intel ya no tendrán compatibilidad con BIOS de PC heredados.
Un sistema operativo que se puede iniciar desde una (U)EFI se denomina sistema operativo compatible con (U)EFI, definido por la especificación (U)EFI. Aquí, el término " iniciado desde una (U)EFI" significa iniciar directamente el sistema utilizando un cargador de 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>.EFI, donde el nombre corto del tipo de máquina puede ser IA32, X64, o . [36]IA64 Algunos proveedores de sistemas operativos pueden tener sus propios cargadores de arranque. También pueden cambiar la ubicación de arranque predeterminada.ARMAA64
El kit de desarrollo de aplicaciones EDK2 (EADK) permite utilizar funciones de la biblioteca C estándar en aplicaciones UEFI. El EADK se puede descargar de forma gratuita desde el proyecto TianoCore UDK/EDK2 SourceForge de Intel . Como ejemplo, se ha puesto a disposición un puerto del intérprete de Python como aplicación UEFI mediante el uso del EADK. [156] El desarrollo se ha trasladado a GitHub desde UDK2015. [157]
Un programa minimalista " Hola mundo " en C escrito con EADK parece similar a su contraparte habitual en C :
#include <Uefi.h> #include <Biblioteca/UefiLib.h> #include <Biblioteca/ShellCEntryLib.h> EFI_STATUS EFIAPI ShellAppMain ( IN UINTN Argc , IN 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 , un activista de derechos digitales, han criticado la UEFI como un intento de eliminar la capacidad del usuario de controlar realmente la computadora. [158] [159] 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. [160]
El proyecto de código abierto TianoCore también proporciona UEFI. [161] TianoCore carece de los controladores especializados que inicializan las funciones del chipset, que en su lugar 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 los controladores de inicialización.
En 2011, Microsoft anunció que las computadoras certificadas para ejecutar su sistema operativo Windows 8 tenían que enviarse con la clave pública de Microsoft registrada y el Arranque Seguro habilitado, lo que implica que el uso de UEFI es un requisito para estos dispositivos. [162] [163] Después del anuncio, la compañía fue acusada por críticos y defensores del software libre/código abierto (incluida la Free Software Foundation ) de intentar usar la funcionalidad de Arranque Seguro de UEFI para obstaculizar o prevenir directamente la instalación de sistemas operativos alternativos como Linux . Microsoft negó que el requisito de Arranque Seguro estuviera destinado a servir como una forma de encierro , y aclaró sus requisitos al afirmar que los sistemas basados en x86 certificados para Windows 8 deben permitir que el Arranque Seguro ingrese al modo personalizado o se deshabilite, pero no en sistemas que usen la arquitectura ARM . [72] [164] Windows 10 permite a los OEM decidir si los usuarios de sus sistemas x86 pueden administrar o no el Arranque Seguro. [165]
Otros desarrolladores expresaron su preocupación por los problemas legales y prácticos de implementar el 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 una distribución revele la clave privada (sin embargo, la Free Software Foundation ha aclarado su posición desde entonces, asegurando que la responsabilidad de poner a disposición las claves recae en el fabricante del hardware), [166] [121] y que también sería difícil para los usuarios avanzados crear núcleos personalizados que pudieran funcionar con Secure Boot habilitado sin autofirmarlos. [164] Otros desarrolladores sugirieron que se podrían proporcionar compilaciones firmadas de Linux con otra clave, pero señalaron que sería difícil persuadir a los OEM para que envíen sus computadoras con la clave requerida junto con la clave de Microsoft. [5]
Varias distribuciones Linux importantes han desarrollado diferentes implementaciones para Secure Boot. El propio Garrett desarrolló un cargador de arranque mínimo conocido como shim, que es un cargador de arranque precompilado y firmado que permite al usuario confiar individualmente en las claves proporcionadas por las distribuciones Linux. [167] Ubuntu 12.10 utiliza una versión anterior de shim [ ¿cuál? ] preconfigurada para su uso con la propia clave de Canonical que verifica solo el cargador de arranque y permite cargar núcleos no firmados; los desarrolladores creyeron que la práctica de firmar solo el cargador de arranque es más factible, ya que un núcleo confiable es efectivo para asegurar solo el espacio del usuario , y no el estado previo al arranque para el que Secure Boot está diseñado para agregar protección. Eso también permite a los usuarios construir sus propios núcleos y usar módulos de núcleo personalizados también, sin la necesidad de reconfigurar el sistema. [121] [168] [169] 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 aplicar un requisito de arranque seguro, exigiendo que se incluyan en su firmware tanto una clave de Canonical como una de Microsoft (por razones de compatibilidad). Fedora también usa shim, [¿ cuál? ] pero requiere que tanto el núcleo como sus módulos también estén firmados. [168]
Se ha debatido si el núcleo del sistema operativo y sus módulos también deben estar firmados; aunque 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. [169] En Windows, si se habilita el Arranque seguro, todos los controladores del núcleo deben estar firmados digitalmente; se puede rechazar la carga de los controladores que no sean WHQL. En febrero de 2013, otro desarrollador de Red Hat intentó enviar un parche al núcleo de Linux que le permitiría analizar la firma authenticode de Microsoft utilizando una clave maestra X.509 incrustada 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 Arranque seguro. [170]
El 26 de marzo de 2013, el grupo de desarrollo de software libre español Hispalinux presentó una queja formal ante la Comisión Europea , alegando que los requisitos de arranque seguro de Microsoft en los sistemas OEM eran "obstructivos" y anticompetitivos . [171]
En la conferencia Black Hat de 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 el Arranque Seguro. [172]
En agosto de 2016 se informó que dos investigadores de seguridad habían encontrado la clave de seguridad "golden key" que Microsoft utiliza para firmar sistemas operativos. [173] Técnicamente, no se expuso ninguna clave, sin embargo, 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 rootkit y bootkit . Esto también hace que sea imposible parchar la falla, ya que cualquier parche puede ser reemplazado (degradado) por el binario explotable (firmado). Microsoft respondió en una declaración que la vulnerabilidad solo existe en la arquitectura ARM y los dispositivos Windows RT , y ha lanzado dos parches; sin embargo, los parches no eliminan (y no pueden) la vulnerabilidad, lo que requeriría reemplazos de claves en el firmware del usuario final para solucionarlo. [ cita requerida ]
El 1 de marzo de 2023, los investigadores de la empresa de ciberseguridad ESET informaron sobre “el primer bootkit UEFI activo que elude 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 eliminan (y no pueden eliminar) la vulnerabilidad”. [174] [175]
En agosto de 2024, las actualizaciones de seguridad de Windows 11 y Windows 10 aplicaron la configuración de Secure Boot Advanced Targeting (SBAT) a la NVRAM UEFI del dispositivo, lo que puede provocar que algunas distribuciones de Linux no se carguen. SBAT es un protocolo compatible con las nuevas versiones de Windows Boot Manager y shim, que impiden que los gestores de arranque intermedios con errores o vulnerabilidades (normalmente winload.efi y GRUB ) se carguen en el proceso de arranque. [176]
Muchas distribuciones de Linux ahora admiten el arranque seguro UEFI, como RHEL (RHEL 7 y posteriores), CentOS (CentOS 7 y posteriores [177] ), Ubuntu , Fedora , Debian (Debian 10 y posteriores [178] ), OpenSUSE y SUSE Linux . [179]
La creciente importancia del firmware UEFI en los dispositivos también ha dado lugar a una serie de problemas técnicos atribuidos a sus respectivas implementaciones. [180]
Tras el lanzamiento de Windows 8 a finales de 2012, se descubrió que ciertos modelos de ordenadores Lenovo con arranque seguro tenían un firmware codificado para permitir que solo se cargaran ejecutables llamados " Windows Boot Manager " o " Red Hat Enterprise Linux ", independientemente de cualquier otra configuración. [181] Otros problemas se encontraron con varios modelos de portátiles Toshiba con arranque seguro a los que les faltaban ciertos certificados necesarios para su correcto funcionamiento. [180]
En enero de 2013, se hizo público un error relacionado con la implementación de UEFI en algunas computadoras portátiles Samsung , que provocó que se bloquearan después de instalar una distribución Linux en modo UEFI. Si bien inicialmente se atribuyó la culpa a posibles conflictos con un módulo del núcleo diseñado para acceder a las funciones del sistema en las computadoras portátiles Samsung (lo que también llevó a los encargados del mantenimiento del núcleo a deshabilitar el módulo en los sistemas UEFI como medida de seguridad), Matthew Garrett descubrió que el error en realidad se desencadenaba al almacenar demasiadas variables UEFI en la memoria, y que el error también podía desencadenarse en Windows bajo ciertas condiciones. En conclusión, determinó que el módulo del núcleo ofensivo había provocado que se escribieran volcados de mensajes del núcleo en el firmware, lo que desencadenó el error. [53] [182] [183]
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 Foro EFI Unificado. Intel aún posee los derechos de autor sobre la especificación EFI 1.10, pero la ha aportado al Foro para que este pueda desarrollarla. No habrá versiones futuras de la especificación EFI, pero los clientes que la obtengan bajo licencia aún pueden usarla bajo los términos de su licencia de Intel. La licencia de la Especificación EFI Unificada proviene del Foro, no de Intel.
{{cite report}}: CS1 maint: estado de la URL ( enlace )El sistema de archivos compatible con 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 se puede probar. La conformidad con la especificación EFI y sus documentos de referencia asociados es la única definición de FAT que se debe implementar 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 mediante plataformas y soluciones disponibles comercialmente, versión 0.3, para obtener una definición) sin ningún 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 la informática de 64 bits y los costos de la plataforma. Por lo tanto, Microsoft originalmente no ofreció compatibilidad con implementaciones UEFI de 32 bits.
