Brancher son silicium : le Provider Pack de A à Z

Un fabricant de silicium (NPU, accélérateur cryptographique, radio logicielle) veut que son matériel serve dans une flotte de nœuds edge. Le chemin classique passe par une intégration propriétaire : pilote spécifique, SDK fermé, portage refait pour chaque programme, coût d’entrée payé à chaque client. Le résultat est connu : le matériel arrive tard, l’intégration verrouille les deux parties, et chaque programme repart de zéro. Pour un fabricant de taille intermédiaire, ce coût d’intégration répété est souvent rédhibitoire : son silicium peut être meilleur que celui d’un grand fournisseur et rester hors des programmes, faute de pouvoir financer une intégration par client.

OC2-Edge propose un chemin standard : le Provider Pack, abrégé PCK. Cet article décrit ce qu’un PCK contient, comment le construire sans matériel grâce au pack NPU émulé du dépôt, comment un pack vit dans une flotte, et pourquoi le repli logiciel obligatoire sert aussi les intérêts du fabricant.

Le problème, vu du nœud

Un nœud OC2-Edge exécute des modules signés et isolés. Un module qui veut de l’inférence, du chiffrement accéléré ou une forme d’onde n’a pas à savoir quel silicium se trouve sous lui. Il déclare un besoin de capacité dans son manifeste ; le nœud fait correspondre ce besoin avec les capacités disponibles.

Pour que cette correspondance fonctionne, le matériel doit se présenter au nœud sous une forme normée. C’est le rôle du PCK : l’unité de livraison par laquelle un fabricant expose son silicium à toutes les instances OC2-Edge, sans négociation bilatérale avec chaque intégrateur. L’idée d’exposer des ressources matérielles aux charges de travail par une interface déclarative n’est pas propre au projet : les device plugins de Kubernetes suivent le même principe dans les infrastructures de conteneurs [5], et les spécifications OCI normalisent de la même façon l’unité de livraison logicielle [4]. Le PCK ajoute ce que le contexte défense exige : preuve, attestation et vie hors ligne.

Les quatre pièces d’un PCK

Le PCK est une archive signée qui contient quatre pièces.

Le manifeste. Il déclare l’identité du pack (fabricant, matériel visé, version, révision de firmware couverte) et les capacités matérielles exposées, dans le vocabulaire de capacités du socle : par exemple inférence avec formats supportés, primitives cryptographiques accélérées, formes d’onde disponibles. Le manifeste déclare aussi, capacité par capacité, l’équivalent logiciel de repli (la section finale y revient). Comme pour les modules, rien d’implicite : une capacité absente du manifeste n’existe pas pour le nœud.

L’autotest embarqué. Le pack embarque sa propre procédure de vérification, exécutable sur le nœud, sans outillage externe : présence du matériel, version de firmware, réponses correctes sur des vecteurs de test connus. L’autotest court à l’activation, puis à la demande de l’opérateur. Un autotest en échec laisse la capacité sur son repli logiciel et journalise l’écart.

La session témoin rejouable. Le fabricant enregistre une session de référence : les entrées soumises au matériel et les sorties attendues. Cette session se rejoue sans le matériel, contre l’émulation du pack, et avec le matériel, contre le silicium réel. Elle donne aux intégrateurs et aux évaluateurs un objet de comparaison stable : le même comportement, prouvé dans les deux environnements. La session témoin sert aussi l’homologation : une autorité qui évalue une flotte peut rejouer la session sur un nœud de référence et verser le résultat au dossier, sans dépendre du laboratoire du fabricant.

L’attestation signée du fabricant. Le fabricant signe le pack : il atteste que le manifeste décrit son matériel, que l’autotest est le sien et que la session témoin provient de son laboratoire. Cette signature s’ajoute à celle de l’instance (qui approuve l’entrée du pack dans sa flotte), elle ne la remplace pas. Lorsque le matériel dispose d’un composant d’attestation conforme aux spécifications du Trusted Computing Group, le pack peut en outre lier l’attestation à l’état mesuré de la plateforme [3].

Le pack NPU émulé : l’exemple exécutable

Le dépôt public contient un PCK complet pour un NPU émulé. Il sert de gabarit : manifeste rempli, autotest fonctionnel, session témoin fournie, chaîne de signature d’exemple. Il s’exécute sur les nœuds émulés x86-64 et ARM64 du socle, sans aucun matériel.

L’intérêt est double. Pour le fabricant, c’est le point de départ : cloner le pack, remplacer l’émulation par le pilote réel, conserver la structure. Pour tout le monde, c’est la preuve rejouable : la chaîne PCK entière (validation, signature, activation, repli) se démontre sur émulateur, et les ~930 tests automatisés du dépôt couvrent ce chemin comme les autres.

Le chemin de construction, condensé, suit quatre temps :

cloner le pack NPU émulé et rejouer sa session témoin sur un nœud émulé, pour observer la chaîne complète en fonctionnement ;
écrire le manifeste du matériel réel : capacités exposées dans le vocabulaire du socle, repli logiciel désigné pour chacune ;
remplacer l’émulation par le pilote et l’autotest réels, puis enregistrer la session témoin sur le silicium ;
signer le pack et le soumettre au magasin d’une instance, qui l’approuve selon sa propre politique.

Aucune de ces étapes ne passe par Cercle Digital : le fabricant construit contre une spécification publique et livre à des instances qui décident seules.

La vie d’un pack en flotte

Un pack approuvé entre au magasin de l’instance et se distribue par le dépôt TUF (The Update Framework), comme un module : mêmes rôles signataires, même résistance à la compromission du dépôt, même chemin de révocation. Un pack retiré par le fabricant, ou révoqué par l’opérateur après découverte d’une vulnérabilité de firmware, sort de la flotte par une mise à jour ordinaire ; les capacités concernées retombent sur leur repli logiciel. Trois mécanismes encadrent ensuite la vie du pack sur les nœuds.

L’intégrité par fs-verity. Les fichiers du pack sont scellés par fs-verity : le noyau Linux vérifie chaque lecture contre un arbre de hachés dont la racine est fixée à l’installation [1]. Une altération du pack sur disque, même après installation, rend les blocs modifiés illisibles au lieu de les servir.

La mesure par IMA. L’Integrity Measurement Architecture (IMA) mesure les exécutables et bibliothèques du pack au moment de leur exécution et tient le journal de ces mesures, ancrable dans le TPM du nœud [2][3]. L’opérateur d’instance peut ainsi prouver a posteriori ce qui a réellement couru sur un nœud, pas seulement ce qui y était installé.

L’activation sans coupure de service. L’activation d’un pack est conçue pour un nœud en service : la capacité matérielle est validée par l’autotest, puis publiée au catalogue du nœud ; les modules qui consommaient le repli logiciel basculent vers l’accélération matérielle sans redémarrage du nœud. La désactivation suit le chemin inverse : retour au repli, sans interruption de la fonction. L’intégration sur silicium réel est en cours de campagne d’essais ; la campagne Jetson est outillée et ses résultats seront publiés au fil de l’eau, échecs compris.

Le repli logiciel obligatoire : l’argument anti-verrouillage

La règle du socle est stricte : toute capacité matérielle exposée par un PCK doit avoir un équivalent logiciel dégradé. Pas de repli déclaré, pas d’entrée au magasin. « Dégradé » est assumé : l’inférence logicielle est plus lente, le chiffrement logiciel consomme du processeur, la forme d’onde logicielle couvre moins de cas. La fonction, elle, reste rendue.

Vu de l’opérateur, l’argument est évident : un nœud dont le silicium meurt, ou une flotte dont un fournisseur disparaît, continue d’opérer en mode dégradé. C’est la même logique de dégradation contrôlée que le reste du socle.

Le repli a une conséquence structurelle sur la concurrence : deux packs de fabricants différents qui exposent la même capacité dans le vocabulaire du socle sont substituables du point de vue des modules. Un opérateur peut qualifier une seconde source de silicium sans toucher à ses modules, comparer les deux à session témoin égale, et panacher sa flotte. Le vocabulaire de capacités joue ici le rôle que joue une interface normalisée dans tout marché ouvert : il déplace la concurrence de l’intégration vers la performance.

Vu du fabricant, l’argument est moins évident et mérite d’être posé : le repli obligatoire protège aussi son client du fabricant, et c’est précisément ce qui rend son matériel achetable. Un acheteur défense évalue toute dépendance comme un risque ; un matériel sans échappatoire logicielle est une dépendance dure, qui appelle des clauses, des séquestres et de la méfiance. Un matériel qui accélère une fonction dont le repli logiciel existe est une amélioration de performance, pas un point de défaillance unique. Le PCK inverse ainsi la charge commerciale : le matériel accélère, il ne conditionne pas. Le fabricant vend un gain, pas une captivité, et la comparaison entre son silicium et le repli logiciel est rejouable par le client, session témoin à l’appui.

Sources

Kernel.org, « fs-verity : read-only file-based authenticity protection », 2024, https://www.kernel.org/doc/html/latest/filesystems/fsverity.html
Linux IMA Project, « Integrity Measurement Architecture (IMA) Wiki », 2024, https://sourceforge.net/p/linux-ima/wiki/Home/
Trusted Computing Group, « TPM 2.0 Library Specification », 2019, https://trustedcomputinggroup.org/resource/tpm-library-specification/
Open Container Initiative, « OCI Image Format Specification », 2024, https://github.com/opencontainers/image-spec
The Kubernetes Authors, « Device Plugins », 2024, https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/