La Chine a franchi une étape clé dans sa stratégie d’autonomie technologique avec la publication de UBIOS (Unified Basic Input/Output System), une norme d’architecture micrologicielle qui redéfinit la manière dont la BIOS, le système d’exploitation, la BMC (contrôleur de gestion de cartes) et les micrologiciels des dispositifs interagissent. Il ne s’agit pas simplement de parcher UEFI, mais de reconstruire la couche d’interaction : un bus virtuel unifié, un langage commun d’appels et de notifications et un ensemble de tableaux décrivant la mémoire, les canaux et les services de façon normalisée.

Cette norme, identifiée comme T/GCC 3007—2025 et publiée par la Global Computing Alliance (GCC), bénéficie du soutien de 13 organisations — parmi lesquelles l’Institut de Normalisation de l’Electronique de Chine et Huawei — et classe UBIOS comme un cadre distribué et faiblement couplé. La promesse est claire : dissocier la logique de démarrage et de services du micrologiciel du matériel sous-jacent, permettant une hétérogénéité d’architectures (ARM, RISC-V et autres), des systèmes multi-domaine et une cohabitation ordonnée des différents micrologiciels présents sur une plateforme moderne.

Ce que UBIOS apporte par rapport à UEFI

Durant deux décennies, UEFI a évolué d’un simple successeur» de la BIOS classique vers une couche universelle de démarrage : stable, mature, avec un écosystème énorme et omniprésent sur x86, ARM et même RISC-V. Toutefois, cette croissance en fonctionnalités a ses coûts : implémentations de référence volumineuses, modules fortement liés, dépendances historiques avec ACPI et l’écosystème x86/Windows, ainsi qu’une compatibilité moins naturelle dans des scénarios innovants (chiplets, coprocesseurs dédiés, hétérogénéité, enclaves de sécurité, etc.).

UBIOS n’est pas une alternative d’implémentation UEFI ni un « mode de compatibilité ». Il s’agit d’un standard d’architecture qui définit comment BIOS, syst. d’exploitation, BMC et micrologiciels de dispositifs doivent échanger des informations dans des systèmes modernes. Son cœur comporte trois éléments :

1. Unified Virtual Bus (UVB)
   • Un bus virtuel logiciel qui unifie les canaux physiques et logiques sous une même interface.
   • Il permet aux composants de s’adresser aux services (appels typés), plutôt qu’à des registres ou liens spécifiques.
   • Il s’étend à l’intérieur et à l’extérieur du SoC, couvrant des relations verticales (OS↔BIOS) et horizontales (micrologiciels↔micrologiciels, BIOS↔BMC, etc.).
2. Un langage commun de messages
   • CIS (Call ID Service) pour appels avec retour (synchrones ou asynchrones), identifiés par Call ID.
   • NII (Notify ID Information) pour notifications unidirectionnelles, avec ou sans accusé de réception, incluant Notify Interrupt lorsque la notification nécessite d’éveiller le récepteur.
   • Un Message ID de 32 bits (type, module, fonction/information) et un User ID de 32 bits (type+indice) pour le routage et la gestion des conflits en cas de multiples fournisseurs ou consommateurs du même service.
3. Tables de description (le “contrat” de données et canaux)
   • Root table : index de toutes les tables UBIOS durant ce démarrage.
   • Memory map : régions physiques avec leurs types (libre, code, données, dispositif, partagé), fiabilité, hot-plug, et alignements.
   • CIS table : description des services (Call ID), qui les fournit et par quel canal (ISA/UVB).
   • UVB table : description de chaque UVB, ses fenêtres et buffers, règles d’arbitrage (délai, cohérence de cache).
   • ISA Call table : pour ARM/RISC-V avec SMC/ECALL, précisant le buffer UVB pour transporter paramètres, évitant de passer des adresses “vivantes”.
   • Notify info : anneaux de buffers pour notifications peu critiques (asynchrones, sans “feedback”) et leur lien avec UVB si un acuse est nécessaire.

Le déplacement des appels : de SMC/ECALL vers fenêtres UVB en mémoire

Voie verticale (OS↔BIOS sur ISA) :
Dans ARM AArch64, UBIOS s’appuie sur SMC 0. Sur RISC-V, utilise ECALL avec les registres a0..a7. La norme définit une structure commune pour empaqueter les paramètres (avec le Message ID en début, le User ID de l’émetteur/récepteur, des pointeurs vers input/output et un champ d’état). L’objectif : réduire la dépendance aux registres étendus et canaliser les données via buffers contrôlés (UVB), pour que le récepteur ne doit pas gérer de pointeurs non fiables ni d’état implicite.

Voie horizontale (micrologiciel↔micrologiciel via UVB) :

La UVB mémoire utilise fenêtres de 64 octets avec en-têtes structurés (version, flags, IDs, adresses, tailles, checksum, statut, champs pour forwarders). UBIOS spécifie un arbitrage léger (réserver un slot en écrivant le User ID, en vérifiant après délai), règles de fragmentation si le payload dépasse le buffer, et libération du slot après l’accusé. Il précise aussi la cohérence de cache pour assurer une vision cohérente des zones entre OS et BIOS.

Une abstraction importante concerne les adresses : le standard distingue un passe direct (même mappage physique partagé) et un mode trans-copie (copie des données dans une zone UVB avec ajustement des pointeurs), de façon à éviter que le développeur ait à connaître la topologie mémoire de l’autre extrémité.

UVB comme “langage de frontière” entre domaines

UBIOS ne se limite pas à l’amorçage : il vise à fonctionner dans des systèmes multi-domaine — plusieurs « petits » systèmes coopérant — via une UVB inter-domaine. Dans ce scénario, BIOS, OS, BMC et micrologiciels périphériques partagent un cadre de messagerie et un catalogue de services pour coordonner :

• Initialisation matérielle et publication du plan de mémoire.
• Découverte des services d’énergie, gestion des erreurs (RAS), surveillance, sécurité.
• Notifications de défaillances et d’événements (avec interruptions si nécessaire).
• Appel de fonctions de bas niveau de façon portable (éssaie ou UVB) sans dépendre d’un fournisseur spécifique.

Il est important de noter que UBIOS se déclare « faiblement couplé » par rapport à l’ISA : dans sa description, il cite de façon normative ARM et RISC-V, tout en insistant que, sauf indication contraire, tout se fait en little-endian et avec des adresses physiques.

Sécurité et robustesse : limites explicites

La spécification ne dicte pas de politiques de sécurité précises, mais impose des limites constructives qui réduisent la surface d’attaque :

• Buffers délimités pour les échanges UVB, avec recommandations de cohérence cache.
• Interdiction des pointeurs imbriqués dans les paramètres CIS : le récepteur n’a pas besoin de suivre des double-sauts.
• Listes de services (CIS) et de canaux (UVB/ISA) pour valider les invocations et filtres selon ce qui est permis.
• En appels ISA (SMC/ECALL), limiter la zone mémoire partagée pour empêcher tout accès arbitraire.

En outre, en séparant Call ID (avec retour) de Notify ID (sans retour, avec ack en option) et en explicitant le Message ID (type, module, fonction/information), UBIOS oblige à modéliser précisément les services, leurs paramètres et leurs réponses, évitant ainsi les ambiguïtés des micrologiciels historiques.

Ce qu’est — et ce qu’il n’est pas — UBIOS

UBIOS est une norme d’architecture et de format. Elle ne constitue pas un micrologiciel de référence ni un arbre de sources ; elle n’impose pas une implémentation unique. Elle fournit le contrat commun (bus, messages, tableaux, exemples ISA) pour que les fournisseurs de BIOS, OS et dispositifs se coordonnent via une couche d’échange unifiée et extensible. Comme toute norme, sa valeur réelle dépendra d’implémentations robustes et d’un écosystème d’outils et de diagnostics permettant de la rendre utilisable en pratique.

Jusqu’à ce que des firmwares “UBIOS nativement” vérifiés et des systèmes en production exploitant la norme à grande échelle existent, l’accomplissement majeur de cette norme réside dans la définition d’un langage partagé qui répond au présent hétérogène (CPU principaux + coprocesseurs + BMC + cartes dotées de leur propre micrologiciel) et permet une évolution modulaire où chaque entité découvre et négocie avec les autres par des services, et non par des “registres magiques”.

Pourquoi cela pourrait importer au-delà de la Chine

Si UBIOS s’impose dans des implémentations concrètes, ses implications dépasseront la souveraineté technologique :

• Portabilité : un même OS pourrait dialoguer avec des BIOS/micrologiciels issus de divers fournisseurs si tous exposent le catalogue de services UBIOS et respectent la messagerie.
• Maintenance : moins de dépendances à des canaux spécifiques, plus de « but précis » pour le code de démarrage et les outils de test, avec une plus grande prévisibilité.
• Performance : un bus virtuel bien conçu évite un polling ou des handshakes inutiles ; simultanément, UBIOS laisse ouverts des canaux ISA ou protocols out-of-band si le contexte l’exige.
• Écosystème : un cadre commun facilite le développement de bibliothèques, d’sniffers UVB, d’ validateurs de tableaux et de télémétrie portable pour le débogage lors de démarrages ou en détectant des défaillances sur site.

Naturellement, UEFI ne disparaîtra pas du jour au lendemain : sa diffusion, ses outils et sa base installée sont très importantes. La question reste ouverte : UBIOS cohabitera-t-il avec UEFI (en tant que cadre d’interaction parallèle) ou ses versions natives finiront-elles par remplacer progressivement certains composants critiques dans certains secteurs ou architectures ?

Ce que les fabricants et hyperscalers doivent surveiller

• Compatibilité croisée : existera-t-il des shims permettant d’envelopper des services UEFI en appels UBIOS, ou vice versa ?
• Outils : sans tooling (éditeurs de tableaux, validateurs d’ID, analyseurs UVB, enregistreurs ISA), l’adoption sera limitée.
• Performance : mesurer la latence des Call ID (SMC/ECALL vs mémoire UVB) et le débit de Notify dans des scénarios réels (démarrage, gestion ACPI, RAS, firmwares hardware comme NIC ou SSD).
• Sécurité : réalisation d’analyses de menace et de guides pour renforcer la sécurité (harden) (listes de contrôle pour fournisseurs et OS).
• Gouvernance : une norme vivante requiert versionnement, tests de conformité et processus publics pour assurer son évolution sans fragmentation.

Questions fréquentes (FAQ)

Qu’est-ce qu’UBIOS et en quoi diffère-t-il de UEFI ?
UBIOS est un standard d’architecture micrologicielle : il définit un bus virtuel unifié (UVB), un langage de messages (CIS/NII avec Message ID et User ID) et une famille de tableaux (mémoire, services, canaux) pour faire interopérer BIOS, OS, BMC et micrologiciels de dispositifs. UEFI, quant à lui, est une interface d’amorçage et d’exécution en runtime avec des implémentations concrètes ; UBIOS sert de cadre commun permettant à tous de parler le même langage, quel que soit le canal.

Comment se invoquent les services UBIOS depuis le système d’exploitation ?
De deux manières :

1. Par ISA (OS↔BIOS) : SMC en ARM ou ECALL en RISC-V, via des paramètres empaquetés en structure et buffers UBIOS.
2. Par UVB (mémoire partagée) : par fenêtres de 64 octets et buffers associés, avec règles d’occupation, fragmentation et accusés.

Quelles tables la BIOS doit-elle publier selon UBIOS pour que le système d’exploitation “voit” le système ?
Au minimum : Root table (index des tables UBIOS), Memory map (zones mémoire et types), UVB table (fenêtres et buffers), CIS table (services et canaux), et, si l’on utilise ISA, ISA Call table pour le transport sécurisé des paramètres. Pour les notifications, on peut ajouter Notify info avec ring buffers et interruptions.

Références : cgcorg et mydrivers