Der Hinweis vorab bleibt derselbe: Das Projekt ist Pre-Alpha, die erste Veröffentlichung gilt nur für VPS mit KVM, und die Zahlen messen Code, Tests und bestimmte Versuche, nicht die Reife in der Produktion.

Wie das in der Zeit aussah

Seit dem vorigen Text (31.10. um 23:00 Uhr) bis heute (1.11. um 20:41 Uhr) sind im Repository 59 neue Commits dazugekommen, insgesamt 178. Alle sind an einem einzigen Kalendertag entstanden, deshalb gilt dieselbe Warnung wie zuvor: Das Projekt wird mit Claude Code gebaut (die Commits tragen Co-Authored-By: Claude), Plan, Code, Tests und ADRs entstehen in kurzen, geschlossenen Schleifen, und die Zahlen unten sagen etwas über die Menge an Code und Prüfungen aus, nicht darüber, wie viel menschliche Arbeit darin steckt.

Die Zahlen sind mit derselben Methode berechnet wie im letzten Text: alle .rs-Dateien außerhalb von vendor/ und fuzz/, #[test]-Funktionen, Überschriften ## ADR- in docs/DECISIONS.md.

Es wurde parallel auf mehreren Branches gearbeitet, daher ist die Reihenfolge der Commits nicht strikt die Reihenfolge der Arbeit. Die ADRs sind bis 232 nummeriert, aber die Nummerierung hat Lücken (ein Teil wurde beim Zusammenführen von Branches umbenannt); wir zählen die Überschriften, nicht die größte Nummer. Veröffentlichungen: v0.2.0 (1.11., 18:45 UTC) und v0.2.1 (1.11., 20:22 UTC), beide als Pre-Release gekennzeichnet.

H6: SQLite im Benutzermodus

Was wir geplant haben. SQLite sind 254 268 Zeilen C, die die Datenbank, das WAL und das Journal von der Festplatte parsen, und die Festplatte kann manipuliert oder verändert sein. Bis dahin lief es im Kernel, mit den Rechten des Kernels. Was wir gebaut haben (ADR-210 bis ADR-212): SQLite, seine libc-Teile und der Heap wurden in ein eigenes Programm verschoben, dbworker, das auf EL0 (aarch64) bzw. Ring 3 (x86_64) in einem eigenen Adressraum läuft. Der Kernel linkt SQLite nicht mehr. Der Worker spricht mit dem Kernel über ein gemeinsames Speicherfenster und zwölf Systemaufrufe, und jede zurückgegebene Länge und jeder Offset wird vor der Verwendung geprüft. Ein Fehler im Worker (unzulässiger Zugriff, undefinierte Instruktion, überschrittenes Zeitbudget von 30 s) beendet den Aufruf, der Worker wird neu gestartet und die Datenbank wird aus dem WAL geöffnet wie beim Hochfahren; nach 5 Neustarts pro Minute wird der Speicher für defekt erklärt, statt endlos neu zu starten.

Die Kosten, gemessen auf aarch64 unter HVF, dieselbe VM, Kernel mit eingebautem SQLite gegenüber Kernel mit Worker, je sechs abwechselnde Läufe:

Die Schreibvorgänge auf die Festplatte (1 572) und die Flushes (319) sind identisch, wie es sein muss. Nicht isoliert ist Folgendes: Der Kernel vertraut weiterhin dem, was der Worker zurückgibt, nach Prüfung der Form. Ein kompromittierter Worker kann lügen (zum Beispiel eine leere Liste widerrufener Zertifikate zurückgeben und sie damit "entwiderrufen"), aber er kann weder den Speicher des Kernels noch TLS-Schlüssel noch Ticket-Schlüssel lesen. Es gibt kein KPTI, daher sind Lecks vom Typ Spectre/Meltdown nicht verhindert, und wir behaupten dazu nichts; der PAC-Schlüssel wird von EL0 und EL1 geteilt. Auf x86_64 haben wir die Umschaltkosten auf KVM nicht gemessen (unter TCG wäre die Zahl sinnlos), und das Fuzzing von Worker und Protokoll selbst ist nicht abgeschlossen. Die Testsuite für den Speicher (79 Szenarien, jedes lässt SQLite im Worker laufen) läuft auf aarch64 HVF und x86_64 TCG durch, auf aarch64 TCG 76 (eines wird übersprungen, weil TCG kein MSI-X hat).

H7 ist abgeschlossen, aber nicht so, wie wir es angekündigt hatten. Die Untergrenze der Zeit (ADR-050) und SNTP mit Konsens (T1) decken den Umfang von H7 ab; NTS (RFC 8915) bleibt außerhalb des Umfangs und ist als verbleibendes Risiko vermerkt, nicht als etwas, das funktioniert. Wir halten die Zeitsicherheit nicht für "gelöst", sondern ihren beweisbaren Teil für fertig.

Neue Netzwerkoption. Contabo vergibt kein DHCP an ein benutzerdefiniertes ISO, daher brauchte der VPS bisher ein anderes Image als die Labor-VM. Jetzt fragt network.mode = "auto" (ADR-214) zuerst DHCP, und wenn innerhalb der Frist (dhcp_timeout_s, Standard 15 s) kein Lease kommt oder er verloren geht, wird die vorgegebene statische Adresse verwendet. Manuell auf QEMU ausprobiert (mit DHCP nutzt es den Lease, ohne Netzwerk fällt es nach 5 s auf die statische Adresse zurück); ein Smoke-Szenario dafür gibt es noch nicht.

X11: Vergleich mit Mosquitto auf demselben VPS

Dieselbe Art von Maschine wie im letzten Text (Contabo, 4 vCPU AMD EPYC, 8 GiB), Last von einem Linux-Host 15 ms entfernt, gegenseitiges TLS 1.3 mit denselben Zertifikaten auf beiden Seiten, Mosquitto 2.0.21 auf Debian 13 ohne Persistenz. Methode und Entscheidungen stehen in ADR-213, Rohdaten in docs/perf-results/. Median aus drei Läufen.

Was das bedeutet und was nicht. Die Handshakes sind Untergrenzen für beide Server: Der Lastgenerator ist eine geteilte VM mit 60 bis 70 % gestohlener CPU-Zeit und war bei 128 Threads nahe an seiner eigenen Grenze, während die Arbeitskerne von urMQTT nur zu 12 bis 13 % ausgelastet waren. Das Verhältnis bei 128 Clients (etwa das 2,2-Fache) ist am aussagekräftigsten; bei 32 und 64 misst es überwiegend das Warten der Clients. Die Speicherzahlen zählen nicht dasselbe (Kernel-Heap gegenüber RSS des Prozesses), daher ist "etwa 50-mal weniger" eine Größenordnung, kein genaues Verhältnis. Die Latenz von 14 ms ist eine Netzwerkrunde (etwa 15 ms), also "keine messbare Zeit des Brokers"; die Ausreißer (p99 etwa 100 bis 200 ms) werden bei beiden Brokern von den geteilten Hosts dominiert. Unterschiede unter etwa 20 % behaupten wir nicht.

Was nicht zu unseren Gunsten ausfiel und in den Tabellen blieb: Ein TCP-Fluss durch urMQTT trug 2- bis 8-mal weniger als durch Mosquitto, mit Schwankungen von null bis 7,7 Tausend Nachrichten pro Sekunde zwischen den Läufen, und der 20-ms-Watchdog des Handlers hat lebende Verbindungen getrennt, wenn der Hypervisor die vCPU angehalten hat (in der Produktionseinstellung action = "drop", 6 bis 8 Verbindungen pro Lauf bei QoS-0-Flut). Beides ist im nächsten Abschnitt beschrieben, denn beides hatte Ursachen in unserem Code.

Warum der Einzelfluss langsam war: Ursachen, keine Ausreden

Am einfachsten wäre gewesen, "geteilter VPS" zu sagen. Das haben wir nicht getan, sondern auf demselben VPS und mit derselben Methode nach Ursachen gesucht. Es wurden fünf Ursachen gefunden, vier im Datenpfad und eine im Watchdog (ADR-221 bis ADR-224):

Die Anhaltephasen sind real: Auf diesem VPS hatten die Kerne 0 bis 2 einen Median von 36 bis 80 verspäteten Ticks pro 5 Sekunden, und die schlimmste Anhaltephase im Fenster lag im Median bei etwa 70 ms und bis zu 0,9 s (Kern 3, Datenbank und Journal: bis zu 1,55 s), während der Host keine gestohlene Zeit meldet (host steal 0 us). Deshalb brauchte der Watchdog eine zweite Uhr, kein größeres Budget.

Watchdog: 148 getrennte Verbindungen in 30 belasteten Läufen vorher, 0 in 24 Läufen nachher; auf einem lokalen Gerät, das Frames verzögert und verliert, hat ein Fluss von 64 B bei 0,1 % Verlust mit 14,3k Nachrichten/s (Kernel von X11) jetzt 41,0k, und bei 0,5 % von 5,0k auf 17,7k.

Was das nicht sagt. urMQTT ist bei einem Einzelfluss weiterhin nicht schneller als Mosquitto: Bei 64 B veröffentlicht es etwa 80 % von dessen Geschwindigkeit und liefert etwa 40 % zu, weil es QoS 0 verwirft, wenn der Fluss des Subscribers langsamer ist als der des Publishers (Mosquitto reiht ohne Grenze ein). Bei 1 KiB in der 16-Paar-Flut liegt Mosquitto um etwa 15 % vorn, was im Rauschen liegt. Der Generator war wieder eine geteilte VM mit 58 bis 77 % gestohlener Zeit. Die zweite Runde (Heap-Sperren außerhalb des Datenpfads, SACK auf der Sendeseite und anderes) liegt auf dem nicht integrierten Branch perf-single-flow-wip; ihre Zahlen sind noch keine Behauptungen, und wir nennen sie hier nicht.

Ein Versprechen, das wir nicht gegeben, aber eingelöst haben: Konfiguration ist Daten

Bisher war jede Konfiguration ein neuer Build: Schlüssel und Limits waren im Image eingebaut. C1 dreht das um (ADR-215 bis ADR-219): Der Kernel wird einmal gebaut, und die Konfiguration ist Daten.

• Der Blob urmqtt-cfg (C1a): eine versionierte, kanonische Darstellung (Felder in aufsteigender Reihenfolge der Tags, SHA-256-Fingerabdruck, optionale getrennte Ed25519-Signatur), 70 Felder mit Standardwerten und Grenzen, ein Decoder, der alles Ungültige ablehnt.
• Der Kernel liest ihn als Limine-Modul (C1b), vor allem anderen, auf aarch64 und x86_64. Es gibt einen veröffentlichten Kernel für jedes ENV außer dev (die aarch64-ELFs für release, prod und bench haben denselben SHA-256; nur auf aarch64 geprüft). Der veröffentlichte Kernel lehnt eine Entwicklungskonfiguration ab, und ohne Konfiguration schreibt er "refusing to serve" und bedient nichts.
• Die installierte Festplatte trägt die Konfiguration, und das Update behält sie (C1c).
• urmqtt-config und die ISO-Vorlage (C1d): pack, show, verify, und pack --iso ersetzt beide Exemplare des Konfigurationsplatzes und 24 Modul-Digests in einem fertigen ISO. Das Ergebnis ist Byte für Byte dasselbe wie das ISO, das mkiso.sh --config baut. Die Vorlage der Version v0.2.0 hat 63 111 168 Bytes.
• Vertrauenserklärung (ADR-219): Ein konfiguriertes Image gibt beim Hochfahren den Fingerabdruck der Konfiguration aus (config: fingerprint ...), und die Signatur ist optional und standardmäßig ausgeschaltet. Ein verändertes ISO hat keinen offiziellen Digest; der Fingerabdruck ist die Möglichkeit zu sehen, was darin steckt.

Der Builder auf aldo.tech

Dasselbe, was urmqtt-config pack --iso tut, tut auch die Webseite, mit demselben Code: die Werkzeugbibliothek, kompiliert zu WebAssembly (1,06 MB, ohne Importe und ohne unsafe-Block). Die Seite ist unter aldo.tech/de/produkte/urmqtt-builder/ und in allen 15 Sprachen der Website verfügbar (zum Beispiel hr).

• Nichts verlässt den Browser. Zertifikate, private Schlüssel und das fertige ISO bleiben auf dem Computer; die Seite lädt nur die Release-Dateien von dieser Website, es gibt kein Tracking und keine Skripte von Dritten. Im Live-Test trug keine Anfrage Schlüsselmaterial.
• Release-Mirror (ADR-227): Stündlich (systemd-Timer, niedrige Priorität) kopiert er die Releases von GitHub, prüft jedes vor der Veröffentlichung, und die Seite im Browser prüft die Signatur von SHA256SUMS mit einem in die Seite eingebauten Schlüssel, erst dann schreibt sie die Konfiguration in die Vorlage. Eine fehlgeschlagene Prüfung blockiert den Download.
• Einfach als Standard, erweitert bei Bedarf (ADR-232): Der erste Bildschirm besteht aus drei Schritten (wo es läuft, Ihre Zertifikate, Name des Images). Ein einziges Feld zum Hineinziehen von Dateien sortiert Zertifikat, Schlüssel und CA nach Inhalt. Die erweiterte Ansicht öffnet jedes der 70 Felder, die Suche, Import und Export von TOML; beide Ansichten bearbeiten denselben Zustand. Die Vorlage (63 MB) wird heruntergeladen, während der Benutzer das Formular ausfüllt. Im Live-Test, mit Test-Mirror und Testschlüssel, dauerte der Bau des ISO im Browser 5 bis 18 s.

Emulator, optional. Neben "ISO herunterladen" steht "Im Emulator ausprobieren": QEMU, kompiliert zu WebAssembly, startet das soeben gebaute Image in einem Browser-Tab. Vor dem Klick wird nichts davon heruntergeladen (beim ersten Mal etwa 3 MB). Der Emulator ist nur BIOS, ohne Netzwerk (damit der Verkehr des Benutzers nicht über einen Vermittler läuft und das "nichts verlässt den Browser" verletzt), braucht etwa 1,5 GB Speicher und einen Desktop-Browser (getestet mit Chrome; Firefox und Safari nicht). Darin erreicht urMQTT URMQTT READY nach etwa 8 s (mit übersprungenem Countdown) und gibt denselben Konfigurationsfingerabdruck aus wie die Seite, was der Beweis ist, dass genau diese Konfiguration hochgefahren wurde. Das Hochfahren ist etwa 2-mal langsamer als im nativen QEMU auf demselben Mac (0,82 s gegenüber 1,9 s), und die Kryptografie etwa 58-mal langsamer, weil die Hardware-Instruktionen emuliert werden. Deshalb ziehen wir aus dem Emulator keinerlei Aussagen zur Geschwindigkeit, und die Seite sagt das vor dem Start. Beim Build mussten vier Bytes in der .wasm gepatcht werden wegen eines Fehlers bei der Übersetzung der Instruktion POPCNT im ursprünglichen Emulator (wir haben ihn noch nicht gemeldet); der Emulator selbst steht unter der GPL, mit Angebot des Quellcodes.

Einfaches MQTT, nur für Netzwerke, denen Sie vertrauen

Einfaches MQTT (TCP 1883, ohne TLS) ist im IoT sehr verbreitet: Es ist der Standard in Mosquitto, in den meisten Firmwares für Arduino und ESP, in Tasmota, Zigbee2MQTT und Home Assistant, und es wird auch in segmentierten Industrienetzen, hinter VPNs und in privaten LANs verwendet, auch auf Geräten ohne Uhr (Zertifikate brauchen ein Datum), ohne genug Flash oder Prozessor für TLS. Über ein nicht vertrauenswürdiges Netzwerk ist es nicht akzeptabel: Wer auf dem Weg sitzt, liest und verändert den Verkehr. Deshalb ist P1 (ADR-229 bis ADR-231) eine ausdrückliche, begrenzte Wahl, standardmäßig ausgeschaltet, und der TLS-Port bleibt; TLS wird dadurch nicht abgeschaltet, der einfache Port kommt zusätzlich.

• Eine Liste erlaubter Netzwerke ist Pflicht (allow_from, CIDRs) und wird beim SYN geprüft: Außerhalb der Liste gibt es kein SYN-ACK und keinen Zustand. Das gesamte Internet (0.0.0.0/0) verlangt eine eigene ausdrückliche Option.
• Drei Anmeldearten: Passwort (Standard, wenn eingeschaltet; PBKDF2-HMAC-SHA-256, Salt, 10 000 Iterationen, Vergleich in konstanter Zeit, Sperrung pro Adresse), anonym (eine konfigurierte Identität mit eigener ACL) und nach Adresse (ip). Der Builder hasht das Passwort im Browser und hält nur den Digest im Speicher.
• Weniger Rechte als mTLS: Ein einfacher Client hat nie Service-, Operator- oder Verwaltungsrechte, hat kein $SYS und keine Konsole, hat eigene Sitzungen ($plain/<identität>/<client-id>, nur saubere), und eigene Limits und das Register erlaubter Clients binden ihn weiterhin.
• Was verloren geht, steht in SECURITY.md: Vertraulichkeit, Integrität, Authentizität des Brokers und die Wiedereinspielung einer aufgezeichneten Anmeldung. Das lässt sich durch Konfiguration nicht beheben; so ist es ohne TLS.

Gemessen auf einem Laptop (Apple Silicon, HVF, QEMU-Benutzernetzwerk), 16 Paare, 64 B, drei Läufe zu je 10 s: Bei 8 000 Nachrichten pro Sekunde liefern der TLS- und der einfache Pfad alle Nachrichten mit gleicher Latenz (p50 0,17 ms gegenüber 0,13 bis 0,18 ms), neue Verbindungen pro Sekunde: TLS etwa 2 600 bis 2 750, anonym einfach etwa 4 900 bis 7 800, und die Passwort-Anmeldung ist der teure Teil: Ein PBKDF2 kostet etwa 2,5 ms, daher ist die Zahl neuer Anmeldungen auf etwa 200 pro Datenkern und Sekunde begrenzt (gemessen 308 bis 342 auf zwei Kernen). Die Flut auf dieser Maschine ist kein stabiles Instrument (20k bis 440k zugestellt pro Sekunde zwischen den Läufen), und wir ziehen daraus keinen Schluss. Der Vergleich des einfachen Pfads mit Mosquitto auf dem VPS ist noch nicht gemacht. Tests: Smoke-Gruppe plaintext 7 von 7 auf aarch64 HVF und auf x86_64 TCG, neues Fuzz-Ziel plain_input (2,3 Millionen Läufe ohne Befund).

Fehler, die der Live-Betrieb gefunden hat

Zwei Dinge haben nicht die Tests entdeckt, sondern die erste Inbetriebnahme auf der echten Website:

• Die Seite suchte die Release-Dateien ein Verzeichnis zu hoch, daher antwortete jede Signaturprüfung mit 404 (Korrektur 13af301). Der Test benutzte einen Test-Mirror unter einem anderen Pfad.
• Die Tastatur des Emulators erreichte den Gast nie: Die Ursache war nicht eine falsche Übersetzung der Tasten, sondern dass der Dialog gar nicht auf Tasten hörte (Korrektur in ADR-232, mit einem Boot-Eintrag ohne Tasten).

Lektionen

• Suchen Sie die Ursache, geben Sie nicht der Umgebung die Schuld. Die meisten Schwächen des Einzelflusses und alle getrennten Verbindungen lagen bei uns; der Hypervisor ist real, aber er musste gemessen und nicht vermutet werden.
• Ein Vergleich mit einem anderen Produkt muss auch die Verluste enthalten. Eine Tabelle, in der nur unsere Siege stehen, wäre kein Vergleich.
• Das Messinstrument hat Grenzen. Ein geteilter Generator mit 60 bis 70 % gestohlener Zeit verändert, was die Zahlen bedeuten; deshalb schreiben wir "Untergrenze" und behaupten keine Unterschiede unter 20 %.
• Isolation ist kein Beweis. SQLite in EL0 verkleinert, was ein Fehler darin anrichten kann, nicht das, wobei es lügen kann.
• Eine echte Installation findet, wonach Tests nicht suchen: einen falsch zusammengesetzten Pfad und Tasten, auf die niemand hört.

Was noch nicht bewiesen ist

• Der Signaturschlüssel der Releases ist vorerst ein Testschlüssel; v0.2.0 und v0.2.1 sind Pre-Releases, und die Images dazu sind Entwicklungs-Images mit Testzertifikaten (außer der Vorlage, die ohne Konfiguration ist).
• 13 Übersetzungen der Builder-Seite (und dieses Textes) hat eine KI geschrieben, und sie wurden durch Tests und Stichproben geprüft, nicht von Muttersprachlern.
• Der Vergleich mit Mosquitto ist eine Sitzung, ein Pfad und ein geteilter Generator, auf einem geteilten VPS; Unterschiede unter 20 % sind keine Behauptungen.
• Der einfache Pfad wurde weder auf dem VPS noch gegen Mosquitto gemessen.
• Lighthouse auf der neuen einfachen Ansicht ist nicht bestätigt (alte Ansicht: Barrierefreiheit 95 oder mehr).
• Bare Metal, x86_64-Kosten des Workers auf KVM, Firefox und Safari für den Emulator: nicht gemessen.

Was als Nächstes kommt

• D1: öffentlicher Demo-Broker. Den Emulator aus dem Browser können wir nicht öffentlich machen: Er lebt im Tab eines einzelnen Besuchers, ist 20- bis 100-mal langsamer als KVM, hat kein eingehendes Netzwerk und verschwindet mit dem Schließen des Tabs; das Internet in den Browser eines Fremden umzuleiten, wäre außerdem Missbrauch. Möglich ist ein echter Demo-Broker: urMQTT auf einem VPS hinter einem Namen auf aldo.tech, mit veröffentlichter Test-CA, strikter ACL und kleinen Limits. Das ist vorerst nur eine Idee, kein Bau, und braucht eine ausdrückliche Zustimmung zur öffentlichen Bereitstellung.
• Zweite Runde für den Einzelfluss (Branch perf-single-flow-wip): erst, wenn sie auf dem VPS gemessen und zusammengeführt ist.
• Den einfachen Pfad gegen Mosquitto auf dem VPS, Anmeldung und Widerruf von Konten für einfaches MQTT über den signierten Verwaltungskanal.
• Nach der Veröffentlichung: Bare Metal (X12 bis X16), IOMMU und Secure Boot, Festplattenverschlüsselung.

Der Code liegt auf github.com/zeljan-alduk/urMQTT, und docs/PROGRESS.md bleibt die einzige Quelle der Wahrheit darüber, was tatsächlich funktioniert, docs/PERFORMANCE.md darüber, was gemessen wurde. Pre-Alpha, wie zuvor; Fehlermeldungen und Sicherheitsmeldungen nach den Hinweisen in SECURITY.md sind willkommen.

Ein Hinweis vorab: Das Projekt ist weiterhin Pre-Alpha. Die Zahlen in diesem Text messen Code und Tests, nicht die Produktionsreife, und die erste Veröffentlichung ist bewusst auf VPS mit KVM beschränkt. Bare Metal bleibt für später.

Wie das in der Zeit aussah

Der erste Commit entstand am 28. Oktober 2026 um 23:48 Uhr (M0). Bis zum 31. Oktober um 23:00 Uhr sind es 119 Commits im Repository, verteilt auf die Kalendertage als 3, 39, 38 und 39. Wie das möglich ist, sagen wir gleich dazu: Das Projekt wird mit Claude Code gebaut, und die Commits tragen Co-Authored-By: Claude-Trailer. Vier Kalendertage Historie bedeuten nicht, dass eine einzelne Person in vier Tagen 90 000 Zeilen geschrieben hat; sie bedeuten, dass Plan, Implementierung, Tests und ADRs in kurzen, geschlossenen Schleifen entstehen und jeder Schritt mit demselben Prüfritual endet wie zuvor. Die Zahlen unten sagen etwas über die Menge an Code und Tests aus, nicht darüber, wie viel Arbeitsaufwand in der Realität dahintersteckt.

Das Diagramm zeigt drei Kurven, die fast gemeinsam wachsen, und genau das ist die Absicht: Tests und festgehaltene Entscheidungen begleiten den Code, statt ihm hinterherzuhinken. Der Anstieg ist am 29. Oktober am steilsten, als der gesamte Weg vom Kernel bis zum Broker entsteht. Danach kommen Zeilen langsamer hinzu, aber die Tests wachsen schneller als der Code (27 Tests auf 1,6 Tausend Zeilen am Anfang, 739 auf 89,8 Tausend heute).

Als Zeilen zählen alle .rs-Dateien außerhalb von vendor/ und fuzz/, als Tests die #[test]-Funktionen. Was welcher Abschnitt hinzugefügt hat, nach Datum aus der Git-Historie:

Versprechen 1: ein ISO für mehrere Plattformen

Was wir geplant haben. Eine einzelne Datei, die auf aarch64-UEFI, x86_64-UEFI und x86_64-BIOS startet. Was wir gebaut haben. Den Port auf x86_64 (X0 bis X10) und ein universelles ISO mit dem Limine-Bootloader, ein hybrides ISO, von dem alle diese Kombinationen starten; die Smoke-Tests starten es auf vier virtuellen Maschinen. Das Menü hat drei Einträge: urMQTT (Live-Modus, läuft aus dem RAM, schreibt nichts auf die Festplatte), die Installation auf die Festplatte der Maschine, auf der es gestartet wurde (die Installation schreibt GPT und Daten und schaltet die Maschine dann aus) und Diagnose (Hardware-Erkennung und Messungen).

Das erste echte Ziel war ein VPS und keine physische Maschine: Wir haben entschieden, dass die erste Veröffentlichung nur VPS (KVM) unterstützt und Bare Metal danach kommt. Getestet haben wir auf einem Contabo-VPS mit AMD-EPYC-Prozessor (Familie 23, Zen 1), 4 vCPUs und 8 GiB RAM, mit virtio-net-Netzwerk und virtio-scsi-Festplatte. Der erste Versuch hat uns überrascht: Das als virtuelle CD eingebundene ISO startete den Standardeintrag, das Produktions-Image weigerte sich, von einem schreibgeschützten Medium zu laufen, und setzte sich zurück. So bekamen wir eine Endlosschleife aus Menü, Kernel und Reset, ohne irgendetwas Lesbares. Heute hinterlässt ein fataler Fehler im Produktions-Image seine Meldung 60 Sekunden lang auf der Konsole, bevor der Reset erfolgt, und von einem optischen Medium wird ausgegeben, dass von einem schreibgeschützten Medium gestartet wurde, und dann angehalten. Der Live-Modus im RAM (O3) hat dieses Problem später für den üblichen Fall umgangen.

Der Diagnose-Eintrag ist aus dieser Erfahrung entstanden: Eine Maschine, die wir nicht sehen, müssen wir fragen können, was sie hat. Er gibt CPU, RAM, Netzwerk, Festplatten und PCI-Geräte aus, misst Speicherdurchsatz, Festplatte und Kryptografie und gibt dieselben Messungen als JSON auf dem seriellen Port aus. Das Schreiben auf die Festplatte ist nur im nicht zugewiesenen Bereich erlaubt und erst, nachdem WIPE eingegeben wurde; in der Aufnahme unten wurde das übersprungen.

Was offen ist. Echte Hardware. Nach der ersten Veröffentlichung folgt Bare Metal (USB-Boot, NVMe und AHCI, Netzwerkkarte eines echten Rechners) zusammen mit IOMMU und Secure Boot, denn ohne IOMMU kann ein bösartiges oder fehlerhaftes Gerät den gesamten Speicher beschreiben. In dieser Version behaupten wir dazu nichts.

Handshake: von 1,2 ms auf 0,24 ms

Die erste Diagnosemessung auf dem VPS lieferte eine unangenehme Zahl: Der mTLS-Handshake, nur die Kryptografie auf der Serverseite, dauerte 1,2 ms. Auf aarch64 nutzten wir bereits die Hardware-Instruktionen für AES und SHA, aber x86_64 hatte für Public-Key-Verfahren nichts Vergleichbares: RustCrypto ist portabel und constant-time, und damit auch langsam. Drei Änderungen haben das gesenkt.

• Für P-256 haben wir den nistz256-Assembler aus OpenSSL und ring übernommen (ADR-130), dazu Tabellen mit fester Basis für das Signieren und die Prüfung von CA-Signaturen (ADR-110, ADR-111).
• X25519 wurde auf vier 64-Bit-Limbs mit MULX/ADX-Instruktionen umgeschrieben (ADR-131).
• Danach haben wir auch den Rest profiliert (ADR-132, ADR-200).

Die Zahlen unterscheiden sich von Lauf zu Lauf um etwa 10%, deshalb haben wir eine Spanne statt eines einzelnen Wertes notiert. Insgesamt ist das ungefähr fünfmal weniger CPU-Zeit für den Handshake.

Was wir über memcpy gelernt haben. Als die Kryptografie gefallen war, zeigte das Profil etwas, womit wir nicht gerechnet hatten: Die mem*-Funktionen (memcpy, memmove, memset) verbrauchten 7% des Handshakes, 13 bis 39% des TLS-Record-Pfads (39% bei 64 B, 13% bei 4 KiB) und 17 bis 34% der PUBLISH-Verteilung. Wir haben sie durch SSE2-Assembler für x86_64 ersetzt (ADR-200), mit Differenztests gegen die Referenzimplementierung für alle Größen, Ausrichtungen und Überlappungen. Pro Aufruf sind das 55 bis 75 Zyklen gegenüber 7 bis 12 bei 1 bis 64 Bytes.

So liest man das Diagramm: Je kleiner der Record, desto größer der Anteil der Zeit, der ins Kopieren fließt, und desto größer der Gewinn. Für kleine Nachrichten, die den Großteil des MQTT-Verkehrs ausmachen, ist das genau das, was zählt.

Was das nicht bedeutet. Auf nativem x86_64 haben wir OpenSSL 3.5.5 (ADR-130) nur als Referenz für den Assembler gemessen, nicht als Produktvergleich. Den Vergleich Linux plus Mosquitto auf demselben VPS (Aufgabe X11) haben wir noch nicht gemacht. Deshalb behaupten wir nicht, dass urMQTT schneller als Linux ist: Es ist nicht gemessen. Die Zahlen oben vergleichen urMQTT mit sich selbst.

Die Überlast war das zweite Ergebnis. Auf dem VPS, von einem einzelnen Mac aus (RTT 35 ms), schafften 128 Clients 618 Handshakes pro Sekunde, 256 Clients 393 und 512 Clients 67, mit Tausenden abgewiesenen Verbindungen. Das war kein Plateau, sondern ein Zusammenbruch. Die Ursachen haben wir im Code gefunden (zwei davon wurden in QEMU/HVF bestätigt, auf dem VPS ließen sie sich nicht reproduzieren), mehrere gleichzeitig: Eine abgewiesene Verbindung schickte den Client über das nächste Segment mit gültigem SYN-Cookie zurück, die Abweisung per RST sagte dem Client, sofort erneut zu versuchen, und die Annahme war O(Warteschlange). Die Korrektur (ADR-080 bis ADR-082) verwirft ein SYN, das nicht angenommen würde, merkt sich abgewiesene Flows, hält die Annahme in O(1) und zählt die Handshakes pro Kern. Möglich (Hypothese, nicht geprüft) ist, dass ein Teil der Ursache auch auf der Client-Seite lag: Das Lastwerkzeug schloss zuerst, sodass ein einzelner Mac mit 16 384 ephemeren Ports und 30 Sekunden TIME_WAIT auf etwa 550 Verbindungen pro Sekunde begrenzt war. Die echte Obergrenze des Servers haben wir daher noch nicht gemessen.

Versprechen 2: rohe Festplatte, aber sorgfältig

Was wir geplant haben. Das eigene Layout ohne Dateisystem beibehalten und all das hinzufügen, was ein Dateisystem sonst liefert: Ausrichtung, Wachstum, Discard, Sicherungskopien und Prüfungen. Warum kein Dateisystem. Darüber haben wir diskutiert, und die Entscheidung wurde bestätigt: urMQTT schreibt eine Datenbank, ein Telemetrie-Journal und eigene Metadaten, braucht weder Verzeichnisse noch Berechtigungen noch Dateinamen, und jede zusätzliche Schicht wäre noch mehr Code im vertrauenswürdigen Teil und noch ein Weg, auf dem ein Schreibvorgang unbemerkt verschwinden kann. Die Festplatte ist GPT mit einer ESP-Partition und einer urMQTT-Datenpartition, auf der das eigene Layout liegt.

Was wir gebaut haben (S2 bis S6).

• Layout v2 (S2). Festplattentopologie, Ausrichtung auf 1 MiB oder die optimale I/O-Größe, ganze physische Blöcke, ein A/B-Paar von Superblöcken mit Generation (ADR-140). Layout v1 lehnt der Kernel mit einer klaren Meldung ab, und es wird vom Offline-Werkzeug urmqtt-disk migrate migriert (ADR-141): Standard ist ein Probelauf, es wird kopiert und erst dann umgeschaltet, mit Rollback und Fehlerinjektion bei jedem Schreibvorgang.
• Wachstum (S3). Beim Start kann die Festplatte wachsen (sie schrumpft nie), und auf virtio-blk auch zur Laufzeit, über den Konfigurationsänderungs-Interrupt (ADR-142, ADR-143).
• Discard und Write-Zeroes (S4). Thin provisionierte Festplatten geben Speicherplatz an den Host zurück. Im Test fiel eine qcow2-Datei auf dem Host von 62 auf 16 MiB, nachdem Telemetriesegmente abgelaufen waren, und die Wiederherstellung traut dem Inhalt verworfener Bereiche nie.
• Sicherungskopie der Datenbank auf der Festplatte (S5). Eine A/B-Kopie mit der Online-Backup-API von SQLite in Schritten von 16 Seiten: der längste Schritt 4,6 ms gegenüber 445 ms, wenn in einem Aufruf kopiert wird. Commits während des Kopierens hatten ein Maximum von 2,4 ms gegenüber 2,2 ms ohne Kopie. Schlägt quick_check beim Start fehl, wird die Datenbank aus der Kopie wiederhergestellt.
• Scrubbing und begrenzter Start (S6). Der Scrubber liest die Festplatte mit begrenztem I/O-Budget und meldet beschädigte Einträge, und der Start liest nur das jeweils neueste Segment jeder Partition, sodass die Startzeit nicht mit der Größe der Telemetrieregion wächst. Damit haben wir ein Problem gelöst, das wir vorab ausgerechnet hatten: Auf einer großen Festplatte würde eine vollständige Wiederherstellung von Minuten bis zu Dutzenden von Minuten dauern.

Die gesamte Gruppe der Smoke-Tests für die Speicherung läuft auf beiden Architekturen durch: 79 erfolgreich, 0 fehlgeschlagen, auf aarch64 unter HVF und auf x86_64 unter TCG. Wir haben auch gemessen, dass S4 die Datenbank nicht verlangsamt hat: 53,3 Tausend Einfügungen pro Sekunde in Batches vorher und nachher, ohne messbaren Unterschied.

Was überrascht hat. Wie viel von einem "einfachen" Layout auf Randfälle entfällt: virtio-scsi und virtio-blk melden die Topologie auf unterschiedliche Weise, und ein unvollständiger Schreibvorgang mitten in der Migration muss immer mindestens eine gültige Version hinterlassen. Deshalb hat jeder Schreibvorgang auf dem Weg der Migration und des Wachstums die Fehlerinjektion durchlaufen.

Was offen ist. SQLite-Seiten haben keine Prüfsumme, sodass die Datenbank ein geändertes Bit innerhalb eines Zeilenwerts nicht bemerkt; Telemetrieeinträge und der Inhalt der Kopien haben ein CRC und werden erkannt. Die Festplattenverschlüsselung (S7) ist nicht fertig.

Versprechen 3: nachweisbar sicher, so weit wir es schaffen

Härtung (H4). Der Allokator löscht freigegebenen Speicher und prüft ihn bei der Wiederverwendung, erkennt doppelte Freigaben, verknüpft Zeiger der Freiliste per XOR und nullt Schlüssel bei der Freigabe (ADR-170). Stack-Schutz (-Zstack-protector=strong, 1315 Funktionen, und SQLite mit -fstack-protector-strong, ADR-171). Fehlerberichte in der Produktion enthalten weder Register noch Adressen (ADR-172). KASLR auf beiden Architekturen: Der Kernel ist PIE, und Limine verschiebt ihn um etwa 19 Bit, zufällig platziert werden Heap, Stacks und das MMIO-Fenster (ADR-173). Auf aarch64 markiert MTE den Heap (ADR-174), aber nur unter TCG: HVF und x86 haben es nicht. kCFI haben wir bewertet und nicht übernommen, weil der Compiler im festgelegten Nightly mit einem internen Fehler abstürzt; IOMMU wurde zusammen mit Bare Metal zurückgestellt (ADR-175, ADR-176).

Der Preis ist gemessen, nicht angenommen. Auf dem Handshake-Pfad (dp-bench, aarch64 HVF, volle TLS-1.3- + mTLS- + CONNECT-Handshakes):

Insgesamt liegt der Preis auf dem Handshake-Pfad also bei etwa 5% für die sauber gemessenen Teile, und mit PIE und Markierungen kommen etwa 7% auf einem und etwa 11% auf vier Kernen heraus, doch diese Messung ist verrauscht. Wir halten das für akzeptabel, haben es aber nicht auf dem x86_64-VPS wiederholt.

Es lohnt sich, das mit der Zahl aus dem ersten Text zu vergleichen (862 Handshakes pro Sekunde auf einem Kern). Dasselbe Werkzeug liefert heute, mit der Hardware-Verschlüsselung auf aarch64 (X0b) und einer Reihe von Beschleunigungen, die seitdem hinzugekommen sind, 1941 vor der Härtung. Den Beitrag jeder einzelnen Änderung haben wir nicht isoliert, deshalb behaupten wir zur Ursache nichts.

Wie es geprüft wurde, und was nicht. H5 hat Miri für eine Teilmenge der Host-Crates, Kani-Beweise, Sanitizer, einen Modell-Fuzzer für die ACL und Abdeckungsberichte hinzugefügt. Kani hat record_len in TLS, parse im TCP und zwei Arithmetiken des Timer-Rads bewiesen. Nicht bewiesen (Zeitüberschreitung) sind beide MQTT-Decoder, beide Konfigurationsparser und das Verhalten des Timer-Rads; der CI-Job für Kani blockiert deshalb noch nicht. Miri kann keinen Assembler ausführen. Lieferkette (H9): ein CycloneDX-SBOM mit 215 Komponenten, cargo-vet läuft durch mit 39 vollständig geprüften und 140 Ausnahmen, und cargo-deny ist so konfiguriert, dass Schwachstellenhinweise als CI-Fehler behandelt werden (diese CI-Jobs wurden bisher nur lokal geprüft, nicht auf GitHub, und der Negativtest wurde nicht ausgeführt), dazu VULNERABILITY-HANDLING.md. Der ehrliche Stand: Von 67 in den Kernel gelinkten Versionen von Drittanbieter-Crates sind 53 Ausnahmen und keine Audits. Vet beweist, dass sich die Menge der Abhängigkeiten nicht ohne sichtbaren Unterschied ändern kann, nicht, dass die TCB geprüft wurde. Ein eigenes Audit eines Crates haben wir nicht geschrieben.

SNTP (T1) ist in diesem Sinne eine kleine Sicherheitsgeschichte: Es ist optional, nur zu privaten IPv4-Servern, mit einem maximalen Sprung und der Bedingung, dass die Quellen übereinstimmen (Median, Mehrheit innerhalb einer Sekunde). Eine Uhr, die jeder auf dem Weg verstellen kann, ist keine Uhr, der wir bei der Gültigkeit von Zertifikaten trauen dürfen.

Auf dem Mac: aarch64 nativ und x86_64 per Emulation

Wir entwickeln auf dem Mac, und der hat zwei Wege, denselben Code auszuführen, die sich stark unterscheiden.

Die Regel ist einfach: Zahlen unter TCG sind Emulation, und wir zitieren sie nicht als Performance. Die x86-Performance messen wir nur auf einem echten VPS. Deshalb stammen die Krypto-Zahlen oben vom Contabo-VPS und nicht vom Mac.

Lektionen

• Messen Sie auf einer echten Maschine, bevor Sie optimieren. Unser erster Ansatz war, das zu optimieren, was wir für langsam hielten; erst die Diagnose auf dem VPS zeigte 1,2 ms und wo genau die Zeit hingeht.
• Überlast ist ein eigenes Feature. Ein System, das unter Last schnell ist, kann darüber zusammenbrechen; Abweisen muss billiger sein als Annehmen.
• Das Profil überrascht. Der größte Einzelgewinn für kleine Nachrichten lag nicht in der Kryptografie, sondern im Kopieren von Speicher.
• Eine Festplatte ohne Dateisystem erfordert mehr Arbeit, nicht weniger. Was ein Dateisystem sonst liefert (Ausrichtung, Wachstum, Discard, Kopien, Prüfungen), müssen wir selbst schreiben und prüfen, jeden Schritt mit Fehlerinjektion.
• Ehrlichkeit bei den Zahlen. Speichermessungen auf einem geteilten VPS schwanken zwischen den Läufen um das bis zu 10-Fache und sagen nichts über den Code aus, deshalb nennen wir sie nicht. Die Krypto-Zahlen sind stabil bis auf etwa 10%.
• Entwicklungsgeschwindigkeit ist keine Reife. Tests und ADRs wachsen mit dem Code, aber vier Tage sind kein echter Betrieb.

Was als Nächstes kommt

• H6: SQLite auf EL0-Ebene isoliert, sodass ein Fehler in der Datenbank nicht den Kernel öffnet.
• H7: der Rest der Zeitsicherheit (NTS und Behandlung von Sprüngen); SNTP ist erst der erste Schritt.
• X11: Vergleich mit Linux und Mosquitto auf demselben VPS, erst dann ist es sinnvoll, von relativer Geschwindigkeit zu sprechen.
• Release: die erste öffentliche Veröffentlichung für VPS (KVM), mit signierten Artefakten und Anleitungen.
• Nach dem Release: Bare Metal (X12 bis X16), IOMMU und Secure Boot sowie Festplattenverschlüsselung.

Der Code liegt auf github.com/zeljan-alduk/urMQTT, und docs/PROGRESS.md bleibt die einzige Quelle der Wahrheit darüber, was tatsächlich funktioniert. Pre-Alpha, wie zuvor; Fehlerberichte und Sicherheitsmeldungen nach den Hinweisen in SECURITY.md sind willkommen.

So ist urMQTT entstanden: ein Unikernel, der selbst der MQTT-Broker ist. Kernel, TCP/IP, TLS 1.3, MQTT und eine eingebettete Datenbank in einem einzigen Rust-Binärprogramm, das von einem einzigen ISO gestartet wird. Es gibt keine Prozesse, keine Systemaufrufe, keine Shell. Die erste Plattform, auf der es gebaut und getestet wird, ist aarch64, und derselbe Code geht weiter in Richtung x86_64, über UEFI und klassisches BIOS, und in Richtung echter Hardware: Das Ziel ist ein einziges ISO, das auf all dem startet. Das Projekt ist Open Source unter der Lizenz MIT oder Apache 2.0, und in diesem Text möchten wir festhalten, wo wir stehen, wie es im Inneren aufgebaut ist und was wir unterwegs gelernt haben.

Was "Unikernel" genau bedeutet

Ein üblicher Broker ist ein Programm, das auf einem Betriebssystem läuft. urMQTT hat kein Betriebssystem unter sich: Es startet sich selbst über die UEFI-Firmware und den Limine-Bootloader, richtet eigene Seitentabellen ein, programmiert den Interrupt-Controller und den Timer, findet virtio-Geräte über PCIe, bezieht per DHCP eine Adresse und lauscht auf einem einzigen Port. Alles, was sonst Kernel, Treiber, Netzwerkstack und Anwendung leisten, ist hier ein einziges ELF, das auf der Ebene EL1 läuft.

Der Vergleich mit einer typischen Installation spricht für sich:

Die Prioritäten lauten in dieser Reihenfolge: Sicherheit, Skalierbarkeit, Mehrkernleistung, geringer Footprint und unveränderliche Installation. Stehen zwei Ziele im Konflikt, gewinnt dasjenige, das in dieser Liste weiter oben steht.

Wo wir jetzt stehen

Das Projekt befindet sich in der Pre-Alpha-Phase, aber siebzehn Entwicklungsmeilensteine, von M0 bis M17, sind abgeschlossen. Heute bedient urMQTT MQTT 3.1.1 über TLS 1.3 mit obligatorischen Client-Zertifikaten und hält den Zustand in SQLite auf einer rohen Festplatte. Kurz zusammengefasst, was bereits funktioniert:

• Kernel: eigene Ausnahmevektoren mit dekodierten Berichten, eigene Seitentabellen mit durchgesetztem W^X, Guard-Pages, PAC und BTI, wo der Prozessor sie besitzt, GICv3 und GICv2, generischer Timer, SMP bis zu 64 Kernen.
• Hardware-Erkennung aus DTB oder ACPI in einer einzigen Plattformbeschreibung, mit identischem Ergebnis aus beiden Quellen.
• Treiber: PCIe ECAM, MSI-X, virtio-net, virtio-blk, virtio-scsi und virtio-rng sowie ein CSPRNG, der mit Hardware-Entropie initialisiert wird.
• Netzwerk: eigenes DHCPv4, ARP, ICMP und striktes IPv4, dazu ein eigenes TCP nur für die Serverseite: SYN-Cookies, hierarchisches Timer-Rad, NewReno, Zusammenfassen von ACKs, kein TIME_WAIT-Zustand.
• TLS: nur TLS 1.3, obligatorisches mTLS, Geräteidentität aus CN oder SAN-URI; der Handshake läuft über rustls, danach folgt eine eigene Record-Schicht mit AES-128-GCM und ChaCha20-Poly1305. Sitzungswiederaufnahme mit PSK-Tickets, Sperrliste, Admission Control bereits beim Handshake.
• MQTT: Kopierfreier Codec, gefuzzt und mit echten mosquitto-Clients getestet; QoS 0 und 1, Wildcards, Retained Messages, Last Will (LWT), persistente Sitzungen, ACL mit Beschränkung auf devices/{id}/#, Ratenbegrenzung pro Gerät.
• Speicherung: SQLite im Kernel über ein VFS auf der rohen Festplatte, im WAL-Modus, mit Integritätsprüfung beim Start; Geräteregister, Sperrungen, Retained Messages, persistente Sitzungen mit Nachrichtenwarteschlangen für Geräte, die offline sind; pro Kern ein eigenes Telemetrie-Journal mit CRC je Eintrag und Wiederherstellung nach einem Absturz.
• Betrieb und Überwachung: Watchdog-Timer für Handler, Health-Check, begrenztes Logging, Syslog und statsd über UDP, eine Admission Control, die Wiederverbindungsstürme übersteht.
• Auslieferung: bitweise identische Rebuilds, die in der CI geprüft werden, ISO und rohes GPT-Festplattenabbild, minisign-Signaturen, Anleitungen für KVM, Proxmox und Hetzner.

Jeder Schritt ist mit dem Meilenstein gekennzeichnet, der ihn gebracht hat, und die Datei docs/PROGRESS.md im Repository ist die einzige Quelle der Wahrheit darüber, was tatsächlich funktioniert.

Die Architektur in drei Bildern

Das gesamte Design ist in docs/ARCHITECTURE.md beschrieben, und die Gründe für jede wichtigere Entscheidung sind als ADRs in docs/DECISIONS.md festgehalten. Hier ein Überblick.

Schichten

Von oben nach unten: Broker (Sitzungen, Topic-Baum, QoS, Retained Messages, Last Wills, ACL, Limits), MQTT-Codec, TLS, TCP, Netzwerkschicht und schließlich die Treiber. Neben diesem Hauptpfad steht die Speicherung (SQLite und Telemetrie-Journal), und unter allem liegen Speicherverwaltung, Plattformerkennung und eine Konfiguration, die zur Build-Zeit in Konstanten übersetzt wird, zusammen mit dem eingebetteten CA-Zertifikat, dem Serverzertifikat und dem Schlüssel. Der Hypervisor mit den virtio-Geräten ist das Einzige, was außerhalb des Images liegt.

Ein Thread pro Kern, kein gemeinsamer Zustand

Jeder Datenkern dreht seine eigene Schleife mit eigenem TCP-Stack, eigenen TLS-Zuständen, einem eigenen Teil des Brokers (Sitzungen und Topic-Baum), einem Heap-Cache und einer Telemetrie-Partition. Die Kerne teilen keinerlei veränderlichen Zustand, sondern nur begrenzte sperrfreie Ringe, je einen für jedes geordnete Kernpaar. Der höchste Kern führt SQLite aus und sonst nichts.

Die Netzwerkkarte hat heute ein Warteschlangenpaar, das Kern 0 hält. Dieser lenkt jeden MQTT-Fluss anhand des Toeplitz-Hashes seines Vierertupels auf einen der Arbeitskerne und sendet, was die Arbeitskerne zurückgeben. Eine Sitzung lebt auf ihrem Heimatkern, der durch den Hash der Client-ID bestimmt wird, sodass Übernahme, Last Wills und Persistenz nie Kerngrenzen überschreiten. Eine Verbindung, die auf einem anderen Kern landet, behält dort ihr TCP und TLS und reicht den gewöhnlichen MQTT-Verkehr mit kreditbasierter Flusskontrolle an den Heimatkern weiter. Jede weitergeleitete Nachricht wird zudem auf die übrigen Broker-Teile verteilt, von denen jeder eine Replik der Retained Messages hält.

Drei Regeln halten dieses Modell zusammen. Run-to-Completion: Ein empfangenes Paket wird vollständig auf einem einzigen Kern verarbeitet, von TCP über das Entschlüsseln von TLS an Ort und Stelle, das Parsen von MQTT und das Routing bis zur verschlüsselten Antwort, ohne Aufgabenwarteschlangen und ohne Kopieren in Anwendungspuffer. Adaptives Polling: Unter Last werden die Empfangswarteschlangen aktiv abgefragt, im Leerlauf kehrt der Kern zu Interrupts und WFI zurück; die Interrupt-Handler quittieren den Interrupt nur und markieren die Arbeit. Watchdog-Timer: Ein 10-ms-Tick pro Kern fängt Handler ab, die ihr Budget überschreiten.

Das Leben eines PUBLISH

Das Gerät sendet einen TLS-Record. Die Netzwerkkarte übergibt ihn per Deskriptor ohne Kopieren an die Schleife des Kerns. Die Schleife prüft TCP, entschlüsselt TLS an Ort und Stelle und parst MQTT aus dem geliehenen Puffer, dann prüft sie im Speicher die ACL, die Ratenbegrenzung und den Pfad durch den Topic-Baum. Interessiert sich ein anderer Kern für das Topic, erhält er eine Routing-Nachricht mit einer Referenz auf die Nutzlast und der Topic-Kennung; die Datenbank erhält einen Telemetrieeintrag oder die Aktualisierung einer Retained Message, gebündelt in einem Paket. Das PUBACK wird direkt in den Ausgangspuffer verschlüsselt und mit dem TCP-ACK verschmolzen, sodass nur ein einziges Segment zum Gerät geht. Einen anderen Kern kostet die Nachricht eine Verschlüsselung pro Abonnent im Moment des Sendens.

Was eine Verbindung kostet

Das Ziel sind höchstens 512 Byte pro inaktiver TLS-Verbindung, mit der Tendenz zu 256. Solange eine Verbindung ruht, wird für sie nichts in einem Puffer gehalten: Empfangene Daten werden direkt aus dem Netzwerkframe verarbeitet, und die Puffer für Senden, Records und MQTT existieren nur, solange etwas unvollendet oder unbestätigt ist. Der Kernel misst das auch selbst: exakte Heap-Zähler in angeforderten Bytes und in den tatsächlich belegten Blöcken, alle zehn Sekunden geschrieben als Heap über der Grundlinie pro offener Verbindung.

Gemessen unter HVF mit vier virtuellen Kernen, davon drei Arbeitskerne, wobei jedes Gerät eine mTLS-Verbindung und ein Abonnement mit QoS 1 hält, einschließlich der Rundung durch den Allokator:

Der Pool der Netzwerkframes ist mit etwa 2 MiB fest, das sind ungefähr 200 B pro Verbindung bei zehntausend Verbindungen und etwa 2 B bei einer Million. Mehr konnten wir nicht messen: Das Benutzer-Netzwerk von QEMU unter macOS hat bei 10 197 aufgehört, Verbindungen anzunehmen, ungefähr an der Grenze von 10 240 Deskriptoren des QEMU-Prozesses. Die Zahl sinkt, je mehr die festen Anteile sich auf mehr Verbindungen verteilen, sie wächst also nicht mit deren Anzahl.

Das Sicherheitsmodell

Sicherheit ist die erste Priorität und gewinnt jeden Konflikt mit den anderen Zielen. Das Modell hat mehrere Schichten:

• Ein einziger Port. TCP 8883, nur TLS 1.3, obligatorische Client-Zertifikate, signiert von der im Image eingebetteten CA. Die MQTT-Client-ID muss der Geräte-ID aus dem Zertifikat entsprechen.
• Kein Zugang. Keine Shell, keine Konsoleneingabe, kein SSH, keine Administrations-API, kein dynamischer Code, kein über das Netzwerk erreichbares SQL und kein Dateisystem.
• Speichersicherheit. Rust, mit forbid(unsafe_code) in den Protokollpaketen; jeder unsafe-Block hat einen Kommentar // SAFETY:, den ein Lint prüft, und bei externer Eingabe gibt es keine Panik: Clippy verbietet in den Paketen auf dem Datenpfad unwrap, expect, Indexierung und panic!.
• Abschwächung von Exploits. W^X wird durch die Kodierung der Deskriptoren und das Bit SCTLR_EL1.WXN durchgesetzt und bei jedem Start auditiert. Die Seitentabellen sind nach dem Start schreibgeschützt, ohne beschreibbaren Alias. Die untere Hälfte des Adressraums ist ausgeschlossen. Jeder Stack hat Guard-Pages, und Ausnahmen laufen auf einem eigenen Stack. PAC und BTI werden aktiviert, wenn der Prozessor sie unterstützt, und das prüfen die Smoke-Tests.
• Missbrauchsresistenz. SYN-Cookies; die Admission Control lehnt neue Verbindungen vor jeglicher Kryptografie ab, wenn der Heap knapp ist, die Datenbank zurückliegt, zu viele Handshakes pro Kern oder pro Quelladresse laufen oder die Handshake-Rate zu hoch ist. Ratenbegrenzung pro Gerät, begrenzte Warteschlangen, ein an den Rückstau des Brokers gekoppeltes TCP-Fenster, begrenztes Logging, Watchdog-Timer und Health-Check.
• Unveränderlichkeit. Konfiguration, CA und Serverschlüssel sind im Image eingebettet. Jede Änderung bedeutet ein neues Image.

Das Bedrohungsmodell ist in docs/SECURITY.md festgehalten.

Speicherung ohne Dateisystem

Die Daten liegen auf einer separaten Festplatte, virtio-blk oder virtio-scsi, auf der es kein Dateisystem gibt. Das Layout ist minimal und eigen:

LBA 0      [ Superblock: Magic · Layout-Version · UUID · Regionstabelle · CRC-32C ]
LBA 8, 16  [ Tabelle der Dateigrößen, Slots A/B (der neueste gültige gewinnt) ]
LBA 64     [ SQLite-Hauptdatenbank ½ ][ SQLite-WAL ⅛ ][ Journal 1 MiB ][ Telemetrie-Journal: 8 Partitionen … ]
letzte 4 KiB [ Bereich für den Selbsttest des Blockgeräts beim Start ]

SQLite (gevendortes 3.54.1, mit Prüfung des Digests beim Build) wird mit clang ohne Standardbibliothek in den Kernel übersetzt und nutzt einen festen memsys5-Heap. Sein VFS bildet drei feste Dateien auf Regionen der Festplatte ab. Es läuft im WAL-Modus mit locking_mode=EXCLUSIVE, braucht also keinen Index im gemeinsamen Speicher, und mit synchronous=FULL; findet quick_check beim Start einen Fehler, hält sich das System sicher an. In der Datenbank liegen das Geräteregister, die Sperrungen, die Retained Messages und die persistenten Sitzungen mit Warteschlangen für QoS-1-Nachrichten für Geräte, die nicht verbunden sind.

Der Kern für die Datenbank, derjenige mit der höchsten Nummer, führt SQLite aus und sonst nichts. Die Datenebene schickt ihm Zustandsänderungen über einen sperrfreien SPSC-Ring; er sammelt sie alle 5 ms oder alle 512 Operationen in einer Transaktion und gibt die Bestätigungen über einen zweiten Ring zurück. Eine leere Festplatte wird beim ersten Start formatiert; alles andere wird niemals überformatiert.

Die Telemetrie geht einen anderen Weg. Jedes akzeptierte PUBLISH auf Topics aus storage.telemetry_topics landet in der Partition des Telemetrie-Journals seines Kerns: ein Ring aus Segmenten mit CRC pro Eintrag, gesalzen mit der Segmentsequenz, sodass alte Durchläufe des Rings nie wieder auftauchen. Die Kerne übergeben die Einträge über einen eigenen Ring ohne Kopieren an die Datenbank, die sie alle 5 ms oder alle 256 KiB ausschreibt. Beim Start behält die Wiederherstellung jeden ausgeschriebenen Eintrag, schneidet den unvollständigen Rest ab und setzt in einem neuen Segment fort. Die Aufbewahrung erfolgt nach Größe, durch den Ring, und nach Alter, durch retention_days. Wir haben das mit einer Million Einträgen und mit kill -9 mitten im Schreiben überprüft.

Die Zahlen

Das Lastwerkzeug in tools/loadgen leistet drei Dinge: einen Sturm von TLS-1.3-Handshakes mit mTLS und CONNECT, langlebige Verbindungen mit PINGREQ, die jede Sekunde Telemetrie veröffentlichen, und Wiederverbindungsstürme. make bench auf einem Apple M4 Pro unter HVF liefert:

Die Zahl im Gast, bei der Client und Server innerhalb derselben virtuellen Maschine liegen und jeder Arbeitskern für sich arbeitet, zeigt, dass die Datenebene linear skaliert. Die Netzwerkzahl wird durch das einthreadige Benutzernetzwerk von QEMU begrenzt, nicht durch den Gast; auch das ist als ADR-032 festgehalten.

Wiederverbindungsstürme testen wir, indem sich alle Geräte gleichzeitig verbinden, abgelehnte Versuche mit Verzögerung wiederholen und dann alle ohne DISCONNECT abstürzen. Der Parameter heap_limit_mb= bringt die Admission Control im Entwicklungsmodus dazu, den Heap für kleiner zu halten, als er ist, sodass sich ein Sturm, der größer ist als der Heap, mit wenigen Sockets ausprobieren lässt. In einer solchen Runde mit 3 000 Geräten verbanden sich 1 368 in 36 Sekunden, und 5 619 Versuche wurden ordnungsgemäß abgelehnt, bei einem Limit von 8 MiB; der Speicher kehrte nach dem Sturm zurück.

Wie wir arbeiten

Das Projekt wird von einer schriftlichen Spezifikation, PROMPT.md, mit einem Meilensteinplan geleitet, und jeder Meilenstein endet mit demselben Ritual: make check und make smoke grün, ein Commit mit der Kennzeichnung M<n>, ein Eintrag in docs/PROGRESS.md und ein ADR für jede Entscheidung, die nicht offensichtlich ist. Die Regeln sind kurz, und wir verhandeln nicht darüber: keine Panik bei externer Eingabe, unsafe nur in Hardware- und FFI-Paketen und immer mit Kommentar, keine Allokationen auf dem heißen Pfad, ein Kommentar zu jeder Reihenfolge atomarer Operationen, jedes Limit kommt aus der Konfiguration, und absichtliche vorläufige Teile scheitern laut.

Die CI leistet mehr, als wir von Hand schaffen würden: fmt, Clippy für den Host und für aarch64-unknown-none, typos, actionlint und shellcheck; Tests unter Linux und macOS auf arm64; den Build des Kernels für die Entwicklungs- und die Produktionskonfiguration mit der ELF-Größe in der Zusammenfassung; den Start unter QEMU mit allen Szenarien des Smoke-Tests und das Sichern der seriellen Logs; cargo-deny für Advisories, Lizenzen und Quellen; eine Minute Fuzzing pro Ziel bei allen elf Zielen und nachts zehn Minuten pro Ziel mit einem zwischengespeicherten Korpus. Dazu CodeQL, OpenSSF Scorecard, Dependabot und eine Veröffentlichung mit SLSA-Provenienz. Jede fremde Action ist auf den vollständigen Commit-SHA festgepinnt.

Reproduzierbarkeit nehmen wir wörtlich: make repro baut HEAD zweimal in frischen Arbeitsbäumen und vergleicht ELF, ISO und rohes Abbild Byte für Byte. Die Releases sind mit minisign signiert, und die Artefakte lassen sich mit gh attestation verify prüfen. Das Produktions-Image enthält den privaten Serverschlüssel, daher ist das ISO selbst ein Geheimnis; die Images bei den Releases auf GitHub sind Entwicklungs-Images mit temporären Schlüsseln und dienen nur zum Ausprobieren.

Was wir gelernt haben

Einige Lektionen, die den Plan verändert haben:

• Ein eigenes TCP hat sich doch gelohnt. Der Prototyp lief auf smoltcp und hat uns bis M13 gute Dienste geleistet. Aber ein Server, der Hunderttausende Verbindungen hält, braucht kein Client-TCP, er braucht SYN-Cookies, ein Timer-Rad und einen Zustand von 96 Byte. In M14 haben wir smoltcp durch einen eigenen Stack nur für die Serverseite ersetzt, mit Tests unter simuliertem Paketverlust und Fuzzing der Segmente.
• Messen Sie den Speicher von innen. Schätzungen pro Verbindung waren nutzlos, bis der Kernel selbst begann, den Heap in Allokatorblöcken zu zählen und nicht in angeforderten Bytes. Erst dann sahen wir, wohin die 512 Byte tatsächlich gehen, und kamen auf 494 herunter.
• Das Testwerkzeug ist Teil des Produkts. Die größte Einschränkung war nicht der Kernel, sondern das Benutzer-Netzwerk von QEMU und die Zahl der ephemeren Ports auf dem Entwicklungsrechner. Für hunderttausend und mehr Verbindungen braucht man vmnet-shared unter macOS oder Linux mit KVM, einem tap-Interface und mehreren Client-Adressen.
• SQLite ohne Betriebssystem ist möglich, aber nur unter strengen Bedingungen: fester Heap, exklusives Locking ohne gemeinsamen Speicher, ein VFS, das von Dateien nichts weiß, und eine Admission Control, die die Datenbank nicht zurückfallen lässt.
• Wiederverbindungsstürme sind der Normalzustand, keine Ausnahme. Fällt das Mobilfunknetz aus und kehrt zurück, klopfen Tausende Geräte gleichzeitig an. Deshalb lehnt die Admission Control eine Verbindung vor jeglicher Kryptografie ab, und jede abgelehnte Verbindung kostet fast nichts.

Was als Nächstes kommt

Die Arbeit nach M17 ist in drei Richtungen geplant, und die Reihenfolge dazwischen ist in docs/PLAN.md festgehalten. Nichts davon ist bisher gebaut.

• Ein ISO für mehrere Plattformen. Dieselbe Datei urmqtt-<env>-<version>.iso und ein einziges rohes GPT-Abbild, die auf aarch64-UEFI, x86_64-UEFI und x86_64-BIOS starten, in virtuellen Maschinen und auf echter Hardware, beginnend mit einem Intel-PC. Weiterhin ein Appliance-Gerät mit allem darin, reproduzierbar und signiert.
• Rohe Festplatte, kein Dateisystem. Eine Formatspezifikation auf Byte-Ebene, das Host-Werkzeug urmqtt-disk, das die Parser mit dem Kernel teilt, Ausrichtung der Regionen auf 1 MiB, Wachstum der Festplatte mit den Daten, Discard für Thin-Provisioning-Festplatten, A/B-Snapshots der Datenbank, Bit-Prüfung und, optional, Verschlüsselung mit AES-256-XTS mit Hardware-AES.
• Nachweislich sicher. Sperrung und Zulassungsliste von Geräten zur Laufzeit über einen signierten Steuerkanal, ohne neues Image; differenzielles und Konformitätstesten des eigenen TLS und TCP; KASLR, Stack-Schutz, kCFI, MTE und ein gehärteter Allokator; SQLite auf der Ebene EL0 isoliert; Secure Boot; SBOM und cargo-vet; und am Ende ein Paket für die externe Revision.

Plattformen, die nur Nicht-virtio-Geräte anbieten, wie AWS ENA oder Azure MANA, werden vorerst nicht unterstützt. Raspberry Pi 4 und 5 als KVM-Host, Hetzner CAX und Oracle Ampere A1 sind dokumentiert und vom Code unterstützt, aber noch nicht auf einem echten Dienst ausprobiert.

Probieren Sie es aus

Das Repository befindet sich unter github.com/zeljan-alduk/urMQTT. Mit Rust samt festgepinnter Nightly-Toolchain und QEMU genügen make certs, make run und ein mosquitto-Client für das erste PUBLISH über mTLS auf Ihrem eigenen Rechner. Die Warnung vom Anfang gilt auch am Ende: Dies ist Pre-Alpha, und alles, was funktioniert, steht in docs/PROGRESS.md. Fehlermeldungen, Fragen zum Design und Sicherheitsmeldungen gemäß der Anleitung in SECURITY.md sind willkommen. Über jeden weiteren Meilenstein berichten wir hier.

In diesem Blog halten wir fest, was wir auf diesem Weg gelernt haben. Keine Marketingtexte, sondern konkrete Notizen: was schiefgegangen ist, wie wir es gelöst haben und was wir heute anders machen würden.

Worüber wir schreiben werden

• Fahrgeldeinzug im ÖPNV. Kontaktlose Karten, SAM-Module, Offline-Betrieb und alles, was ein Terminal in einem Fahrzeug aushalten muss, das zwölf Stunden am Tag rüttelt.
• Mobile Apps im Einsatz. Android und Flutter auf Geräten, die keine gewöhnlichen Telefone sind: mit Kartenlesern, Druckern und Akkus, die eine ganze Schicht durchhalten müssen.
• Backend und Flottenüberwachung. Wie man erfährt, dass ein Gerät im Fahrzeug ein Problem hat, bevor der Fahrer es meldet.
• Hardware. Vom Prototyp auf dem Tisch bis zur Platine in der Serienfertigung, und alle Fehler dazwischen.
• Lokale KI-Modelle. Wo Modelle auf eigener Hardware sinnvoll sind und wo Cloud und API schlicht die bessere Wahl sind.

Wie wir schreiben werden

Kurz und konkret, mit Code und Zahlen, wo wir sie haben. Wir veröffentlichen, wenn wir etwas zu sagen haben, nicht nach Plan. Die Beiträge entstehen auf Kroatisch und werden in alle Sprachen dieser Website übersetzt; per RSS bleiben Sie auf dem Laufenden.

Wenn Sie ein Thema interessiert oder Sie an einem ähnlichen Problem arbeiten, schreiben Sie uns an info@aldo.tech.