Kevin Boone: 5 partes para programar UEFI en Linux

Kevin Boone publica una serie de cinco partes para programar sobre UEFI

Kevin Boone publicó una serie de cinco artículos para desarrolladores de Linux que quieren escribir aplicaciones bare-metal sobre firmware UEFI en un equipo tipo PC. El índice de la serie es explícito sobre el punto de partida: está escrita para programadores con experiencia en Linux, pero asume cero conocimiento previo de UEFI.

Bare-metal, en este contexto, significa que el código se ejecuta sobre el firmware, sin un sistema operativo por debajo que resuelva memoria, archivos o entrada y salida. Es el territorio de los gestores de arranque, las utilidades de diagnóstico de hardware y las herramientas de recuperación.

La serie está pensada para leerse en orden y el propio autor advierte que saltearse partes dificulta el seguimiento. El recorrido es:

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Parte 1 – Compilar y enlazar. Las herramientas de software necesarias y el proceso de compilación y enlace.
Parte 2 – La partición de sistema EFI. Cómo se organiza el espacio donde el firmware busca qué arrancar.
Parte 3 – Crear una imagen de DVD o USB. Cómo generar un medio booteable para probar el resultado.
Parte 4 – Una digresión pragmática. Un paréntesis práctico dentro de la secuencia.
Parte 5 – Manejo de archivos con el Simple File Protocol. Gestión básica de archivos desde el propio entorno UEFI.

El punto de partida es una estación de trabajo Linux y el resultado se prueba con medios booteables, así que el material está pensado para quien ya vive en ese entorno y quiere bajar una capa más.

¿Por qué el firmware dejó de ser un tema solo de especialistas?

UEFI es el software que corre primero cuando se enciende un equipo, antes que el sistema operativo, según The Hacker News. Esa posición lo vuelve una superficie atractiva: quien logra ejecutar código en esa etapa lo hace antes de que se carguen Secure Boot y las defensas del sistema.

Para un founder, la consecuencia es directa. Si tu producto corre sobre hardware que no fabricas —kioscos, terminales de pago, equipos médicos, dispositivos de borde— el firmware es parte de tu superficie de ataque aunque no aparezca en tu backlog.

¿Qué fallas recientes muestran el tamaño del problema?

El caso más reciente es CVE-2026-97631, un desbordamiento de búfer en el código de arranque por red (PXE) de EDK II, el proyecto open source sobre el que casi todos los fabricantes construyen su firmware UEFI, incluidos AMI, Insyde y Phoenix, además del fork endurecido de Microsoft, Project Mu. TianoCore calificó la falla con 9,5 sobre 10 en un aviso publicado el 22 de octubre, según The Hacker News.

El mecanismo es concreto: durante un arranque PXE, el driver copia mensajes de error ICMP en un área fija de 504 bytes y los chequeos de tamaño están mal tanto en la versión IPv4 como en la IPv6, de modo que un mensaje más largo se desborda y sobrescribe memoria cercana con datos elegidos por el atacante.

La corrección se fusionó en la rama principal de EDK II el 15 de octubre, pero ninguna versión estable la incluye todavía y el aviso seguía listando la versión parcheada como no disponible. PXE viene activado por defecto en la build estándar de EDK II, así que la exposición alcanza a organizaciones que arrancan por red, sobre todo servidores y equipos de centro de datos. Intel dijo a Ars Technica que ninguno de sus productos comerciales bajo soporte de seguridad está afectado conocido, y Arm señaló que la falla no aplica directamente a su portfolio.

No es un episodio aislado. En 2023, BlackLotus se convirtió en el primer bootkit UEFI documentado públicamente capaz de saltar Secure Boot en sistemas Windows 11 totalmente actualizados, según Ars Technica, explotando Baton Drop, un fallo lógico del gestor de arranque de Windows registrado como CVE-2022-21894. Antes, en enero de 2024, PixieFail agrupó nueve fallas en la misma parte de EDK II, también alcanzables durante el arranque PXE, según The Hacker News.

La divulgación de CVE-2026-97631 estaba coordinada para enero de 2027. Se adelantó porque el 28 de septiembre un pull request a EDK II describió públicamente la falla con su número de CVE y adjuntó el arreglo. Alex Matrosov, de Anthropic, y Dan Holmes-Mitra, de Google, la habían encontrado. Matrosov afirmó después, según BankInfoSecurity, que «la investigación asistida por IA está matando los embargos»: cuando todos usan las mismas herramientas para buscar vulnerabilidades, ya no eres el único que encuentra el bug.

¿Qué necesita un desarrollador para empezar con UEFI en Linux?

La barrera de entrada es más baja de lo que sugiere el tema. La serie de Boone cubre las herramientas necesarias, el proceso de compilación y enlace, la creación de un medio booteable y la gestión básica de archivos desde el propio entorno UEFI, todo desde una estación Linux.

Para un equipo chico, eso significa que no hace falta contratar a un especialista en firmware para empezar a entender la capa. Un ingeniero con base en C y Linux puede recorrer la serie en orden y llegar a tener un binario que arranca en hardware real.

¿Qué significa esto para tu startup?

Audita el firmware de tus proveedores. Pregunta a quien te vende hardware si su build de EDK II incluye el arreglo de CVE-2026-97631 y cuándo publicará una actualización. Hoy no existe una versión estable que lo traiga, así que la respuesta depende de cada fabricante.
Reduce exposición donde puedas. Si tu infraestructura arranca por red y no lo necesitas, desactivar PXE es la mitigación más directa: la falla solo es alcanzable durante ese tipo de arranque y el aviso no lista un workaround.
Mira la cadena de suministro de firmware como mercado. Que un pull request público haya adelantado meses un aviso coordinado muestra que la verificación de firmware sigue siendo un proceso frágil, con dolores que ningún proveedor resolvió del todo.
Invierte en formación interna. La serie es una ruta de entrada de bajo costo para que alguien de tu equipo entienda qué pasa antes de que arranque tu software, y eso cambia cómo se priorizan los incidentes de seguridad.

Conclusión

La serie de Kevin Boone es material técnico, no una noticia de mercado. Pero llega en un momento en que la capa que corre antes del sistema operativo dejó de ser invisible: los bootkits y las fallas en EDK II muestran que el firmware es una superficie de ataque real y una dependencia que la mayoría de las startups no tiene mapeada. Entender cómo funciona esa capa, aunque sea a nivel básico, es una decisión de riesgo y no un hobby de ingeniería.