urMQTT op een echte VPS: ISO, handshake van 0,24 ms, eigen schijf en geharde kernel

In het eerste artikel over urMQTT beschreven we een unikernel die zelf een MQTT-broker is, tot en met mijlpaal M17, en we eindigden met drie beloften onder de kop "Wat volgt": één ISO die op meerdere platformen opstart, een rauwe schijf zonder bestandssysteem en veiligheid die je kunt aantonen in plaats van alleen te beweren. Niets daarvan was toen gebouwd. Dit artikel volgt wat er met elke belofte is gebeurd, in dezelfde volgorde als eerder: wat we hadden gepland, wat we hebben gebouwd, wat ons verraste en wat nog openstaat. Onderweg laten we ook zien hoeveel tijd het heeft gekost, want ook dat hoort bij het verhaal.

Eén opmerking vooraf: het project is nog steeds pre-alfa. De cijfers in dit artikel meten code en tests, geen rijpheid in productie, en de eerste release is bewust beperkt tot VPS'en met KVM. Bare metal komt later.

Hoe het er in de tijd uitzag

De eerste commit is van 28 oktober 2026 om 23:48 (M0). Op 31 oktober om 23:00 telt de repository 119 commits, verdeeld als 3, 39, 38 en 39 per kalenderdag. Meteen ook hoe dat mogelijk is: het project wordt gebouwd met Claude Code, en de commits dragen Co-Authored-By: Claude-trailers. Vier kalenderdagen geschiedenis betekenen niet dat één persoon in vier dagen 90.000 regels heeft geschreven; ze betekenen dat plan, implementatie, tests en ADR's in korte, gesloten lussen worden geschreven, en dat elke stap eindigt met hetzelfde controleritueel als eerder. De cijfers hieronder zeggen iets over de hoeveelheid code en tests, niet over hoeveel daarvan in de praktijk is beproefd.

De grafiek toont drie krommen die bijna samen stijgen, en dat is ook de bedoeling: tests en vastgelegde beslissingen volgen de code in plaats van erachteraan te lopen. De helling is het steilst op 29 oktober, toen het hele pad van kernel naar broker ontstond. Daarna komen er langzamer regels bij, maar de tests groeien sneller dan de code (27 tests op 1,6 duizend regels aan het begin, 739 op 89,8 duizend nu).

Mijlpaal	Commit	Tijdstip	Regels Rust	Tests	ADR's
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
vandaag	HEAD	31.10. 23:00	89.790	739	104

De regels zijn alle .rs-bestanden buiten vendor/ en fuzz/, de tests zijn #[test]-functies. Wat elk onderdeel heeft toegevoegd, volgens de datum in de git-geschiedenis:

Datum	Mijlpalen	Wat er is toegevoegd
29.10.	M0 tot M17	kernel, netwerk, TLS, broker, SQLite, meerdere cores, eigen TCP, hardening, reproduceerbare release
29.10. 's avonds en 30.10.	X0 tot X10, S1, H2, H3 (X0 begint op 29.10. om 20:54)	port naar x86_64, universele ISO, één schijf en zelfinstallerende ISO, TLS-controles, aanvallende clients
31.10.	O1 tot O4, T1, PERF, H4, H5, H9, S2 tot S6	inzicht en console via MQTT, live-modus en diagnostiek, SNTP, versnellingen, hardening, verificatie, toeleveringsketen, opslag

Belofte 1: één ISO voor meerdere platformen

Wat we hadden gepland. Eén bestand dat opstart op aarch64 UEFI, x86_64 UEFI en x86_64 BIOS. Wat we hebben gebouwd. De port naar x86_64 (X0 tot X10) en een universele ISO met de Limine-bootloader, één hybride ISO waarmee al die combinaties opstarten; smoke-tests starten hem op vier virtuele machines. Het menu heeft drie items: urMQTT (live-modus, draait vanuit RAM, schrijft niets naar schijf), installatie op de schijf van de machine waarop hij draait (de installatie schrijft GPT en gegevens en zet de machine daarna uit) en Diagnostiek (hardwaredetectie en metingen).

Het eerste echte doel was een VPS en geen fysieke computer: we hebben besloten dat de eerste release alleen VPS'en (KVM) ondersteunt en dat bare metal daarna komt. We testten op een Contabo-VPS met een AMD EPYC-processor (familie 23, Zen 1), 4 vCPU's en 8 GiB RAM, met een virtio-net-netwerk en een virtio-scsi-schijf. De eerste poging verraste ons: de ISO, gekoppeld als virtuele cd, startte het standaarditem op, de productie-image weigerde vanaf een alleen-lezen medium te draaien en herstartte, en we kregen een eindeloze lus van menu, kernel en reset zonder iets leesbaars. Tegenwoordig laat een fatale fout in de productie-image 60 seconden lang een bericht op de console staan voordat er wordt herstart, en vanaf een optisch medium meldt hij dat hij van een alleen-lezen medium is opgestart en stopt. De live-modus in RAM (O3) heeft dat probleem later voor het gewone geval omzeild.

Het diagnostiekitem is uit die ervaring voortgekomen: een machine die we niet kunnen zien, moeten we kunnen vragen wat erin zit. Het toont CPU, RAM, netwerk, schijven en PCI-apparaten, meet de doorvoer van geheugen, schijf en cryptografie, en schrijft dezelfde metingen als JSON naar de seriële poort. Schrijven naar schijf is alleen toegestaan in niet-toegewezen ruimte en pas nadat WIPE is ingetypt; op de opname hieronder is dat overgeslagen.

Wat openstaat. Echte hardware. Na de eerste release volgt bare metal (opstarten via USB, NVMe en AHCI, de netwerkkaart van een echte computer), samen met IOMMU en Secure Boot, want zonder IOMMU kan een kwaadwillend of defect apparaat over het hele geheugen schrijven. In deze versie beweren we daarover niets.

Handshake: van 1,2 ms naar 0,24 ms

De eerste meting van de diagnostiek op de VPS leverde een vervelend getal op: de mTLS-handshake, alleen de cryptografie aan de serverkant, duurde 1,2 ms. Op aarch64 gebruikten we al hardware-instructies voor AES en SHA, maar x86_64 had niets vergelijkbaars voor publieke sleutels: RustCrypto is overdraagbaar en constant-time, en dus ook traag. Drie wijzigingen brachten dat omlaag.

• Voor P-256 hebben we de nistz256-assembly uit OpenSSL en ring overgenomen (ADR-130), met tabellen met vaste basis voor het ondertekenen en voor het verifiëren van CA-handtekeningen (ADR-110, ADR-111).
• X25519 is herschreven naar vier 64-bits limbs met MULX/ADX-instructies (ADR-131).
• Daarna hebben we ook de rest geprofileerd (ADR-132, ADR-200).

Meting op de VPS (server, microseconden)	Ervoor	Erna
mTLS-handshake, alle cryptografie	1200	circa 240 (237 in de meting van de grafiek, 244 op de opname)
X25519	146	48
ECDSA-ondertekening	673	34
ECDSA-verificatie	309	90 (107 op de opname)
handshake, oude memcpy, dezelfde boot	278,8	229,4 (-17,7%)

De cijfers verschillen per run ongeveer 10%, dus hebben we een bereik genoteerd in plaats van één waarde. In totaal is dat ongeveer vijf keer minder CPU-tijd voor de handshake.

Wat we over memcpy hebben geleerd. Toen de cryptografie was gedaald, liet het profiel iets zien wat we niet verwachtten: de mem*-functies (memcpy, memmove, memset) kostten 7% van de handshake, 13 tot 39% van het pad van een TLS-record (39% voor 64 B, 13% voor 4 KiB) en 17 tot 34% van de verdeling van een PUBLISH. We hebben ze vervangen door SSE2-assembly voor x86_64 (ADR-200), met differentiële tests tegen de referentie-implementatie voor alle groottes, uitlijningen en overlappingen. Per aanroep is dat 55 tot 75 cycli tegen 7 tot 12 voor 1 tot 64 bytes.

Pad	Aandeel mem* ervoor	Sneller erna
handshake	7%	17,7%
TLS-record 64 B	39%	26,4%
TLS-record 256 B	37%	19,6%
TLS-record 1 KiB	24%	16,1%
TLS-record 4 KiB	13%	6,6%
verdeling van berichten	17 tot 34%	7 tot 34%

De grafiek lezen: hoe kleiner het record, hoe groter het deel van de tijd dat naar kopiëren gaat, en dus hoe groter de winst. Voor kleine berichten, het grootste deel van het MQTT-verkeer, is dat waar het om gaat.

Wat dit niet betekent. Op native x86_64 hebben we alleen OpenSSL 3.5.5 gemeten als referentie voor de assembly (ADR-130), niet als productvergelijking. De vergelijking van Linux plus Mosquitto op dezelfde VPS (taak X11) hebben we nog niet gedaan. Daarom beweren we niet dat urMQTT sneller is dan Linux: dat is niet gemeten. De cijfers hierboven vergelijken urMQTT met zichzelf.

Overbelasting was het tweede resultaat. Op de VPS, vanaf één Mac (RTT 35 ms), leverden 128 clients 618 handshakes per seconde op, 256 clients 393 en 512 clients 67, met duizenden geweigerde verbindingen. Dat was geen plateau maar een instorting. De oorzaken hebben we in de code gevonden (twee zijn bevestigd in QEMU/HVF, op de VPS konden ze niet worden nagebootst), meerdere tegelijk: een geweigerde verbinding stuurde de client via het volgende segment met een geldige SYN-cookie weer naar binnen, het weigeren met een RST zei de client meteen opnieuw te proberen, en de ontvangst was O(wachtrij). De fix (ADR-080 tot ADR-082) laat een SYN vallen die toch niet zou worden geaccepteerd, onthoudt geweigerde stromen, houdt de ontvangst in O(1) en telt handshakes per core. Mogelijk (hypothese, niet gecontroleerd) lag een deel van de oorzaak ook bij de client: de belastingstool sloot als eerste af, waardoor één Mac met 16.384 efemere poorten en een TIME_WAIT van 30 seconden beperkt was tot ongeveer 550 verbindingen per seconde. Daarom hebben we het echte plafond van de server nog niet gemeten.

Belofte 2: een rauwe schijf, maar zorgvuldig

Wat we hadden gepland. Onze eigen indeling zonder bestandssysteem behouden en alles toevoegen wat een bestandssysteem normaal biedt: uitlijning, groei, discard, back-ups en controles. Waarom geen bestandssysteem. Daarover hebben we gediscussieerd en het besluit is bevestigd: urMQTT schrijft één database, één telemetriejournaal en zijn eigen metadata, heeft geen mappen, rechten of bestandsnamen nodig, en elke extra laag zou meer code in het vertrouwde deel zijn en nog een manier waarop een schrijfactie stilletjes verdwijnt. De schijf is GPT met een ESP-partitie en één urMQTT-gegevenspartitie, met daarop onze eigen indeling.

Wat we hebben gebouwd (S2 tot S6).

• Indeling v2 (S2). Schijftopologie, uitlijning op 1 MiB of de optimale I/O-grootte, hele fysieke blokken, een A/B-paar superblokken met een generatie (ADR-140). Indeling v1 wordt door de kernel geweigerd met een duidelijke melding, en gemigreerd door de offline tool urmqtt-disk migrate (ADR-141): standaard is dat een proefrun, er wordt eerst gekopieerd en pas daarna omgeschakeld, met rollback en foutinjectie bij elke schrijfactie.
• Groei (S3). Bij het opstarten kan de schijf groeien (nooit krimpen), en op virtio-blk ook tijdens bedrijf, via de interrupt voor configuratiewijziging (ADR-142, ADR-143).
• Discard en write-zeroes (S4). Thin-provisioned schijven geven ruimte terug aan de host. In een test daalde het qcow2-bestand op de host van 62 naar 16 MiB nadat telemetriesegmenten waren verlopen, en het herstel vertrouwt nooit op inhoud die is weggegooid.
• Back-up van de database op schijf (S5). Een A/B-kopie met de online backup-API van SQLite in stappen van 16 pagina's: de langste stap is 4,6 ms tegen 445 ms wanneer in één aanroep wordt gekopieerd. Commits tijdens het kopiëren hadden een maximum van 2,4 ms tegen 2,2 ms zonder kopie. Als quick_check bij het opstarten faalt, wordt de database uit de kopie hersteld.
• Scrubben en begrensd opstarten (S6). De scrubber leest de schijf met een begrensd I/O-budget en meldt beschadigde records, en het opstarten leest alleen het nieuwste segment van elke partitie, zodat de opstarttijd niet meegroeit met de grootte van het telemetriegebied. Daarmee hebben we een probleem opgelost dat we vooraf hadden uitgerekend: op een grote schijf zou volledig herstel minuten tot tientallen minuten duren.

De hele groep smoke-tests voor opslag slaagt op beide architecturen: 79 geslaagd, 0 mislukt, op aarch64 onder HVF en op x86_64 onder TCG. We hebben ook gemeten dat S4 de database niet heeft vertraagd: 53,3 duizend inserts per seconde in batches ervoor en erna, zonder meetbaar verschil.

Wat ons verraste. Hoeveel van een "eenvoudige" indeling uit randgevallen bestaat: virtio-scsi en virtio-blk melden de topologie op verschillende manieren, en een onvolledige schrijfactie midden in een migratie moet altijd minstens één geldige versie achterlaten. Daarom is elke schrijfactie op het pad van migratie en groei door foutinjectie gegaan.

Wat openstaat. SQLite-pagina's hebben geen controlesom, dus een gewijzigde bit binnen een waarde in een rij ontdekt de database niet; telemetrierecords en de inhoud van kopieën hebben een CRC en worden wel ontdekt. Schijfversleuteling (S7) is niet af.

Belofte 3: aantoonbaar veilig, voor zover we het redden

Hardening (H4). De allocator wist vrijgegeven geheugen en controleert het bij hergebruik, detecteert dubbel vrijgeven, bindt de pointers van de vrije lijst met XOR en nult sleutels bij het vrijgeven (ADR-170). Stackbescherming (-Zstack-protector=strong, 1315 functies, en SQLite met -fstack-protector-strong, ADR-171). Foutrapporten in productie bevatten geen registers of adressen (ADR-172). KASLR op beide architecturen: de kernel is PIE en Limine verschuift hem met ongeveer 19 bits, en heap, stacks en het MMIO-venster worden willekeurig geplaatst (ADR-173). Op aarch64 markeert MTE de heap (ADR-174), maar alleen onder TCG: HVF en x86 hebben het niet. kCFI hebben we beoordeeld en niet overgenomen omdat de compiler op de vastgezette nightly crasht met een interne fout; IOMMU is uitgesteld samen met bare metal (ADR-175, ADR-176).

De prijs is gemeten, niet aangenomen. Op het handshake-pad (dp-bench, aarch64 HVF, volledige TLS 1.3 + mTLS + CONNECT-handshakes):

Stap	1 core	4 cores	Wijziging
zonder hardening	1941	7620
+ allocator	1898	7429	-2,2% tot -2,5%
+ stackbescherming	1845	7243	samen -4,9% tot -5%
+ PIE en tags	circa 1800	circa 6750	op een belaste computer, ruis

In totaal is de prijs op het handshake-pad dus ongeveer 5% voor de onderdelen die schoon zijn gemeten, en met PIE en tags komt het uit op ongeveer 7% op één en ongeveer 11% op vier cores, al is die meting ruisachtig. We vinden dat acceptabel, maar we hebben het niet herhaald op de x86_64-VPS.

Het is de moeite waard om dit te vergelijken met het cijfer uit het eerste artikel (862 handshakes per seconde op één core). Dezelfde tool geeft vandaag, met de hardwareversnelde cryptografie op aarch64 (X0b) en een reeks versnellingen die sindsdien zijn gekomen, 1941 vóór hardening. We hebben de bijdrage van elke wijziging niet geïsoleerd, dus over de oorzaak beweren we niets.

Hoe het is gecontroleerd, en wat niet. H5 voegde Miri toe op een deel van de host-crates, Kani-bewijzen, sanitizers, een model-fuzzer voor de ACL en dekkingsrapporten. Kani heeft record_len in TLS bewezen, parse in TCP en twee rekenkundige onderdelen van het timerwiel. Niet bewezen (time-out): beide MQTT-decoders, beide configuratieparsers en het gedrag van het timerwiel; de CI-taak voor Kani blokkeert daarom nog niet. Miri kan geen assembly uitvoeren. Toeleveringsketen (H9): een CycloneDX-SBOM met 215 componenten, cargo-vet slaagt met 39 volledig beoordeelde en 140 uitzonderingen, en cargo-deny is zo geconfigureerd dat advisories over kwetsbaarheden als CI-fout tellen (die CI-taken zijn tot nu toe alleen lokaal gecontroleerd, niet op GitHub, en de negatieve test is niet uitgevoerd), plus VULNERABILITY-HANDLING.md. De eerlijke stand: van 67 kernel-gelinkte versies van crates van derden zijn er 53 uitzonderingen en geen beoordelingen. Vet bewijst dat de verzameling afhankelijkheden niet zonder zichtbaar verschil kan veranderen, niet dat de TCB is nagekeken. Een eigen beoordeling van geen enkele crate hebben we geschreven.

SNTP (T1) is in dat opzicht een klein veiligheidsverhaal: het is optioneel, alleen naar privé-IPv4-servers, met een maximale sprong en de voorwaarde dat de bronnen het eens zijn (mediaan, meerderheid binnen één seconde). Een klok die iedereen op het pad kan verzetten, is geen klok die we mogen vertrouwen bij de geldigheid van certificaten.

Op de Mac: aarch64 native en x86_64 via emulatie

We ontwikkelen op een Mac, en die heeft twee manieren om dezelfde code uit te voeren, die erg verschillend zijn.

	aarch64 onder HVF	x86_64 onder TCG
Wat het is	native uitvoering, snelheid dicht bij een echte processor	QEMU emuleert instructies
Handshake in de gast	circa 0,58 ms (voor het eerst gemeten rond M13); dp-bench vandaag 1941/s per core	circa 3,3 ms
TLS-smoke-scenario's	snel	circa 15 minuten per scenario
MTE	nee (HVF heeft het niet)	x86 heeft het niet; heap-tagging werkt alleen voor een aarch64-gast onder TCG
Waarvoor	echte metingen	juistheid: het x86-pad wordt gecontroleerd, de cijfers zijn geen prestaties

De regel is eenvoudig: cijfers onder TCG zijn emulatie en die citeren we niet als prestaties. x86-prestaties meten we alleen op een echte VPS. Daarom komen de cryptografiecijfers hierboven van de Contabo-VPS en niet van de Mac.

Lessen

• Meet op een echte machine voordat je optimaliseert. Onze eerste aanpak was optimaliseren wat we traag dachten te zijn; pas de diagnostiek op de VPS liet 1,2 ms zien en waar de tijd precies heen gaat.
• Overbelasting is een aparte eigenschap. Een systeem dat onder belasting snel is, kan erboven instorten; weigeren moet goedkoper zijn dan accepteren.
• Het profiel verrast. De grootste afzonderlijke winst voor kleine berichten zat niet in de cryptografie maar in het kopiëren van geheugen.
• Een schijf zonder bestandssysteem vraagt meer werk, niet minder. Wat een bestandssysteem normaal biedt (uitlijning, groei, discard, kopieën, controles) moeten we zelf schrijven en controleren, elke stap met foutinjectie.
• Eerlijkheid in cijfers. Geheugenmetingen op een gedeelde VPS variëren tot 10 keer tussen runs en zeggen niets over de code, dus noemen we ze niet. De cryptocijfers zijn stabiel tot ongeveer 10%.
• Ontwikkelsnelheid is geen rijpheid. Tests en ADR's groeien mee met de code, maar vier dagen zijn geen echte productie.

Wat volgt

• H6: SQLite geïsoleerd op EL0-niveau, zodat een fout in de database de kernel niet openzet.
• H7: de rest van de tijdveiligheid (NTS en het afhandelen van sprongen); SNTP is slechts een eerste stap.
• X11: vergelijking met Linux en Mosquitto op dezelfde VPS, pas dan is het zinvol om over relatieve snelheid te praten.
• Release: de eerste openbare release voor VPS (KVM), met ondertekende artefacten en instructies.
• Na de release: bare metal (X12 tot X16), IOMMU en Secure Boot, en schijfversleuteling.

De code staat op github.com/zeljan-alduk/urMQTT, en docs/PROGRESS.md blijft de enige bron van waarheid over wat er werkelijk werkt. Pre-alfa, net als eerder; foutmeldingen en beveiligingsmeldingen volgens de instructies in SECURITY.md zijn welkom.