--- title: "China estrena UBIOS: un nuevo estándar de firmware que reimagina la “BIOS” con bus virtual unificado y soporte nativo para heterogeneidad" description: "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 rel..." url: https://revistacloud.com/china-estrena-ubios-un-nuevo-estandar-de-firmware-que-reimagina-la-bios-con-bus-virtual-unificado-y-soporte-nativo-para-heterogeneidad/ date: 2025-10-22 modified: 2025-10-22 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2025/10/ubios-china.jpg categories: ["Noticias"] tags: ["BIOS", "china", "UBIOS"] type: post lang: es --- # China estrena UBIOS: un nuevo estándar de firmware que reimagina la “BIOS” con bus virtual unificado y soporte nativo para heterogeneidad 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: 1. **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.). 2. **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. 3. **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: 1. **Por ISA** (OS↔BIOS): **SMC** en ARM o **ECALL** en RISC-V, pasando parámetros en una estructura y usando buffers definidos por UBIOS. 2. **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. Referencias: [cgcorg](https://www.gccorg.com/article/69/426.html) y [mydrivers](https://news.mydrivers.com/1/1081/1081504.htm)