UEFI

UEFI admite arquitecturas de procesador de 32 bits o superiores. Sin embargo, solo se admiten procesadores con modo little-endian . ^{[ 13 ] : sección 1.9.1} La especificación UEFI, versión 2.11, tiene documentación oficial para las siguientes arquitecturas de procesador: ^{[ 13 ] : sección 3.5.1.1}

• x86 ( IA-32 , x86-64 )
• Itanium ( IA-64 )
• ARM ( AArch32 , AArch64 )
• RISC-V (32 bits, 64 bits, 128 bits)
• LoongArch (32 bits, 64 bits)

Se está desarrollando soporte UEFI no oficial para POWERPC64 mediante la implementación de TianoCore EDK II sobre OPAL, ^{[ 14 ]} la capa de abstracción OpenPOWER, que se ejecuta en modo little-endian. ^{[ 15 ]} Para MIPS , también existe un proyecto no oficial, basado en el EDK original. ^{[ 16 ] [ 17 ]} Sin embargo, ambos proyectos fueron abandonados en noviembre de 2016 y septiembre de 2015, respectivamente.

UEFI solo permite ejecutar aplicaciones UEFI que coincidan con la arquitectura del firmware, incluso si el procesador admite arquitecturas más pequeñas o más grandes. Por ejemplo, un firmware UEFI de 64 bits solo puede ejecutar aplicaciones UEFI de 64 bits, incluso si el procesador tiene un modo de procesador de 32 bits. ^{[ 13 ] : secciones 2.3.2 y 2.3.4} Algunos ordenadores de gama baja se han distribuido con firmware UEFI de 32 bits ejecutándose en CPU de 64 bits. ^{[ 18 ]} Una vez que una aplicación UEFI finaliza los servicios de arranque y obtiene el control total del sistema, es posible cambiar el modo de ejecución del procesador. ^{[ 13 ] : secciones 2.3.2 y 2.3.4} Sin embargo, llamar a los servicios de tiempo de ejecución requiere volver brevemente al modo de procesador original, ^{[ 19 ]} ya que los servicios de tiempo de ejecución solo se pueden llamar desde el mismo modo de procesador que la implementación del firmware. ^{[ 13 ] : secciones 2.3.2 y 2.3.4}

El kernel de Linux agregó soporte para arrancar kernels de 64 bits en implementaciones de firmware UEFI de 32 bits con CPU x86-64 desde la versión 3.15, lo que requiere que el cargador de arranque UEFI admita el protocolo de transferencia EFI. ^{[ 20 ]} El protocolo de transferencia EFI permite que los cargadores de arranque UEFI difieran la inicialización UEFI al stub de arranque EFI del kernel, de modo que solo el kernel realiza la inicialización UEFI. ^{[ 21 ] [ 22 ] [ 23 ]}

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 de tabla de partición GUID (GPT), que está libre de muchas de las limitaciones de MBR . En particular, se relajan los límites de MBR en cuanto al número y tamaño de las particiones de disco (hasta cuatro particiones primarias por disco y hasta 2 TB (2 × 2 ⁴⁰ bytes ) por disco). Más específicamente, GPT permite un tamaño máximo de disco y partición de 8 ZiB (8 × 2 ⁷⁰ bytes) con sectores de 512 bytes. ^{[ 24 ]} La especificación UEFI solo admite particiones FAT12 / 16 / 32 ^{[ 13 ] : sección 13.3} que se encuentran en discos GPT o MBR, así como discos ópticos formateados en El Torito . ^{[ 13 ] : sección 13.3.2} Aunque GPT es parte del estándar UEFI, también puede ser utilizado por PCs con BIOS para arrancar un sistema operativo. ^{[ 24 ] [ 25 ]}  

EFI define dos tipos de servicios: servicios de arranque y servicios de tiempo de ejecución . Los servicios de arranque solo están disponibles mientras el firmware controla la plataforma (es decir, antes de la ExitBootServices()llamada) e incluyen consolas de texto y gráficas en diversos dispositivos, así como servicios de bus, bloques y archivos. Los servicios de tiempo de ejecución siguen estando accesibles mientras el sistema operativo está en funcionamiento; incluyen servicios como el acceso a la fecha, la hora y la NVRAM .

Servicios del Protocolo de Salida Gráfica (GOP)

El Protocolo de Salida Gráfica (GOP) proporciona servicios en tiempo de ejecución; véase también la sección de características gráficas más abajo. El sistema operativo puede escribir directamente en el framebuffer y realizar la transferencia de bits proporcionada por GOP durante el modo de ejecución. ^{[ 29 ]}

Servicios de mapeo de memoria UEFI

Servicios de marketing en redes sociales

Servicios ACPI

Servicios SMBIOS

Servicios Devicetree (para procesadores RISC)

Servicios variables

Las variables UEFI proporcionan una forma de almacenar datos, en particular datos no volátiles. Algunas variables UEFI se comparten entre el firmware de la plataforma y los sistemas operativos. Los espacios de nombres de las variables se identifican mediante GUID, y las variables son pares clave/valor. Por ejemplo, las variables UEFI se pueden usar para guardar mensajes de fallo en la NVRAM después de un fallo, para que el sistema operativo los recupere después de un reinicio. ^{[ 30 ]}

Servicios de tiempo

UEFI proporciona servicios de tiempo. Los servicios de tiempo incluyen soporte para campos de zona horaria y horario de verano, que permiten que el reloj de tiempo real del hardware se configure a la hora local o UTC. ^{[ 13 ] : sección 8.3} En máquinas que utilizan un reloj de tiempo real PC-AT, por defecto el reloj de hardware todavía tiene que estar configurado a la hora local para compatibilidad con Windows basado en BIOS, ^{[ 31 ]} a menos que se utilicen versiones recientes y se haya configurado una entrada en el registro de Windows para indicar el uso de UTC.

Interacción entre el gestor de arranque EFI y los controladores EFI

UEFI ejecuta programas independientes conocidos como aplicaciones UEFI, que se almacenan como archivos en la partición del sistema EFI. Estas se pueden iniciar a través de la consola UEFI, el gestor de arranque del firmware u otras aplicaciones UEFI, y pueden desarrollarse independientemente del fabricante del equipo original (OEM).

Un tipo de aplicación UEFI es un gestor de arranque del sistema operativo, como GRUB , rEFInd , systemd-boot y el Administrador de arranque de Windows , que carga archivos del sistema operativo en la memoria y los ejecuta. Además, un gestor de arranque del sistema operativo puede proporcionar una interfaz de usuario para seleccionar otra aplicación UEFI que se ejecutará. Utilidades como la consola UEFI 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 de la BIOS .

Además de los controladores de dispositivo específicos de la arquitectura del conjunto de instrucciones estándar ( ISA), EFI proporciona un controlador de dispositivo independiente de la ISA almacenado en memoria no volátil como código de bytes EFI o EBC . El firmware del sistema cuenta con un intérprete para imágenes EBC. En ese sentido, EBC es análogo a Open Firmware , el firmware independiente de la ISA utilizado en los ordenadores Apple Macintosh basados ​​en PowerPC y Sun Microsystems SPARC , entre otros.

Algunos controladores EFI específicos de la arquitectura (sin código de bytes EFI) para ciertos tipos de dispositivos pueden tener interfaces que el sistema operativo puede utilizar. 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, si es que se cargan.

En otros casos, el controlador EFI puede ser un controlador de sistema de archivos que permite arrancar desde otros tipos de volúmenes de disco. Algunos ejemplos incluyen efifs para 37 sistemas de archivos (basados ​​en el código GRUB2 ), ^{[ 32 ]} utilizados por Rufus para la carga en cadena de ESP NTFS. ^{[ 33 ]}

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 Gráfica) . ^{[ 34 ]}

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; desde al menos UEFI 2.4, permite usar ASCII para codificar cadenas que solo contienen caracteres ASCII.

La mayoría de las primeras implementaciones de firmware UEFI se basaban en la consola. Hoy en día, muchas implementaciones de firmware UEFI se basan en la interfaz gráfica de usuario (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 se adhieren a la especificación UEFI. Accedida por el 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 partición compatibles incluyen MBR y GPT , así como volúmenes El Torito en discos ópticos. ^{[ 13 ] : 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, abarcando los sistemas de archivos FAT32 , FAT16 y FAT12 . ^{[ 13 ] : sección 13.3 [ 35 ]} La ESP también proporciona espacio para un sector de arranque como parte de la compatibilidad retroactiva de BIOS.

Los ordenadores se inician mediante un proceso denominado arranque : el ordenador carga su software operativo mediante un programa muy pequeño integrado en el hardware, que normalmente carga otro programa, también pequeño, para cargar e iniciar el sistema operativo (SO).

arranque UEFI

A diferencia de la BIOS tradicional de los PC, UEFI no depende de sectores de arranque en el almacenamiento de datos del equipo, sino que define un gestor de arranque como parte de la especificación UEFI. Al encender el equipo, el gestor de arranque comprueba la configuración de arranque y, en función de ella, ejecuta el cargador de arranque o el núcleo del sistema operativo especificado . La configuración de arranque se define mediante variables almacenadas en la memoria NVRAM persistente del equipo , incluidas variables que indican las rutas del sistema de archivos a los cargadores o núcleos del sistema operativo.

Los cargadores de arranque del sistema operativo pueden ser detectados automáticamente por UEFI, lo que permite un arranque sencillo desde dispositivos extraíbles como unidades flash USB . Esta detección automatizada se basa en rutas de archivo estandarizadas al cargador de arranque del sistema operativo, y la ruta varía según la arquitectura del ordenador . El formato de la ruta de archivo se define como <PARTICIÓN_DEL_SISTEMA_EFI>\EFI\BOOT\BOOT<NOMBRE_CORTO_DEL_TIPO_DE_MÁQUINA>.EFI ; por ejemplo, la ruta de archivo al cargador del sistema operativo en un sistema x86-64 es \efi\boot\bootx64.efi , ^{[ 13 ] : sección 3.5.1.1} 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 , aunque la especificación UEFI requiere que las tablas de partición MBR sean totalmente compatibles. ^{[ 13 ] : sección 13.3.2} Algunas implementaciones de firmware UEFI cambian inmediatamente al arranque CSM basado en BIOS dependiendo del tipo de tabla de partición del disco de arranque, lo que impide efectivamente el arranque UEFI desde una partición del sistema EFI en discos particionados con MBR; este esquema de arranque se denomina comúnmente UEFI-MBR .

También es habitual que un gestor de arranque disponga de una interfaz de usuario textual que permita al usuario seleccionar el sistema operativo (o la utilidad de configuración) deseado de una lista de opciones de arranque disponibles.

En las plataformas de PC, el firmware que admite el arranque UEFI se suele denominar "UEFI BIOS", aunque algunas plataformas x86 más recientes excluyen por completo la compatibilidad con CSM.

Arranque seguro

La especificación UEFI define un Arranque Seguro que protege 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 . Cuando se habilita el Arranque Seguro, 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, el Arranque Seguro entra en modo "Usuario", donde solo los controladores UEFI y los cargadores de arranque del sistema operativo 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 memoria para permitir el uso de otros certificados, pero estos deben seguir estando conectados a la parte privada de la clave de plataforma. ^{[ 44 ]} El Arranque Seguro también puede colocarse en modo "Personalizado", donde se pueden agregar claves públicas adicionales al sistema que no coincidan con la clave privada. ^{[ 45 ]}

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 ^{[ 46 ]} 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 ^{[ 47 ]} ), Debian (desde la versión 10) ^{[ 48 ]} , Ubuntu (desde la versión 12.04.2), Linux Mint (desde la versión 21.3) ^{[ 49 ] [ 50 ]} y AlmaLinux OS (desde la versión 8.4 ^{[ 51 ]} ). A partir de enero de 2025 , el soporte para FreeBSD está en su etapa de planificación. ^{[ 52 ]}

UEFI proporciona un entorno de shell que se puede usar para ejecutar otras aplicaciones UEFI, incluidos los cargadores de arranque UEFI . Además, los comandos disponibles en el shell UEFI se pueden usar para obtener diversa información sobre el sistema o el firmware, incluyendo obtener el mapa de memoria ( ), modificar variables del administrador de arranque ( ), ejecutar programas de particionamiento ( ), cargar controladores UEFI y editar archivos de texto ( ). ^{[ 53 ] [ 54 ]}memmapbcfgdiskpartedit

El código fuente para un shell UEFI se puede descargar del proyecto TianoCore UDK/EDK2 de Intel . ^{[ 55 ]} También está disponible un ShellBinPkg precompilado. ^{[ 56 ]} 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. ^{[ 57 ] [ 58 ]}

Los métodos utilizados para iniciar el shell UEFI dependen del fabricante y modelo de la placa base del sistema . Algunos ya proporcionan una opción directa en la configuración del firmware para iniciarlo, por ejemplo, la versión compilada x86-64 del shell debe estar disponible como <EFI_SYSTEM_PARTITION>/SHELLX64.EFI. Otros sistemas tienen un shell UEFI ya integrado que se puede iniciar mediante combinaciones de teclas apropiadas. ^{[ 59 ]} Para otros sistemas, la solución es crear una unidad flash USB apropiada o agregar manualmente ( bcfg) una opción de arranque asociada con la versión compilada del shell. ^{[ 54 ]}

Las extensiones de UEFI se pueden cargar desde prácticamente cualquier dispositivo de almacenamiento no volátil conectado al ordenador. Por ejemplo, un fabricante de equipos originales (OEM) puede distribuir sistemas con una partición de sistema EFI en el disco duro, lo que añadirí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 firmware del sistema operativo. ^{[ 60 ]} Windows 8 , Windows 8.1 , Windows 10 , ^{[ 61 ]} y Fwupd para Linux son compatibles con UEFI Capsule.

Al igual que BIOS , UEFI inicializa y prueba los componentes de hardware del sistema y luego carga el cargador de arranque desde un dispositivo de almacenamiento masivo o a través de una conexión de red . En los sistemas x86 , el firmware UEFI generalmente se almacena en el chip de memoria flash NOR de la placa base, y el proceso de arranque es más complejo, por ejemplo, la detección e inicialización de dispositivos PCI Express . ^{[ 62 ] [ 63 ]} En algunos dispositivos Android y Windows Phone basados ​​en ARM, el cargador de arranque UEFI se almacena en la memoria flash eMMC o eUFS .

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 (CAR) o procesador de arranque integrado en el SoC ) y actúa como raíz de confianza del software del sistema, con la opción de verificar el PEI antes de la transferencia.

La segunda etapa del arranque UEFI consiste en un despachador que tiene en cuenta las dependencias y que carga y ejecuta módulos PEI (PEIM) para gestionar las tareas iniciales de inicialización del hardware, como la inicialización de la memoria principal (inicialización del controlador de memoria y la DRAM ) y las operaciones de recuperación del firmware. Además, es responsable de la detección del modo de arranque actual y de la gestión de numerosas operaciones ACPI S3. En el caso de la reanudación ACPI S3, es responsable de restaurar muchos registros de hardware a un estado anterior al modo de suspensión. 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. ^{[ 2 ]}

Esta etapa consta de varios componentes, entre ellos la base PEI, PEIMs y PPI. Debido a la escasez de recursos disponibles, esta etapa debe ser mínima y realizar preparativos mínimos para la siguiente etapa, DXE, que es más completa.

Esta etapa consta de módulos C y un despachador que tiene en cuenta las dependencias. Con la memoria principal ya 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. ^{[ 2 ]}

BDS es parte de DXE. ^{[ 66 ] [ 67 ]} En esta etapa, se inicializan los dispositivos de arranque, se ejecutan los controladores UEFI o las ROM de opción de los dispositivos PCI de acuerdo con las variables definidas arquitectónicamente llamadas NVRAM , y se inician los cargadores de arranque del sistema operativo (como el Administrador de arranque de Windows ).

Esta es la etapa entre la selección del dispositivo de arranque y la transferencia al sistema operativo. En este punto, se puede acceder a una consola UEFI o ejecutar una aplicación UEFI, como el gestor de arranque del sistema operativo.

La UEFI transfiere el control al sistema operativo (SO) después de que se ejecuta ExitBootServices() . Un SO compatible con UEFI ahora es responsable de salir de los servicios de arranque, lo que activa el firmware para descargar todo el código y los datos que ya no se necesitan, dejando solo el código/datos de los servicios de tiempo de ejecución, por ejemplo, SMM y ACPI . ^{[ 68 ]} 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 se encargará de esta llamada, garantizando que el sistema sea compatible con las expectativas del BIOS heredado.

La implementación de EFI de Intel es el Intel Platform Innovation Framework , con nombre en clave Tiano . Tiano se ejecuta en los procesadores XScale , Itanium , IA-32 y x86-64 de Intel , y es software propietario, aunque una parte del código se ha publicado bajo la licencia BSD o la Licencia Pública de Eclipse (EPL) como TianoCore EDK II . TianoCore se puede utilizar como carga útil para coreboot . ^{[ 69 ]}

La implementación de UEFI de Phoenix Technologies se denomina SecureCore Technology (SCT). ^{[ 70 ]} American Megatrends ofrece su propia implementación de firmware UEFI conocida como Aptio, ^{[ 71 ]} mientras que Insyde Software ofrece InsydeH2O, ^{[ 72 ]} 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 . ^{[ 73 ]}

En 2017 se introdujo una implementación de la API UEFI en el cargador de arranque universal ( Das U-Boot ). ^{[ 74 ]} 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 ^{[ 75 ]} ), lo mismo ocurre con OpenBSD. ^{[ 76 ]} Para arrancar desde iSCSI , se puede utilizar iPXE como una aplicación UEFI cargada por U-Boot. ^{[ 77 ]}

Las primeras estaciones de trabajo y servidores Itanium de Intel , lanzados en el año 2000, implementaron EFI 1.02.

Los primeros sistemas Itanium 2 de Hewlett-Packard , lanzados en 2002, implementaban EFI 1.10. Estos sistemas podían arrancar Windows , Linux , FreeBSD y HP-UX . OpenVMS añadió la capacidad UEFI en junio de 2003.

En enero de 2006, Apple Inc. lanzó sus primeras computadoras Macintosh con procesador Intel . Estos sistemas utilizaban EFI en lugar de Open Firmware , que se había utilizado en sus sistemas anteriores basados ​​en PowerPC. ^{[ 78 ]} El 5 de abril de 2006, Apple lanzó Boot Camp , que genera un disco de controladores de Windows y una herramienta de particionamiento 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 con BIOS a su implementación de EFI. Los modelos Macintosh posteriores se lanzaron con el firmware más reciente. ^{[ 79 ]}

Durante 2005, se enviaron más de un millón de sistemas Intel con la implementación de UEFI de Intel. ^{[ 80 ]} En 2006, comenzaron a enviarse nuevos productos móviles, de escritorio y de servidor que utilizaban la implementación de UEFI de Intel. 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 embebidos basados ​​en núcleos XScale . ^{[ 80 ]}

El EDK (EFI Developer Kit) incluye un objetivo NT32, que permite ejecutar firmware y aplicaciones EFI dentro de una aplicación de Windows . Sin embargo, el EDK NT32 no permite el acceso directo al hardware. Esto significa que solo un subconjunto de las aplicaciones y controladores EFI puede ejecutarse en el objetivo EDK NT32.

En 2008, más sistemas x86-64 adoptaron UEFI. Si bien muchos de estos sistemas aún permiten arrancar únicamente los sistemas operativos basados ​​en BIOS mediante el Módulo de Compatibilidad (CSM) (por lo que no parecen ser 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 los portátiles HP EliteBook.

En 2009, IBM lanzó al mercado máquinas System x (x3550 M2, x3650 M2, iDataPlex dx360 M2) y BladeCenter HS22 con capacidad UEFI. Dell lanzó servidores PowerEdge T610, R610, R710, M610 y M710 con capacidad UEFI. En un documento técnico sobre UEFI se mencionan otros sistemas disponibles comercialmente. ^{[ 81 ]}

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. ^{[ 82 ]}

Con el lanzamiento de Windows 8 en octubre de 2012, los requisitos de certificación de Microsoft ahora exigen que los equipos incluyan firmware que implemente la especificación UEFI. Además, si el equipo 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 Compatibilidad (CSM). Por lo tanto, los sistemas que admiten Connected Standby no pueden arrancar sistemas operativos BIOS heredados. ^{[ 83 ] [ 84 ]}

En octubre de 2017, Intel anunció que eliminaría la compatibilidad con BIOS de PC heredada de todos sus productos para 2020, en favor de UEFI Clase 3. ^{[ 85 ]} Para 2019, todos los ordenadores basados ​​en plataformas Intel ya no tienen compatibilidad con BIOS de PC heredada.

Un sistema operativo que puede arrancar desde (U)EFI se llama sistema operativo compatible con (U)EFI, definido por la especificación (U)EFI. Aquí, el término arrancar desde un (U)EFI significa arrancar directamente el sistema usando 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, IA64, ARMo AA64. ^{[ 13 ] : sección 3.5.1.1} Algunos proveedores de sistemas operativos pueden tener sus propios cargadores de arranque. También pueden cambiar la ubicación de arranque predeterminada.

• El kernel de Linux ha podido usar EFI en el momento del arranque desde principios de la década de 2000, ^{[ 86 ]} usando el cargador de arranque EFI elilo y, más recientemente, versiones EFI de GRUB ^{[ 87 ]} o systemd-boot . Grub+Linux también admite el arranque desde una tabla de particiones GUID sin UEFI. ^{[ 25 ]} La distribución Ubuntu agregó soporte para UEFI Secure Boot a partir de la versión 12.10. ^{[ 88 ]} El kernel de Linux se puede compilar con la opción de ejecutarse como un cargador de arranque EFI por sí mismo a través de la función EFI boot stub. En el kernel de Linux, se puede usar con UEFI tanto el protocolo ACPI (generalmente usado en máquinas compatibles con PC) como el protocolo DeviceTree (generalmente usado en teléfonos inteligentes y tabletas). ^{[ 89 ]}
• HP-UX utiliza (U)EFI como mecanismo de arranque en sistemas IA-64 desde 2002.
• OpenVMS ha utilizado EFI en IA-64 desde su lanzamiento inicial de evaluación en diciembre de 2003, y para lanzamientos de producción desde enero de 2005. ^{[ 90 ]} OpenVMS en x86-64 también utiliza UEFI para arrancar el sistema operativo. ^{[ 91 ]}
• Apple utiliza EFI para su línea de Macs basadas en Intel . Mac OS X v10.4 Tiger y Mac OS X v10.5 Leopard implementan EFI v1.10 en modo de 32 bits incluso en CPUs de 64 bits, pero la compatibilidad total llegó con OS X v10.8 Mountain Lion . ^{[ 92 ]}
• Las versiones Itanium de Windows 2000 (Advanced Server Limited Edition y Datacenter Server Limited Edition; basadas en el código fuente de la versión preliminar de Windows Server 2003 ) implementaron EFI 1.10 en 2002. Windows XP 64-bit Edition , Windows 2000 Advanced Server Limited Edition (versión preliminar de Windows Server 2003) y Windows Server 2003 para IA-64 , todos ellos para la familia de procesadores Intel Itanium , implementan EFI, un requisito de la plataforma según la especificación DIG64 . ^{[ 93 ]}
• Microsoft introdujo UEFI para sistemas operativos Windows x64 con Windows Vista SP1 ^{[ 94 ]} y Windows Server 2008, sin embargo, solo se admite UGA (Adaptador Gráfico Universal) 1.1 o Legacy BIOS INT 10h ; el Protocolo de Salida de Gráficos (GOP) no es compatible. Por lo tanto, las PC que ejecutan versiones de 64 bits de Windows Vista SP1 , Windows Vista SP2 , Windows 7 , Windows Server 2008 y Windows Server 2008 R2 son compatibles con UEFI Clase 2. ^{[ 95 ] [ 96 ]} UEFI de 32 bits no era compatible originalmente ya que los proveedores no tenían ningún interés en producir firmware UEFI nativo de 32 bits debido al estado dominante de la computación de 64 bits . ^{[ 97 ]} Windows 8 finalmente introdujo más optimizaciones para sistemas UEFI, incluido el soporte del Protocolo de Salida de Gráficos (GOP), ^{[ 98 ]} un inicio más rápido, soporte de UEFI de 32 bits y soporte de Arranque Seguro. ^{[ 99 ] [ 100 ]} Desde Windows 8 , el firmware UEFI con protocolo ACPI es un requisito obligatorio para los sistemas operativos Microsoft Windows basados ​​en ARM. Microsoft comenzó a exigir UEFI para ejecutar Windows con Windows 11 , ^{[ 101 ]} con las ediciones IoT Enterprise de Windows 11 desde la versión 24H2 exentas de este requisito. ^{[ 102 ]}
• El 5 de marzo de 2013, la Fundación FreeBSD otorgó una subvención a un desarrollador que buscaba agregar soporte UEFI al kernel y al cargador de arranque de FreeBSD . ^{[ 103 ]} Los cambios se almacenaron inicialmente en una rama discreta del código fuente de FreeBSD, pero se fusionaron con el código fuente principal el 4 de abril de 2014 (revisión 264095); los cambios también incluyen soporte en el instalador. ^{[ 104 ]} El soporte de arranque UEFI para amd64 apareció por primera vez en FreeBSD 10.1 y para arm64 en FreeBSD 11.0. ^{[ 105 ]}
• NetBSD admite UEFI desde la versión 8.0 ^{[ 106 ]} para las arquitecturas i386 y amd64, así como en varias plataformas ARM desde la versión 9.0. ^{[ 107 ]}
• Oracle Solaris 11.1 y versiones posteriores admiten el arranque UEFI para sistemas x86 con firmware UEFI versión 2.1 o posterior. GRUB 2 se utiliza como cargador de arranque en x86. ^{[ 108 ]}
• OpenBSD 5.9 ^{[ 109 ]} introdujo soporte de arranque UEFI para sistemas x86 de 64 bits utilizando su propio cargador personalizado, OpenBSD 6.0 extendió ese soporte para incluir ARMv7. ^{[ 110 ]}
• illumos añadió soporte básico para UEFI en octubre de 2017. ^{[ 111 ]}
• ArcaOS admite el arranque UEFI desde la versión 5.1. ^{[ 112 ]} La compatibilidad UEFI de ArcaOS emula funcionalidades específicas de la BIOS de las que depende el sistema operativo (en particular, las interrupciones INT 10H e INT 13H ). ^{[ 113 ] [ 114 ]}

• HP Integrity Virtual Machines proporciona arranque UEFI en servidores HP Integrity. Además, ofrece un entorno UEFI virtualizado para los sistemas operativos invitados compatibles con UEFI.
• Intel aloja un proyecto de firmware de máquina virtual abierta en SourceForge. ^{[ 115 ]}
• El software VMware Fusion 3 para Mac OS X puede arrancar máquinas virtuales de Mac OS X Server utilizando UEFI.
• VMware Workstation anterior a la versión 11 admite UEFI de forma no oficial, pero se habilita manualmente editando el archivo .vmx. ^{[ 116 ]} VMware Workstation versión 11 y posteriores admiten UEFI, independientemente de si el sistema host físico se basa en UEFI. VMware Workstation 14 (y, por consiguiente, Fusion 10) añade compatibilidad con la función de arranque seguro de UEFI. ^{[ 117 ] [ 118 ]}
• El hipervisor VMware ESXi 5.0 admite oficialmente UEFI. La versión 6.5 añade compatibilidad con Secure Boot. ^{[ 119 ] [ 120 ]}
• VirtualBox implementó UEFI desde la versión 3.1, ^{[ 121 ]} pero está limitado a sistemas operativos Unix/Linux y Windows 8 y versiones posteriores (no funciona con Windows Vista x64 y Windows 7 x64). ^{[ 122 ] [ 123 ]}
• QEMU / KVM se puede utilizar con el firmware de máquina virtual abierta (OVMF) proporcionado por TianoCore . ^{[ 124 ]}
• La segunda generación de la máquina virtual Microsoft Hyper-V admite UEFI virtualizado. ^{[ 125 ]}
• Las máquinas virtuales protegidas de Google Cloud Platform admiten UEFI virtualizado para habilitar el arranque seguro. ^{[ 126 ]}

En 2011, Microsoft anunció que los ordenadores certificados para ejecutar su sistema operativo Windows 8 debían 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. ^{[ 135 ] [ 136 ]} Tras el anuncio, los críticos y los defensores del software libre/código abierto, incluida la Free Software Foundation, expresaron su preocupación de que Microsoft pudiera utilizar la funcionalidad de Arranque Seguro de UEFI para restringir la instalación de sistemas operativos alternativos como Linux. Microsoft negó que el requisito de Arranque Seguro tuviera la intención de servir como una forma de dependencia 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 esté deshabilitado, pero no en sistemas que utilizan la arquitectura ARM . ^{[ 45 ] [ 137 ]} Windows 10 permite a los OEM decidir si el Arranque Seguro puede ser administrado por los usuarios de sus sistemas x86. ^{[ 138 ]}

Otros desarrolladores plantearon inquietudes sobre 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 versión 3 de la Licencia Pública General de GNU  podrían impedir el uso del cargador de arranque unificado GNU GRand sin que el desarrollador de la distribución divulgue la clave privada (sin embargo, la Free Software Foundation aclaró posteriormente su posición, asegurando que la responsabilidad de poner las claves a disposición recaía en el fabricante del hardware), ^{[ 139 ] [ 88 ]} y que también sería difícil para los usuarios avanzados crear kernels personalizados que pudieran funcionar con Secure Boot habilitado sin autofirmarlos. ^{[ 137 ]} 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 fabricantes de equipos originales (OEM) para que incluyeran en sus ordenadores la clave requerida junto con la clave de Microsoft. ^{[ 4 ]}

Varias distribuciones importantes de Linux 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 de Linux. ^{[ 140 ]} Ubuntu 12.10 utiliza una versión anterior de shim preconfigurada para su uso con la clave propia de Canonical que verifica solo el cargador de arranque y permite cargar kernels sin firmar; los desarrolladores creían que la práctica de firmar solo el cargador de arranque es más factible, ya que un kernel de confianza es efectivo para asegurar solo el espacio de usuario , y no el estado de prearranque para el cual Secure Boot está diseñado para agregar protección. Esto también permite a los usuarios crear sus propios kernels y usar módulos de kernel personalizados , sin necesidad de reconfigurar el sistema. ^{[ 88 ] [ 141 ] [ 142 ]} 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 que tanto una clave de Canonical como una clave de Microsoft (por razones de compatibilidad) se incluyan en su firmware. Fedora también usa shim, pero requiere que tanto el kernel como sus módulos también estén firmados. ^{[ 141 ]} shim tiene una clave de propietario de máquina (MOK) que se puede usar para firmar kernels compilados localmente y otro software no firmado por el mantenedor de la distribución, sin cambiar el modo de arranque seguro al modo de configuración. ^{[ 143 ] [ 144 ]}

Se ha debatido si el núcleo del sistema operativo y sus módulos también deben estar firmados; si bien las especificaciones UEFI no lo exigen, Microsoft ha afirmado que sus requisitos contractuales sí lo hacen y que se reserva el derecho de revocar cualquier certificado utilizado para firmar código que pueda comprometer la seguridad del sistema. ^{[ 142 ]} En Windows, si el Arranque Seguro está habilitado, todos los controladores del núcleo deben estar firmados digitalmente; los controladores que no sean WHQL pueden rechazarse para cargarse. 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 argumentó que Red Hat estaba cediendo al control de Microsoft sobre la infraestructura de Arranque Seguro. ^{[ 145 ]}

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 , alegando que los requisitos de arranque seguro de Microsoft en los sistemas OEM eran "obstructivos" y anticompetitivos . ^{[ 146 ]}

En la conferencia Black Hat de agosto de 2013, un grupo de investigadores de seguridad presentó una serie de exploits en implementaciones específicas de UEFI de proveedores que podrían usarse para explotar Secure Boot. ^{[ 147 ]}

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. ^{[ 148 ]} Técnicamente, no se expuso ninguna clave, pero sí un binario vulnerable firmado por ella. Esto permite que el software se ejecute como si estuviera firmado por Microsoft, lo que presenta riesgos potenciales para ataques de rootkit y bootkit . Esto también complica los esfuerzos de remediación, ya que un parche podría ser degradado al reemplazarlo con el binario vulnerable firmado. Microsoft declaró que la vulnerabilidad solo afecta a la arquitectura ARM y a los dispositivos Windows RT , y lanzó dos actualizaciones; sin embargo, algunos informes señalaron que estas actualizaciones no impiden completamente la explotación, ya que resolver la vulnerabilidad por completo requeriría el reemplazo de claves en el firmware del usuario final.

El 1 de marzo de 2023, investigadores de ESET informaron del descubrimiento de "BlackLotus", descrito como el primer bootkit UEFI activo capaz de eludir el arranque seguro UEFI explotando las limitaciones de las actualizaciones de seguridad anteriores. ^{[ 149 ] [ 150 ]}

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 provocó que algunas distribuciones de Linux no se cargaran correctamente. SBAT es un protocolo compatible con las versiones más recientes del Administrador de arranque de Windows y el shim, que impide que los gestores de arranque intermedios defectuosos o vulnerables (normalmente versiones antiguas del Administrador de arranque de Windows y GRUB ) se carguen durante el proceso de arranque. El cambio se revirtió al mes siguiente. ^{[ 151 ]}

En junio de 2025, LWN.net informó que el certificado UEFI CA 2011 de Microsoft expiraría el 24 de junio de 2026, lo que podría impedir que algunas distribuciones de Linux se carguen si el arranque seguro está habilitado. ^{[ 152 ] [ 153 ]} Sin embargo, en TianoCore EDK II , así como en muchas implementaciones comerciales de UEFI (como AMI Aptio), la comprobación de fecha y hora para el certificado de arranque seguro suele estar deshabilitada por defecto. ^{[ 153 ]}

Muchas distribuciones de Linux son compatibles con el arranque seguro UEFI desde enero de 2025. , tales como RHEL (RHEL  7 y posteriores), CentOS (CentOS  7 y posteriores ^{[ 154 ]} ), Ubuntu , Fedora , Debian (Debian  10 y posteriores ^{[ 155 ]} ), OpenSUSE y SUSE Linux Enterprise . ^{[ 156 ]}

Se han reportado varios problemas técnicos relacionados con implementaciones específicas del firmware UEFI en dispositivos comerciales. ^{[ 157 ]}

Tras el lanzamiento de Windows 8 en octubre de 2012, se descubrió que ciertos modelos de computadoras Lenovo con Secure Boot tenían UEFI que verificaba la presencia de " Windows Boot Manager " o " Red Hat Enterprise Linux " en la cadena descriptiva de un sistema operativo compatible con UEFI, negándose a cargarlo en caso contrario. ^{[ 158 ]} Se reportaron dificultades operativas similares con respecto a varios modelos de portátiles Toshiba en los que faltaban certificados de firmware específicos necesarios para el funcionamiento de Secure Boot. ^{[ 157 ]}

En enero de 2013, se hizo público un problema de firmware relacionado con la implementación UEFI en ciertas computadoras portátiles Samsung , que dejaba los dispositivos completamente inoperables después de instalar una distribución de Linux en modo UEFI. Si bien los informes iniciales atribuyeron el problema a conflictos con un módulo del kernel diseñado para acceder a las funciones del sistema en las computadoras portátiles Samsung (lo que llevó a los mantenedores del kernel a deshabilitar el módulo en los sistemas UEFI como medida de seguridad), el análisis de Matthew Garrett indicó que la condición se activaba al almacenar variables UEFI excesivas en la memoria no volátil, un comportamiento que también podría ocurrir bajo ciertas condiciones en Windows. Su análisis concluyó que el módulo del kernel asociado provocaba que se escribieran volcados de mensajes del kernel en el espacio de almacenamiento del firmware, ejecutando el estado de falla. ^{[ 30 ] [ 159 ] [ 160 ]}