urMQTT sur un vrai VPS : ISO, poignée de main de 0,24 ms, disque propre et noyau durci

Dans le premier article sur urMQTT, nous avons décrit l'unikernel qui est un broker MQTT, jusqu'au jalon M17, et nous avons conclu par trois promesses sous le titre « La suite » : un seul ISO qui démarre sur plusieurs plateformes, un disque brut sans système de fichiers et une sécurité qui se démontre au lieu de simplement s'affirmer. Rien de tout cela n'était encore construit. Cet article suit le sort de chaque promesse, dans le même ordre qu'avant : ce que nous avions prévu, ce que nous avons construit, ce qui nous a surpris et ce qui reste ouvert. Nous montrerons aussi, en chemin, combien de temps tout cela a pris, car cela fait partie de l'histoire.

Une précision d'emblée : le projet reste en pré-alpha. Les chiffres de cet article mesurent du code et des tests, pas une maturité en production, et la première publication est volontairement limitée aux VPS avec KVM. Le bare metal viendra plus tard.

À quoi cela ressemblait dans le temps

Le premier commit date du 28 octobre 2026 à 23:48 (M0). Au 31 octobre à 23:00, le dépôt compte 119 commits, répartis en 3, 39, 38 et 39 par jour calendaire. Disons tout de suite comment c'est possible : le projet se construit avec Claude Code, et les commits portent des trailers Co-Authored-By: Claude. Quatre jours calendaires d'historique ne signifient pas qu'une seule personne a écrit 90 000 lignes en quatre jours ; cela signifie que le plan, l'implémentation, les tests et les ADR s'écrivent en boucles courtes et fermées, et que chaque étape se termine par le même rituel de vérification qu'auparavant. Les chiffres ci-dessous parlent de la quantité de code et de tests, pas du temps de travail réel que tout cela représente.

Le graphique montre trois courbes qui montent presque ensemble, ce qui est voulu : les tests et les décisions consignées suivent le code au lieu de rester à la traîne. La pente est la plus raide le 29 octobre, quand naît tout le chemin qui va du noyau au broker. Ensuite, les lignes s'ajoutent plus lentement, mais les tests croissent plus vite que le code (27 tests pour 1,6 millier de lignes au début, 739 pour 89,8 milliers aujourd'hui).

Jalon	Commit	Heure	Lignes de Rust	Tests	ADR
M0	9412a9c	28.10. 23:48	1 592	27	13
M5	a61083b	29.10. 01:32	9 314	88	24
M9	4be8cc9	29.10. 02:21	15 729	149	28
M11	4800904	29.10. 03:43	22 737	180	30
M13	a558d5e	29.10. 05:22	26 556	193	32
M17	7df4f98	29.10. 08:48	33 504	232	36
S1	ecf72ec	30.10. 00:46	41 910	299	45
X8	fb1504a	30.10. 19:08	56 341	456	59
PERF	76f7c36	31.10. 14:19	72 511	618	76
aujourd'hui	HEAD	31.10. 23:00	89 790	739	104

Les lignes sont tous les fichiers .rs hors de vendor/ et fuzz/, et les tests sont des fonctions #[test]. Ce que chaque étape a apporté, par date d'après l'historique git :

Date	Jalons	Ce qui a été ajouté
29.10.	M0 à M17	noyau, réseau, TLS, broker, SQLite, multicœur, TCP maison, durcissement, publication reproductible
29.10. au soir et 30.10.	X0 à X10, S1, H2, H3 (X0 commence le 29.10. à 20:54)	portage vers x86_64, ISO universel, un seul disque et ISO auto-installant, contrôles TLS, clients hostiles
31.10.	O1 à O4, T1, PERF, H4, H5, H9, S2 à S6	observabilité et console via MQTT, mode live et diagnostic, SNTP, accélérations, durcissement, vérification, chaîne d'approvisionnement, stockage

Promesse 1 : un seul ISO pour plusieurs plateformes

Ce que nous avions prévu. Un seul fichier qui démarre sur UEFI aarch64, UEFI x86_64 et BIOS x86_64. Ce que nous avons construit. Le portage vers x86_64 (X0 à X10) et un ISO universel avec le bootloader Limine, un ISO hybride unique d'où démarrent toutes ces combinaisons ; les tests de fumée le démarrent sur quatre machines virtuelles. Le menu comporte trois entrées : urMQTT (mode live, exécuté depuis la RAM, rien n'est écrit sur le disque), l'installation sur le disque de la machine sur laquelle il tourne (l'installation écrit le GPT et les données, puis éteint la machine) et Diagnostic (détection du matériel et mesures).

La première cible réelle a été un VPS, et non un ordinateur physique : la décision est que la première publication ne prend en charge que les VPS (KVM), et que le bare metal viendra après. Nous avons testé sur un VPS Contabo avec un processeur AMD EPYC (famille 23, Zen 1), 4 vCPU et 8 GiB de RAM, avec un réseau virtio-net et un disque virtio-scsi. Le premier essai nous a surpris : l'ISO attaché comme CD virtuel démarrait l'entrée par défaut, l'image de production refusait de fonctionner depuis un support en lecture seule et se réinitialisait, et nous nous sommes retrouvés dans une boucle infinie menu, noyau, réinitialisation sans rien de lisible. Aujourd'hui, une erreur fatale dans l'image de production laisse un message sur la console pendant 60 secondes avant la réinitialisation, et depuis un support optique elle affiche qu'elle a démarré depuis un support en lecture seule, puis s'arrête. Le mode live en RAM (O3) a ensuite contourné ce problème pour le cas courant.

L'entrée de diagnostic est née de cette expérience : une machine que nous ne voyons pas, nous devons pouvoir l'interroger sur ce qu'elle contient. Elle affiche le CPU, la RAM, le réseau, les disques et les périphériques PCI, mesure le débit mémoire, le disque et la cryptographie, et écrit les mêmes mesures en JSON sur le port série. L'écriture sur le disque n'est permise que dans l'espace non alloué, et seulement après avoir saisi WIPE ; sur la capture ci-dessous, cette étape a été sautée.

Ce qui reste ouvert. Le vrai matériel. Après la première publication viendra le bare metal (démarrage USB, NVMe et AHCI, carte réseau d'un vrai ordinateur), avec l'IOMMU et Secure Boot, car sans IOMMU un périphérique malveillant ou défectueux peut écrire dans toute la mémoire. Dans cette version, nous n'affirmons rien à ce sujet.

La poignée de main : de 1,2 ms à 0,24 ms

La première mesure du diagnostic sur le VPS a donné un chiffre gênant : la poignée de main mTLS, uniquement la cryptographie côté serveur, durait 1,2 ms. Sur aarch64, nous utilisions déjà les instructions matérielles AES et SHA, mais x86_64 n'avait rien de comparable pour la clé publique : RustCrypto est portable et à temps constant, donc lent aussi. Trois changements l'ont fait baisser.

• Pour P-256, nous avons repris l'assembleur nistz256 d'OpenSSL et de ring (ADR-130), avec des tables à base fixe pour la signature et la vérification des signatures de la CA (ADR-110, ADR-111).
• X25519 a été réécrit sur quatre membres de 64 bits avec les instructions MULX/ADX (ADR-131).
• Nous avons ensuite profilé tout le reste (ADR-132, ADR-200).

Mesure sur le VPS (serveur, microsecondes)	Avant	Après
poignée de main mTLS, toute la cryptographie	1200	environ 240 (237 dans la mesure du graphique, 244 sur la capture)
X25519	146	48
signature ECDSA	673	34
vérification ECDSA	309	90 (107 sur la capture)
poignée de main, ancien memcpy, même boot	278,8	229,4 (-17,7%)

Les chiffres varient d'environ 10% d'une exécution à l'autre, c'est pourquoi nous avons noté une fourchette plutôt qu'une valeur unique. Au total, cela représente environ cinq fois moins de temps CPU par poignée de main.

Ce que nous avons appris sur memcpy. Quand la cryptographie a chuté, le profil a montré quelque chose d'inattendu : les fonctions mem* (memcpy, memmove, memset) consommaient 7% de la poignée de main, 13 à 39% du chemin d'un enregistrement TLS (39% pour 64 B, 13% pour 4 KiB) et 17 à 34% de la distribution des PUBLISH. Nous les avons remplacées par de l'assembleur SSE2 pour x86_64 (ADR-200), avec des tests différentiels contre l'implémentation de référence pour toutes les tailles, tous les alignements et tous les chevauchements. Par appel, cela donne 55 à 75 cycles contre 7 à 12 pour 1 à 64 octets.

Chemin	Part de mem* avant	Plus rapide après
poignée de main	7%	17,7%
enregistrement TLS 64 B	39%	26,4%
enregistrement TLS 256 B	37%	19,6%
enregistrement TLS 1 KiB	24%	16,1%
enregistrement TLS 4 KiB	13%	6,6%
distribution des messages	17 à 34%	7 à 34%

Lecture du graphique : plus l'enregistrement est petit, plus la part du temps consacrée à la copie est grande, et plus le gain est important. Pour les petits messages, qui forment l'essentiel du trafic MQTT, c'est ce qui compte.

Ce que cela ne veut pas dire. Sur x86_64 natif, nous n'avons mesuré OpenSSL 3.5.5 (ADR-130) que comme référence pour l'assembleur, et non comme comparaison de produits. La comparaison Linux plus Mosquitto sur le même VPS (tâche X11) n'a pas encore été faite. Nous n'affirmons donc pas qu'urMQTT est plus rapide que Linux : ce n'est pas mesuré. Les chiffres ci-dessus comparent urMQTT à lui-même.

La surcharge a été le second résultat. Sur le VPS, depuis un seul Mac (RTT 35 ms), 128 clients ont donné 618 poignées de main par seconde, 256 clients 393, et 512 clients 67, avec des milliers de connexions refusées. Ce n'était pas un plateau mais un effondrement. Nous avons trouvé les causes dans le code (deux sont confirmées dans QEMU/HVF, mais n'ont pas pu être reproduites sur le VPS), plusieurs à la fois : une connexion refusée renvoyait le client sur le segment suivant portant un cookie SYN valide, le refus par RST disait au client de réessayer aussitôt, et la réception était en O(file). Le correctif (ADR-080 à ADR-082) laisse tomber un SYN qui ne serait pas accepté, mémorise les flux refusés, maintient la réception en O(1) et compte les poignées de main par cœur. Il est possible (hypothèse, non vérifiée) qu'une partie de la cause se soit trouvée aussi côté client : l'outil de charge fermait en premier, si bien qu'un seul Mac, avec 16 384 ports éphémères et un TIME_WAIT de 30 secondes, était limité à environ 550 connexions par seconde. Nous n'avons donc pas encore mesuré le vrai plafond du serveur.

Promesse 2 : un disque brut, mais soigneux

Ce que nous avions prévu. Garder notre propre disposition sans système de fichiers, et ajouter tout ce qu'un système de fichiers apporte d'habitude : alignement, croissance, discard, sauvegardes et vérifications. Pourquoi pas un système de fichiers. Nous en avons débattu et la décision est confirmée : urMQTT écrit une seule base, un seul journal de télémétrie et ses propres métadonnées, n'a besoin ni de répertoires, ni de permissions, ni de noms de fichiers, et chaque couche supplémentaire serait du code de plus dans la partie de confiance et une manière de plus de perdre un enregistrement en silence. Le disque est un GPT avec une partition ESP et une partition de données urMQTT, sur laquelle se trouve la disposition propre au projet.

Ce que nous avons construit (S2 à S6).

• Disposition v2 (S2). Topologie du disque, alignement sur 1 MiB ou sur la taille d'E/S optimale, blocs physiques entiers, paire A/B de superblocs avec génération (ADR-140). La disposition v1 est refusée par le noyau avec un message clair, et l'outil hors ligne urmqtt-disk migrate la migre (ADR-141) : par défaut c'est un passage à blanc, on copie puis on bascule seulement ensuite, avec retour arrière et injection de fautes à chaque écriture.
• Croissance (S3). Au démarrage, le disque peut grandir (jamais rétrécir), et sur virtio-blk aussi pendant l'exécution, via l'interruption de changement de configuration (ADR-142, ADR-143).
• Discard et write-zeroes (S4). Les disques à allocation dynamique rendent l'espace à l'hôte. Dans un test, le fichier qcow2 sur l'hôte est passé de 62 à 16 MiB après l'expiration des segments de télémétrie, et la récupération ne fait jamais confiance au contenu qui a été rejeté.
• Sauvegarde de la base sur le disque (S5). Une copie A/B avec l'API de sauvegarde en ligne de SQLite par pas de 16 pages : l'étape la plus longue dure 4,6 ms contre 445 ms quand on copie en un seul appel. Les commits pendant la copie ont eu un maximum de 2,4 ms contre 2,2 ms sans elle. Si quick_check échoue au démarrage, la base est restaurée à partir de la copie.
• Nettoyage et démarrage borné (S6). Le scrubber lit le disque avec un budget d'E/S limité et signale les enregistrements corrompus, et le démarrage ne lit que le segment le plus récent de chaque partition, si bien que le temps de démarrage ne croît pas avec la taille de la région de télémétrie. Nous avons ainsi fermé un problème que nous avions calculé à l'avance : sur un grand disque, une récupération complète aurait pris de quelques minutes à plusieurs dizaines de minutes.

Tout le groupe de tests de fumée du stockage passe sur les deux architectures : 79 réussis, 0 échoués, sur aarch64 sous HVF et sur x86_64 sous TCG. Nous avons aussi mesuré que S4 n'a pas ralenti la base : 53,3 milliers d'insertions par seconde par lots avant et après, sans différence mesurable.

Ce qui a surpris. La part des cas limites dans une disposition « simple » : virtio-scsi et virtio-blk signalent la topologie de manières différentes, et une écriture incomplète au milieu d'une migration doit toujours laisser au moins une version valide. C'est pourquoi chaque écriture sur le chemin de migration et de croissance a subi une injection de fautes.

Ce qui reste ouvert. Les pages SQLite n'ont pas de somme de contrôle, donc la base ne détectera pas un bit modifié à l'intérieur d'une valeur d'une ligne ; les enregistrements de télémétrie et le contenu des copies ont un CRC et sont détectés. Le chiffrement du disque (S7) n'est pas terminé.

Promesse 3 : démontrablement sûr, autant que nous y parvenons

Durcissement (H4). L'allocateur efface la mémoire libérée et la vérifie à la réutilisation, détecte les double libérations, lie les pointeurs de la liste libre par XOR et met les clés à zéro à la libération (ADR-170). Protection de la pile (-Zstack-protector=strong, 1315 fonctions, et SQLite avec -fstack-protector-strong, ADR-171). Les rapports d'erreur en production ne contiennent ni registres ni adresses (ADR-172). KASLR sur les deux architectures : le noyau est PIE et Limine le déplace d'environ 19 bits, tandis que le heap, les piles et la fenêtre MMIO sont placés au hasard (ADR-173). Sur aarch64, MTE marque le heap (ADR-174), mais seulement sous TCG : HVF et x86 n'en disposent pas. Nous avons évalué kCFI sans le retenir, car le compilateur du nightly épinglé plante avec une erreur interne ; l'IOMMU est reporté avec le bare metal (ADR-175, ADR-176).

Le coût est mesuré, pas supposé. Sur le chemin de la poignée de main (dp-bench, aarch64 HVF, poignées de main complètes TLS 1.3 + mTLS + CONNECT) :

Étape	1 cœur	4 cœurs	Variation
sans durcissement	1941	7620
+ allocateur	1898	7429	-2,2% à -2,5%
+ protection de la pile	1845	7243	ensemble -4,9% à -5%
+ PIE et marquage	environ 1800	environ 6750	sur une machine chargée, bruité

Au total, le coût sur le chemin de la poignée de main est donc d'environ 5% pour les éléments mesurés proprement, et avec PIE et le marquage on obtient environ 7% sur un cœur et environ 11% sur quatre, mais cette mesure est bruitée. Nous la jugeons acceptable, mais nous ne l'avons pas reproduite sur le VPS x86_64.

Il vaut la peine de comparer avec le chiffre du premier article (862 poignées de main par seconde sur un cœur). Le même outil aujourd'hui, avec le pilote de chiffrement matériel sur aarch64 (X0b) et la série d'accélérations arrivées depuis, donne 1941 avant le durcissement. Nous n'avons pas isolé la contribution de chaque changement, donc nous n'affirmons rien sur la cause.

Comment cela a été vérifié, et ce qui ne l'a pas été. H5 a ajouté Miri sur un sous-ensemble de crates de l'hôte, des preuves Kani, des sanitizers, un model-fuzzer pour les ACL et des rapports de couverture. Kani a prouvé record_len dans TLS, parse dans TCP et deux arithmétiques de la roue de timers. Non prouvés (délai dépassé) : les deux décodeurs MQTT, les deux analyses de configuration et le comportement de la roue de timers ; le job CI de Kani n'est donc pas encore bloquant. Miri ne peut pas exécuter d'assembleur. Chaîne d'approvisionnement (H9) : SBOM CycloneDX de 215 composants, cargo-vet passe avec 39 audités complètement et 140 exemptions, et cargo-deny est configuré pour traiter les avis de vulnérabilité comme un échec de la CI (ces jobs CI n'ont été vérifiés jusqu'ici qu'en local, pas sur GitHub, et le test négatif n'a pas été exécuté), avec VULNERABILITY-HANDLING.md. L'état honnête : sur 67 versions de crates tierces liées au noyau, 53 sont des exemptions et non des audits. Vet prouve que l'ensemble des dépendances ne peut pas changer sans différence visible, pas que le TCB a été examiné. Nous n'avons écrit notre propre audit d'aucun crate.

SNTP (T1) est dans ce sens une petite histoire de sécurité : il est facultatif, uniquement vers des serveurs IPv4 privés, avec un saut maximal et à la condition que les sources s'accordent (médiane, majorité à moins d'une seconde). Une horloge que n'importe qui sur le chemin peut décaler n'est pas une horloge à laquelle nous pouvons nous fier pour la validité des certificats.

Sur le Mac : aarch64 en natif et x86_64 par émulation

Nous développons sur un Mac, et celui-ci offre deux manières d'exécuter le même code, très différentes l'une de l'autre.

	aarch64 sous HVF	x86_64 sous TCG
Ce que c'est	exécution native, vitesse proche d'un vrai processeur	QEMU émule les instructions
Poignée de main dans l'invité	environ 0,58 ms (première mesure vers M13) ; dp-bench aujourd'hui 1941/s par cœur	environ 3,3 ms
Scénarios de fumée TLS	rapides	environ 15 minutes par scénario
MTE	non (absent de HVF)	x86 n'en a pas ; le marquage du heap ne fonctionne que pour un invité aarch64 sous TCG
À quoi cela sert	mesures réelles	exactitude : le chemin x86 est vérifié, les chiffres ne sont pas des performances

La règle est simple : les chiffres sous TCG sont de l'émulation et nous ne les citons pas comme des performances. Nous ne mesurons les performances x86 que sur un vrai VPS. C'est pourquoi les chiffres de cryptographie ci-dessus viennent du VPS Contabo, et non du Mac.

Leçons

• Mesurez sur une vraie machine avant d'optimiser. Notre première approche consistait à optimiser ce que nous croyions lent ; ce n'est que le diagnostic sur le VPS qui a montré 1,2 ms et où le temps passe exactement.
• La surcharge est une fonctionnalité à part. Un système rapide sous charge peut s'effondrer au-delà ; refuser doit coûter moins cher qu'accepter.
• Le profil surprend. Le plus grand gain isolé pour les petits messages ne se trouvait pas dans la cryptographie mais dans la copie de mémoire.
• Un disque sans système de fichiers demande plus de travail, pas moins. Ce qu'un système de fichiers apporte d'habitude (alignement, croissance, discard, copies, vérifications) nous devons l'écrire et le vérifier nous-mêmes, chaque étape avec injection de fautes.
• L'honnêteté dans les chiffres. Les mesures de mémoire sur un VPS partagé varient jusqu'à 10 fois d'une exécution à l'autre et ne disent rien du code, nous ne les citons donc pas. Les chiffres cryptographiques sont stables à environ 10%.
• La vitesse de développement n'est pas la maturité. Les tests et les ADR croissent avec le code, mais quatre jours ne font pas un vrai fonctionnement en production.

La suite

• H6 : SQLite isolé au niveau EL0, de sorte qu'une erreur dans la base n'ouvre pas le noyau.
• H7 : le reste de la sécurité du temps (NTS et traitement des sauts) ; SNTP n'est qu'un premier pas.
• X11 : comparaison avec Linux et Mosquitto sur le même VPS ; ce n'est qu'alors qu'il a un sens de parler de vitesse relative.
• Publication : première publication publique pour VPS (KVM), avec artefacts signés et instructions.
• Après la publication : bare metal (X12 à X16), IOMMU et Secure Boot, ainsi que le chiffrement du disque.

Le code est sur github.com/zeljan-alduk/urMQTT, et docs/PROGRESS.md reste l'unique source de vérité sur ce qui fonctionne réellement. Pré-alpha, comme avant ; les rapports de bogues et les signalements de sécurité, selon les indications de SECURITY.md, sont les bienvenus.