China ha dado un paso clave en su estrategia de autonomía tecnológica con la publicación de UBIOS (Unified Basic Input/Output System), un estándar de arquitectura de firmware que redefine cómo se relacionan entre sí la BIOS, el sistema operativo, el BMC (controladora de gestión de placas) y los firmwares de los dispositivos. No se trata de “parchear” UEFI, sino de reconstruir la capa de interacción: un bus virtual unificado, un lenguaje común de llamadas y notificaciones, y un conjunto de tablas que describen memoria, canales y servicios de manera normalizada.
La norma, identificada como T/GCC 3007—2025 y emitida por la Global Computing Alliance (GCC), llega con el aval de 13 organizaciones —entre ellas, el Instituto de Estandarización de la Electrónica de China y Huawei— y sitúa a UBIOS como un marco distribuido y de bajo acoplamiento. La promesa es clara: desacoplar la lógica de arranque y de servicios del firmware del hardware subyacente, habilitando heterogeneidad de arquitecturas (ARM, RISC-V y otras), sistemas multi-dominio y coexistencia ordenada de los distintos firmwares que conviven en una placa base moderna.
Qué aporta UBIOS frente a UEFI
Durante dos décadas, UEFI fue pasando de “sucesor de la BIOS clásica” a capa universal de arranque: estable, madura, con un ecosistema enorme y omnipresente en x86, ARM e incluso RISC-V. Pero el crecimiento funcional trae costes: implementaciones de referencia de gran tamaño, módulos con alto acoplamiento, dependencias históricas con ACPI y el ecosistema x86/Windows, y un encaje menos natural ante escenarios nuevos (chiplets, coprocesadores dedicados, heterogeneidad, enclaves de seguridad, etc.).
UBIOS no es una implementación alternativa de UEFI, ni un “modo de compatibilidad”. Es un estándar de arquitectura que define cómo deben intercambiar información BIOS, OS, BMC y firmwares de dispositivos en sistemas modernos. En su núcleo hay tres piezas:
- Unified Virtual Bus (UVB)
- Un bus virtual software que unifica canales físicos y lógicos bajo una misma interfaz.
- Permite que los componentes se dirijan a servicios (invocaciones tipadas), no a registros o vínculos concretos.
- Se extiende dentro y fuera del SoC, abarcando relaciones verticales (OS↔BIOS) y horizontales (firmware↔firmware, BIOS↔BMC, etc.).
- Un lenguaje común de mensajes
- CIS (Call ID Service) para llamadas con retorno (sincrónicas o asíncronas) identificadas por Call ID.
- NII (Notify ID Information) para notificaciones unidireccionales con acuse opcional, incluyendo Notify Interrupt (cuando la notificación requiere despertar al receptor).
- Un Message ID de 32 bits (tipo, módulo, función/info) y un User ID de 32 bits (tipo+índice) para direccionamiento, enrutado y resolución de colisiones cuando hay varios proveedores o consumidores de un mismo servicio.
- Tablas de descripción (el “contrato” de datos y canales)
- Root table: índice de todas las tablas UBIOS publicadas en ese arranque.
- Memory map: regiones físicas con tipo (libre, código, datos, dispositivo, compartida), fiabilidad (normal/alta/baja), hot-plug y alineaciones.
- CIS table: qué servicios (Call ID) existen, quién los ofrece, por qué canal (ISA/UVB).
- UVB table: cuántas UVB hay, dónde están sus ventanas y buffers, cómo arbitran el uso (delays, coherencia de caché).
- ISA Call table: en entornos que usan SMC/ECALL (ARM/RISC-V), qué buffer UVB se emplea para transportar parámetros y evitar pasar direcciones “vivas” al receptor.
- Notify info: ring buffers para notificaciones menos críticas (asincrónicas, sin “feedback”) y su relación con UVB cuando sí se requiere acuse.
Cómo se mueven las llamadas: de SMC/ECALL a ventanas UVB en memoria
Camino vertical (OS↔BIOS en ISA):
En ARM AArch64, UBIOS se apoya en SMC 0; en RISC-V, utiliza ECALL con registros a0..a7. El estándar define una estructura común para empacar parámetros (con el Message ID al inicio, User ID de emisor/receptor, punteros a input/output y un campo de estado). El objetivo: reducir dependencia de registros extendidos y canalizar los datos por buffers controlados (UVB), de modo que el receptor no tenga que resolver punteros no confiables ni estado implícito.
Camino horizontal (firmware↔firmware por UVB):
La UVB en memoria utiliza ventanas de 64 bytes con cabeceras definidas (versión, flags de fragmentación, IDs, direcciones y tamaños de entrada/salida con checksum, estatus y campos para forwarders). UBIOS especifica arbitraje ligero (cómo “reservar” slot escribiendo el User ID y comprobándolo tras un delay), reglas de fragmentación cuando el payload excede el buffer, y liberación del slot tras el acuse. También detalla consideraciones de coherencia de caché para que OS y BIOS tengan una visión consistente de esas áreas.
Un aspecto interesante es la abstracción de direcciones: el estándar distingue paso directo (ambas partes comparten el mismo mapeo físico) y modo trans-copia (la capa de intercambio copia datos a una zona UVB y ajusta punteros), de forma que el desarrollador no asuma la topología de memoria del otro extremo.
UVB como “idioma de frontera” entre dominios
UBIOS no se limita al arranque: pretende funcionar con sistemas multi-dominio —varios “sistemas pequeños” cooperando— a través de una UVB inter-dominio. En ese escenario, BIOS, OS, BMC y firmwares de periféricos comparten un marco de mensajería y un catálogo de servicios para coordinar:
- Inicialización de hardware y publicación del mapa de memoria.
- Descubrimiento de servicios de energía, gestión de errores (RAS), monitorización, seguridad.
- Notificaciones de fallos y eventos (con interrupciones cuando el receptor debe actuar).
- Invocación de funciones de bajo nivel de forma portable (ISA o UVB) sin encadenar el software a un proveedor concreto.
Es relevante que UBIOS se declara “loosely coupled” respecto a la ISA: en su descripción, cita de forma normativa ARM y RISC-V, y subraya que, salvo indicación en contrario, todo se asume little-endian y con direcciones físicas.
Seguridad y robustez: límites explícitos
La especificación no dicta políticas de seguridad, pero impone límites constructivos que reducen la superficie de ataque:
- Buffers delimitados para intercambios UVB, con recomendaciones de cache-coherencia.
- Prohibición de punteros anidados en parámetros de CIS: el receptor no tiene que perseguir dobles saltos.
- Listados de servicios (CIS) y canales (UVB/ISA) para validar invocaciones y filtrar lo permitido.
- En llamadas ISA (SMC/ECALL), acotar la región compartida de memoria para impedir accesos arbitrarios.
Además, al separar Call ID (con retorno) de Notify ID (sin retorno, con ack opcional) y explicitar el Message ID (tipo+módulo+función/info), UBIOS obliga a modelar qué hace cada servicio, qué parámetros acepta y cómo responde, evitando ambigüedades típicas de firmwares históricos.
Qué es —y qué no— UBIOS
UBIOS es una norma de arquitectura y formato. Esto significa que no es un firmware de referencia ni un árbol de fuentes; tampoco impone una implementación única. Proporciona el contrato común (bus, mensajes, tablas, ejemplos ISA) para que proveedores de BIOS, OS y dispositivos converjan en una capa de intercambio unificada y extensible. Como toda norma, su valor real dependerá de implementaciones robustas y de que florezca un ecosistema de herramientas y diagnósticos que la haga usable fuera del papel.
Mientras no existan firmwares “UBIOS-nativos” auditables y sistemas en producción que lo exploten a escala, el principal logro de la norma es haber fijado un lenguaje compartido apto para el presente heterogéneo (CPU principales + coprocesadores + BMC + tarjetas con firmware propio) y para una evolución modular en la que cada parte descubre al resto y negocia por servicios, no por “registros mágicos”.
Por qué puede importar más allá de China
Si UBIOS logra cuajar en implementaciones reales, tiene implicaciones que van más allá de la soberanía tecnológica:
- Portabilidad: el mismo OS podría hablar con BIOS/firmwares de distintos proveedores si todos exponen el catálogo de servicios UBIOS y respetan la mensajería.
- Mantenibilidad: menos dependencias de canal y más de “propósito” significa código de arranque y herramientas de test más predecibles.
- Rendimiento: un bus virtual bien diseñado evita polling y handshakes innecesarios; al mismo tiempo, UBIOS deja abiertos canales ISA o protocolos out-of-band cuando el rendimiento o la latencia lo aconsejen.
- Ecosistema: un marco común facilita bibliotecas, sniffers de UVB, validadores de tablas y, en general, telemetría portable para depurar arranques y fallos de campo.
Naturalmente, UEFI no desaparece por decreto. Su implantación, tooling y base instalada son enormes. La incógnita es si UBIOS convivirá con UEFI (como marco paralelo de interacción) o si las implementaciones UBIOS-nativas apuntarán a sustituir progresivamente piezas críticas en ciertos sectores o arquitecturas.
Qué deberían vigilar los fabricantes y hyperscalers
- Compatibilidad cruzada: ¿habrá shims que permitan “envolver” servicios UEFI en llamadas UBIOS y viceversa?
- Herramientas: sin tooling (editores de tablas, validador de ID, analizadores de UVB, loggers ISA), la adopción será difícil.
- Desempeño: mediciones transparentes de latencia de Call ID (SMC/ECALL vs UVB memoria) y throughput de Notify en escenarios reales (arranque, ACPI-like, RAS, firmware de NIC/SSD).
- Seguridad: modelado de amenazas y guías prescriptivas para hardening (listas de control para proveedores/OS).
- Gobernanza: una norma viva necesita versionado, pruebas de conformidad y procesos públicos para evolucionar sin fragmentaciones.
Preguntas frecuentes (FAQ)
¿Qué es UBIOS y en qué se diferencia de UEFI?
UBIOS es un estándar de arquitectura de firmware: define un bus virtual unificado (UVB), un lenguaje de mensajes (CIS/NII con Message ID y User ID) y una familia de tablas (memoria, servicios, canales) para que BIOS, OS, BMC y firmwares de dispositivos interoperen. UEFI es una interfaz de arranque y runtime con implementaciones concretas; UBIOS es el marco para que todos hablen el mismo idioma, independientemente del canal.
¿Cómo se invocan los servicios de UBIOS desde el sistema operativo?
De dos formas:
- Por ISA (OS↔BIOS): SMC en ARM o ECALL en RISC-V, pasando parámetros en una estructura y usando buffers definidos por UBIOS.
- Por UVB (memoria compartida): mediante ventanas de 64 bytes y buffers asociados con reglas de ocupación, fragmentación y acuses.
¿Qué tablas debe publicar la BIOS bajo UBIOS para que el OS “vea” el sistema?
Al menos: Root table (índice de tablas UBIOS), Memory map (regiones y tipos), UVB table (ventanas y buffers), CIS table (servicios disponibles y canales) y, si se usa ISA, ISA Call table para transportar parámetros con seguridad. Para notificaciones, puede añadirse Notify info con ring buffers e interrupciones.
