China has taken a significant step in its technological sovereignty strategy with the publication of UBIOS (Unified Basic Input/Output System), a firmware architecture standard that redefines how BIOS, operating systems, BMC (baseboard management controller), and device firmware relate to each other. This isn’t about “patching” UEFI but about rebuilding the interaction layer: a unified virtual bus, a common language of calls and notifications, and a set of tables that describe memory, channels, and services in a normalized way.
The standard, identified as T/GCC 3007—2025 and issued by the Global Computing Alliance (GCC), has support from 13 organizations—including the China Electronic Standardization Institute and Huawei—and positions UBIOS as a distributed and loosely coupled framework. The promise is clear: to decouple the boot and service logic of firmware from the underlying hardware, enabling architecture heterogeneity (ARM, RISC-V, and others), multi-domain systems, and an orderly coexistence of various firmwares on a modern motherboard.
What does UBIOS contribute compared to UEFI
For two decades, UEFI transitioned from being the “successor to traditional BIOS” to a universal boot layer: stable, mature, with a vast ecosystem, and omnipresent across x86, ARM, and even RISC-V. But as functionality grows, so do costs: large reference implementations, highly coupled modules, historical dependencies on ACPI and the x86/Windows ecosystem, and a less natural fit for emerging scenarios (chiplets, dedicated coprocessors, heterogeneity, security enclaves, etc.).
UBIOS is not an alternative implementation of UEFI nor a compatibility mode. It’s an architecture standard defining how BIOS, OS, BMC, and device firmware exchange information in modern systems. Its core includes three main components:
- Unified Virtual Bus (UVB)
- A software virtual bus that unifies physical and logical channels under a single interface.
- Enables components to address services (typed invocations), rather than specific registers or links.
- Extends within and outside the SoC, covering vertical relationships (OS↔BIOS) and horizontal interactions (firmware↔firmware, BIOS↔BMC, etc.).
- A common messaging language
- CIS (Call ID Service) for call operations with return (synchronous or asynchronous), identified by Call ID.
- NII (Notify ID Information) for unidirectional notifications with optional acknowledgment, including Notify Interrupt (when a notification requires waking up the receiver).
- A Message ID of 32 bits (type, module, function/info) and a User ID of 32 bits (type+index) for addressing, routing, and collision resolution when multiple providers or consumers share a service.
- Description tables (the “contract” of data and channels)
- Root table: index of all published UBIOS tables for that boot.
- Memory map: physical regions with types (free, code, data, device, shared), reliability levels (normal/high/low), hot-plug capability, and alignments.
- CIS table: which services (Call ID) exist, who offers them, and through which channel (ISA/UVB).
- UVB table: number of UVB instances, locations of windows and buffers, arbitration rules (delays, cache coherence).
- ISA Call table: in environments using SMC/ECALL (ARM/RISC-V), which UVB buffer transports parameters and prevents passing “live” addresses to the receiver.
- Notify info: ring buffers for less critical notifications (asynchronous, no “feedback”) and their relationship with UVB when acknowledgment is required.
How calls move: from SMC/ECALL to UVB memory windows
Vertical path (OS↔BIOS in ISA):
In ARM AArch64, UBIOS relies on SMC 0; in RISC-V, it uses ECALL with registers a0..a7. The standard defines a common structure for packing parameters (with the Message ID at the start, User ID of sender/receiver, pointers to input/output, and a status field). The goal: reduce dependency on extended registers and channel data through controlled buffers (UVB), so the receiver does not need to resolve unreliable pointers or implicit state.
Horizontal path (firmware↔firmware via UVB):
In-memory UVB uses 64-byte windows with defined headers (version, fragmentation flags, IDs, addresses, input/output sizes with checksum, status, and forwarder fields). UBIOS specifies light arbitration (how to “reserve” a slot by writing User ID and verifying after a delay), fragmentation rules when payload exceeds buffer size, and slot release after acknowledgment. It also details cache coherency considerations to maintain a consistent view among OS and firmware of those areas.
An interesting aspect is the address abstraction: the standard distinguishes direct passing (both sides sharing the same physical mapping) from copy mode (the exchange layer copies data to a UVB zone and adjusts pointers), so developers are not required to assume the memory topology of the other end.
UVB as a “border language” between domains
UBIOS extends beyond boot: it aims to work with multi-domain systems—several “small systems” cooperating—via a inter-domain UVB. In this scenario, BIOS, OS, BMC, and peripheral firmwares share a messaging framework and a service catalog to coordinate:
- Hardware initialization and publication of the memory map.
- Discovery of power management, error handling (RAS), monitoring, and security services.
- Event notifications about failures or events (with interrupts when the receiver must act).
- Invocation of low-level functions in a portable way (ISA or UVB), avoiding software dependence on specific providers.
It’s notable that UBIOS declares itself as “loosely coupled” regarding the ISA: its description normalizes ARM and RISC-V, emphasizing that, unless specified otherwise, everything assumes little-endian and physical addresses.
Security and robustness: explicit limits
The specification does not impose security policies but enforces constructive limits to reduce attack surfaces:
- Delimited buffers for UVB exchanges, with recommendations for cache coherence.
- Prohibition of nested pointers in CIS parameters: the receiver does not need to chase double jumps.
- Lists of services (CIS) and channels (UVB/ISA) to validate invocations and filter allowed operations.
- In ISA calls (SMC/ECALL), limit the shared memory region to prevent arbitrary access.
Moreover, by separating Call ID (with return) from Notify ID (without return, with optional ack) and explicitly defining Message ID (type, module, function/info), UBIOS enforces modeling of each service’s purpose, parameters, and responses—avoiding the ambiguities common in historical firmwares.
What is — and isn’t — UBIOS
UBIOS is an architecture and format standard. It is not a reference firmware nor a source tree; it does not impose a unique implementation. Instead, it provides the common contract (bus, messages, tables, ISA examples) so that BIOS, OS, and device vendors can converge on a unified and extensible exchange layer. Just like any standard, its value depends on the development of robust implementations and a thriving tooling ecosystem that makes it practical outside theory.
Until native, auditable UBIOS firmwares and production systems leveraging this standard emerge at scale, the main achievement is establishing a shared language suitable for today’s heterogeneous landscape (main CPUs + coprocessors + BMC + firmware-driven cards) and for a modular evolution where each part discovers others and negotiates via services, not “magic registers”.
Why it might matter beyond China
If UBIOS gains traction in real implementations, it could have implications beyond technological sovereignty:
- Portability: the same OS could interact with BIOS/firmware from different providers if all expose the UBIOS service catalog and respect the messaging.
- Maintainability: fewer channel dependencies and more purpose-driven code lead to more predictable boot tools and diagnostics.
- Performance: a well-designed virtual bus avoids unnecessary polling and handshakes; UBIOS also leaves room for ISA or out-of-band protocols when performance or latency requirements demand it.
- ecosystem: a common framework facilitates library development, UVB sniffers, table validators, and generally portable telemetry for boot and field failure analysis.
Of course, UEFI won’t disappear overnight. Its widespread adoption, tooling, and installed base remain substantial. Whether UBIOS will coexist with UEFI (as a parallel interaction framework) or whether native UBIOS implementations will aim to gradually replace critical components in certain sectors or architectures is still an open question.
What manufacturers and hyperscalers should watch for
- Cross-compatibility: Will there be shims that allow “wrapping” UEFI services in UBIOS calls and vice versa?
- Tools: Without tooling (table editors, ID validators, UVB analyzers, ISA loggers), adoption will be challenging.
- Performance: Transparent measurements of Call ID latency (SMC/ECALL vs. UVB memory) and throughput of Notify in real-world scenarios (boot, ACPI-like events, RAS, NIC/SSD firmware).
- Security: Threat modeling and prescriptive guidelines for hardening (provider and OS control lists).
- Governance: A living standard requires versioning, conformance testing, and public processes for evolution to prevent fragmentation.
Frequently Asked Questions (FAQ)
What is UBIOS and how does it differ from UEFI?
UBIOS is a firmware architecture standard: it defines a unified virtual bus (UVB), a message language (CIS/NII with Message ID and User ID), and a family of tables (memory, services, channels) so that BIOS, OS, BMC, and device firmware interoperate. UEFI is a specific boot and runtime interface with concrete implementations; UBIOS is the framework that ensures everyone speaks the same language, regardless of the channel.
How are UBIOS services invoked from the OS?
In two ways:
- Via ISA (OS↔BIOS): SMC on ARM or ECALL on RISC-V, passing parameters in a structured format and using UBIOS-defined buffers.
- Via UVB (shared memory):
through 64-byte window buffers with rules for occupation, fragmentation, and acknowledgment.
What tables must BIOS publish under UBIOS to ensure OS visibility?
At a minimum: Root table (index of UBIOS tables), Memory map (regions and types), UVB table (windows and buffers), CIS table (available services and channels), and, if ISA is used, ISA Call table for secure parameter transport. For notifications, Notify info can be added, including ring buffers and interrupt configuration.