Poznámka předem zůstává stejná: projekt je pre-alfa, první vydání je jen pro VPS s KVM a čísla měří kód, testy a konkrétní pokusy, ne zralost v produkci.

Jak to vypadalo v čase

Od minulého textu (31. 10. ve 23:00) do dneška (1. 11. ve 20:41) přibylo v repozitáři 59 nových commitů, celkem 178. Všechny vznikly během jednoho kalendářního dne, takže platí stejné upozornění jako dřív: projekt vzniká s Claude Code (commity nesou Co-Authored-By: Claude), plán, kód, testy a ADR se píšou v krátkých uzavřených smyčkách a čísla níže vypovídají o množství kódu a ověření, ne o tom, kolik lidské práce v nich je.

Čísla jsou spočítána stejnou metodou jako v minulém textu: všechny soubory .rs mimo vendor/ a fuzz/, funkce #[test], nadpisy ## ADR- v docs/DECISIONS.md.

Pracovalo se paralelně na více větvích, takže pořadí commitů není přesně pořadím práce. ADR jsou číslována do 232, ale číslování má mezery (část byla při slučování větví přejmenována); počítáme nadpisy, ne nejvyšší číslo. Vydání: v0.2.0 (1. 11., 18:45 UTC) a v0.2.1 (1. 11., 20:22 UTC), obě označená jako pre-release.

H6: SQLite v uživatelském režimu

Co jsme plánovali. SQLite je 254 268 řádků C, které parsují databázi, WAL a žurnál z disku, a disk může být vyroben nebo upraven. Dosud běžel v jádře, s právy jádra. Co jsme postavili (ADR-210 až ADR-212): SQLite, jeho části libc a halda byly přesunuty do samostatného programu, dbworker, který běží na EL0 (aarch64), respektive v ring 3 (x86_64), ve vlastním adresním prostoru. Jádro už SQLite nelinkuje. Worker s jádrem komunikuje přes sdílené okno paměti a dvanáct systémových volání a každá vrácená délka a offset se před použitím kontroluje. Chyba ve workeru (nepovolený přístup, nedefinovaná instrukce, překročený časový rozpočet 30 s) ukončí volání, worker se znovu spustí a databáze se otevře z WAL jako při startu; po 5 restartech za minutu se úložiště prohlásí za vadné a nespouští se donekonečna.

Cena, změřená na aarch64 pod HVF, stejná VM, jádro se vestavěným SQLite oproti jádru s workerem, šest střídavých spuštění od každého:

Zápisy na disk (1572) a flushe (319) jsou identické, jak má být. Izolováno není tohle: jádro stále věří tomu, co worker vrátí, po kontrole tvaru. Kompromitovaný worker může lhát (například vrátit prázdný seznam odvolaných certifikátů a tím je „odvolat z odvolání"), ale nemůže číst paměť jádra, klíče TLS ani klíče ticketů. KPTI není, takže úniky typu Spectre/Meltdown nejsou zabráněny a nic o nich netvrdíme; klíč PAC sdílejí EL0 a EL1. Na x86_64 jsme cenu přepínání na KVM neměřili (pod TCG by číslo bylo nesmyslné) a samotné fuzzování workeru a protokolu není hotové. Sada testů úložiště (79 scénářů, každý točí SQLite ve workeru) prochází na aarch64 HVF a x86_64 TCG, na aarch64 TCG 76 (jeden se přeskakuje, protože TCG nemá MSI-X).

H7 je uzavřen, ale ne tak, jak jsme oznámili. Dolní mez času (ADR-050) a SNTP s konsenzem (T1) pokrývají rozsah H7; NTS (RFC 8915) zůstává mimo rozsah a je zapsán jako zbývající riziko, ne jako něco, co funguje. Nepovažujeme bezpečnost času za „vyřešenou", ale za hotovou v té části, kterou lze dokázat.

Nová síťová volba. Contabo nedává DHCP vlastnímu ISO, takže VPS dosud potřeboval jiný obraz než laboratorní VM. Nyní network.mode = "auto" (ADR-214) nejprve zeptá DHCP, a pokud pronájem nepřijde v zadané lhůtě (dhcp_timeout_s, výchozí 15 s) nebo ho ztratí, použije zadanou statickou adresu. Vyzkoušeno ručně na QEMU (s DHCP použije pronájem, bez sítě se po 5 s vrátí na statickou adresu); smoke scénář pro to ještě není.

X11: srovnání s Mosquittem na stejném VPS

Stejný druh stroje jako v minulém textu (Contabo, 4 vCPU AMD EPYC, 8 GiB), zátěž z linuxového hostitele vzdáleného 15 ms, oboustranný TLS 1.3 se stejnými certifikáty na obou stranách, Mosquitto 2.0.21 na Debianu 13 bez trvalého ukládání. Metoda a rozhodnutí jsou v ADR-213, surová data v docs/perf-results/. Medián ze tří spuštění.

Co to znamená a co ne. Handshaky jsou dolní meze pro oba servery: generátor zátěže je sdílená VM s 60 až 70% ukradeného procesorového času a při 128 vláknech byl blízko vlastního limitu, zatímco pracovní jádra urMQTT byla vytížena jen z 12 až 13%. Poměr při 128 klientech (asi 2,2násobek) je nejvýznamnější; při 32 a 64 většinou měří čekání klientů. Čísla paměti nepočítají totéž (halda jádra oproti RSS procesu), takže „asi 50krát méně" je řádová hodnota, ne přesný poměr. Latence 14 ms je jedno kolo sítě (asi 15 ms), tedy „žádný měřitelný čas brokeru"; ocasy (p99 asi 100 až 200 ms) jsou u obou brokerů ovládány sdílenými hostiteli. Rozdíly pod asi 20% netvrdíme.

Co nevyšlo v náš prospěch a zůstalo v tabulkách: jediný tok TCP přes urMQTT nesl 2 až 8krát méně než přes Mosquitto, s výkyvy od nuly do 7,7 tisíce zpráv za sekundu mezi spuštěními, a 20ms watchdog handleru přerušoval živá spojení, když hypervizor zastavil vCPU (v produkčním nastavení action = "drop", 6 až 8 spojení na spuštění při zahlcení QoS 0). Obojí je popsáno v další části, protože to mělo příčiny v našem kódu.

Proč byl jediný tok pomalý: příčiny, ne výmluvy

Nejsnazší by bylo říct „sdílený VPS". Neřekli jsme to, ale s tímtéž VPS a stejnou metodou jsme hledali příčiny. Nalezlo se jich pět, čtyři v datové cestě a jedna ve watchdogu (ADR-221 až ADR-224):

Zastavení jsou skutečná: na tomto VPS měla jádra 0 až 2 medián 36 až 80 zpožděných taktů za 5 sekund a nejhorší zastavení v okně mělo medián asi 70 ms a až 0,9 s (jádro 3, databáze a žurnál: až 1,55 s), zatímco hostitel neukazuje ukradený čas (host steal 0 us). Proto watchdog potřeboval jiné hodiny, ne větší rozpočet.

Watchdog: 148 přerušených spojení ve 30 zatížených spuštěních před, 0 ve 24 spuštěních po; na lokálním zařízení, které zpožďuje a ztrácí rámce, má při ztrátě 0,1% jeden tok 64 B s 14,3k zpráv/s (jádro X11) nyní 41,0k a při 0,5% z 5,0k na 17,7k.

Co tím neříkáme. urMQTT stále není rychlejší než Mosquitto na jediném toku: při 64 B publikuje asi 80% jeho rychlosti a doručuje asi 40%, protože zahazuje QoS 0, když je tok odběratele pomalejší než vydavatelův (Mosquitto bez limitu řadí do fronty). Při 1 KiB v 16párovém zahlcení je Mosquitto vpředu asi o 15%, což je v rámci šumu. Generátor byl znovu sdílená VM s 58 až 77% ukradeného času. Druhé kolo (zamykání haldy mimo datovou cestu, SACK na straně odesílání a další) je na neintegrované větvi perf-single-flow-wip; jeho čísla zatím nejsou tvrzení a neuvádíme je zde.

Slib, který jsme nedali, ale splnili: konfigurace je data

Dosud byla každá konfigurace novým sestavením: klíče a limity byly zabudované v obrazu. C1 to obrací (ADR-215 až ADR-219): jádro se staví jednou a konfigurace jsou data.

• Blob urmqtt-cfg (C1a): verzovaný, kanonický zápis (pole podle rostoucích značek, otisk SHA-256, nepovinný oddělený podpis Ed25519), 70 polí s výchozími hodnotami a mezemi, dekodér, který odmítá vše neplatné.
• Jádro ho čte jako modul Limine (C1b), před čímkoli jiným, na aarch64 i x86_64. Existuje jedno vydané jádro pro každé ENV kromě dev (ELF aarch64 pro release, prod a bench mají stejné SHA-256; ověřeno jen na aarch64). Vydané jádro odmítne vývojovou konfiguraci a bez konfigurace napíše „refusing to serve" a nic neobsluhuje.
• Nainstalovaný disk nese konfiguraci a aktualizace ji zachovává (C1c).
• urmqtt-config a šablona ISO (C1d): pack, show, verify, a pack --iso nahradí obě kopie místa pro konfiguraci a 24 součtů modulů v hotovém ISO. Výsledek je bajt po bajtu stejný jako ISO, které sestaví mkiso.sh --config. Šablona vydání v0.2.0 má 63 111 168 bajtů.
• Prohlášení o důvěře (ADR-219): konfigurovaný obraz při startu vypíše otisk konfigurace (config: fingerprint ...), podpis je nepovinný a ve výchozím stavu vypnutý. Upravené ISO nemá oficiální součet; otisk je způsob, jak vidět, co v něm je.

Builder na aldo.tech

Totéž, co dělá urmqtt-config pack --iso, dělá i webová stránka, týmž kódem: knihovna nástroje přeložená do WebAssembly (1,06 MB, bez importů a bez bloku unsafe). Stránka je na aldo.tech/cs/produkty/urmqtt-builder/ a existuje ve všech 15 jazycích webu (například hr).

• Nic neopouští prohlížeč. Certifikáty, soukromé klíče a hotové ISO zůstávají v počítači; stránka stahuje jen soubory vydání z tohoto webu, žádné sledování ani skripty třetích stran. V živém testu žádný požadavek nenesl klíčový materiál.
• Zrcadlo vydání (ADR-227): hodinu po hodině (časovač systemd, nízká priorita) kopíruje vydání z GitHubu, každé před zveřejněním ověří a stránka v prohlížeči ověří podpis SHA256SUMS klíčem zabudovaným ve stránce, a teprve pak zapíše konfiguraci do šablony. Neúspěšné ověření stahování zablokuje.
• Jednoduše ve výchozím stavu, pokročile podle potřeby (ADR-232): první obrazovka má tři kroky (kde poběží, vaše certifikáty, název obrazu). Jedno pole pro přetažení souborů roztřídí certifikát, klíč a CA podle obsahu. Pokročilé zobrazení otevře každé z 70 polí, vyhledávání, import a export TOML; obě zobrazení upravují stejný stav. Šablona (63 MB) se stahuje, zatímco uživatel vyplňuje formulář. Při živé zkoušce, s zkušebním zrcadlem a zkušebním klíčem, trvalo sestavení ISO v prohlížeči 5 až 18 s.

Emulátor, nepovinně. Vedle „Stáhnout ISO" stojí „Vyzkoušet v emulátoru": QEMU přeložené do WebAssembly spustí právě sestavený obraz v kartě prohlížeče. Nic z něj se před kliknutím nestahuje (asi 3 MB poprvé). Emulátor je jen BIOS, bez sítě (aby provoz uživatele neprošel přes nějakého prostředníka a nenarušil „nic neopouští prohlížeč"), potřebuje asi 1,5 GB paměti a počítačový prohlížeč (testováno v Chrome; Firefox a Safari ne). V něm urMQTT dosáhne URMQTT READY za asi 8 s (s přeskočeným odpočtem) a vypíše stejný otisk konfigurace jako stránka, což je důkaz, že se spustila právě ta konfigurace. Start je asi 2krát pomalejší než původní QEMU na stejném Macu (0,82 s oproti 1,9 s) a kryptografie asi 58krát pomalejší, protože hardwarové instrukce jsou emulované. Proto z emulátoru nevyvozujeme žádná tvrzení o rychlosti a stránka to říká před spuštěním. Při sestavení bylo třeba záplatovat čtyři bajty v .wasm kvůli chybě v překladu instrukce POPCNT v původním emulátoru (zatím jsme ji nenahlásili); samotný emulátor je pod GPL, s nabídkou zdrojového kódu.

Prostý MQTT, jen pro sítě, kterým věříte

Prostý MQTT (TCP 1883, bez TLS) je v IoT velmi běžný: je výchozí v Mosquittu, ve většině firmwarů pro Arduino a ESP, v Tasmotě, Zigbee2MQTT a Home Assistantu a používá se i uvnitř segmentovaných průmyslových sítí, za VPN a na soukromých LAN, i na zařízeních bez hodin (certifikáty vyžadují datum), bez dost flashe nebo procesoru pro TLS. Přes nedůvěryhodnou síť není přijatelný: kdo je na cestě, čte a mění provoz. Proto je P1 (ADR-229 až ADR-231) výslovná, omezená volba, ve výchozím stavu vypnutá, a port TLS zůstává; TLS se tím nevypíná, prostý port přichází vedle něj.

• Seznam povolených sítí je povinný (allow_from, CIDR) a kontroluje se při SYN: mimo seznam není SYN-ACK ani stav. Celý internet (0.0.0.0/0) vyžaduje samostatnou výslovnou volbu.
• Tři způsoby přihlášení: heslo (výchozí, když je zapnuto; PBKDF2-HMAC-SHA-256, sůl, 10 000 iterací, porovnání v konstantním čase, zamykání podle adresy), anonymně (jedna nakonfigurovaná identita s vlastním ACL) a podle adresy (ip). Builder heslo hashuje v prohlížeči a v paměti drží jen součet.
• Méně práv než mTLS: prostý klient nikdy nemá servisní, operátorská ani řídicí práva, nemá $SYS ani konzoli, má vlastní relace ($plain/<identita>/<id klienta>, jen čisté), vlastní limity a registr povolených ho dál zavazuje.
• Co se ztrácí, je napsáno v SECURITY.md: důvěrnost, integrita, autentičnost brokera a opakování zachyceného přihlášení. Konfigurací se to opravit nedá; tak to je, když není TLS.

Změřeno na notebooku (Apple silicon, HVF, uživatelská síť QEMU), 16 párů, 64 B, tři spuštění po 10 s: při 8000 zprávách za sekundu doručují cesta TLS i prostá všechny zprávy se stejnou latencí (p50 0,17 ms oproti 0,13 až 0,18 ms), nová spojení za sekundu: TLS asi 2600 až 2750, anonymní prostá asi 4900 až 7800, a přihlášení heslem je drahá část: jeden PBKDF2 stojí asi 2,5 ms, takže počet nových přihlášení je omezen na asi 200 na datové jádro za sekundu (změřeno 308 až 342 na dvou jádrech). Zahlcení na tomto stroji není stabilní nástroj (20k až 440k doručených za sekundu mezi spuštěními) a nevyvozujeme z něj závěr. Srovnání prosté cesty s Mosquittem na VPS ještě nebylo provedeno. Testy: skupina smoke plaintext 7 ze 7 na aarch64 HVF i na x86_64 TCG, nový fuzz cíl plain_input (2,3 milionu spuštění bez nálezů).

Chyby, které našel provoz naživo

Dvě věci neodhalily testy, ale první zapnutí na skutečném webu:

• Stránka hledala soubory vydání o jeden adresář výš, takže každé ověření podpisu odpovědělo 404 (oprava 13af301). Test používal zkušební zrcadlo na jiné cestě.
• Klávesnice emulátoru nikdy nedorazila k hostu: příčinou nebyl špatný překlad kláves, ale to, že dialog klávesy vůbec neposlouchal (oprava v ADR-232, s položkou pro start bez kláves).

Poučení

• Hledejte příčinu, neviňte prostředí. Většina slabin jediného toku a všechna přerušená spojení byly naše; hypervizor je skutečný, ale bylo třeba ho měřit, ne předpokládat.
• Srovnání s jiným produktem musí zahrnovat i ztráty. Tabulka, v níž jsou jen naše výhry, by nebyla srovnáním.
• Měřicí přístroj má meze. Sdílený generátor s 60 až 70% ukradeného času mění, co čísla znamenají; proto píšeme „dolní mez" a netvrdíme rozdíly pod 20%.
• Izolace není důkaz. SQLite v EL0 zmenšuje, co může způsobit chyba v něm, ne to, co může lhát.
• Skutečná instalace najde to, co testy nehledají: cestu, která je špatně složena, a klávesy, které nikdo neposlouchá.

Co ještě není dokázáno

• Podpisový klíč vydání je zatím zkušební klíč; v0.2.0 a v0.2.1 jsou pre-release a obrazy k nim jsou vývojové se zkušebními certifikáty (kromě šablony, která je bez konfigurace).
• 13 překladů stránky builderu (a tohoto textu) napsala AI a ověřily je testy a vzorky, ne rodilí mluvčí.
• Srovnání s Mosquittem je jedna relace, jedna cesta a jeden sdílený generátor, na sdíleném VPS; rozdíly pod 20% nejsou tvrzení.
• Prostá cesta nebyla měřena na VPS ani proti Mosquittu.
• Lighthouse na novém jednoduchém zobrazení není potvrzen (staré zobrazení: přístupnost 95 nebo více).
• Bare metal, cena workeru na x86_64 na KVM, Firefox a Safari pro emulátor: neměřeno.

Co následuje

• D1: veřejný demo broker. Emulátor z prohlížeče nemůžeme udělat veřejným: žije v kartě jednoho návštěvníka, je 20 až 100krát pomalejší než KVM, nemá příchozí síť a zmizí se zavřením karty; přesměrování internetu do cizího prohlížeče by bylo i zneužitím. Možný je skutečný demo broker: urMQTT na VPS za jménem na aldo.tech, s publikovanou zkušební CA, přísným ACL a malými limity. Zatím je to jen nápad, ne stavba, a vyžaduje výslovný souhlas s veřejným vystavením.
• Druhé kolo pro jediný tok (větev perf-single-flow-wip): teprve až bude změřeno na VPS a sloučeno.
• Prostá cesta proti Mosquittu na VPS, přihlášení a odvolání účtu pro prostý MQTT přes podepsaný řídicí kanál.
• Po vydání: bare metal (X12 až X16), IOMMU a Secure Boot, šifrování disku.

Kód je na github.com/zeljan-alduk/urMQTT a docs/PROGRESS.md zůstává jediným zdrojem pravdy o tom, co skutečně funguje, docs/PERFORMANCE.md o tom, co bylo změřeno. Pre-alfa, jako dříve; hlášení chyb a bezpečnostní hlášení podle pokynů v SECURITY.md jsou vítána.

Jedna poznámka předem: projekt je pořád pre-alfa. Čísla v textu měří kód a testy, ne zralost v produkci, a první vydání je záměrně omezené na VPS s KVM. Bare metal zůstává na později.

Jak to vypadalo v čase

První commit vznikl 28. října 2026 ve 23:48 (M0). Do 31. října ve 23:00 má repozitář 119 commitů, rozložených jako 3, 39, 38 a 39 podle kalendářních dní. Hned řekněme, jak je to možné: projekt vzniká s Claude Code a commity nesou trailery Co-Authored-By: Claude. Čtyři kalendářní dny historie neznamenají, že jeden člověk napsal za čtyři dny 90 000 řádků; znamenají, že plán, implementace, testy a ADR se píšou v krátkých uzavřených smyčkách a každý krok končí stejným ověřovacím rituálem jako dřív. Čísla níže vypovídají o množství kódu a testů, ne o tom, kolik skutečné práce to všechno obnášelo.

Graf ukazuje tři křivky, které rostou téměř společně, což je záměr: testy a zapsaná rozhodnutí kód doprovázejí, a nezaostávají za ním. Sklon je nejstrmější 29. října, kdy vzniká celá cesta od jádra k brokeru. Dál se řádky přidávají pomaleji, ale testy rostou rychleji než kód (27 testů na 1,6 tisíce řádků na začátku, 739 na 89,8 tisíce dnes).

Řádky jsou všechny soubory .rs mimo vendor/ a fuzz/, testy jsou funkce #[test]. Co který úsek přidal, podle data z historie gitu:

Slib 1: jedno ISO pro více platforem

Co jsme plánovali. Jeden soubor, který nabootuje na aarch64 UEFI, x86_64 UEFI a x86_64 BIOS. Co jsme postavili. Port na x86_64 (X0 až X10) a univerzální ISO s bootloaderem Limine, jediné hybridní ISO, z něhož se zavádějí všechny tyto kombinace; kouřové testy ho spouštějí na čtyřech virtuálních strojích. Nabídka má tři položky: urMQTT (živý režim, běží z RAM, nic nezapisuje na disk), instalace na disk stroje, na kterém běží (instalace zapíše GPT a data a poté stroj vypne) a Diagnostika (detekce hardwaru a měření).

Prvním skutečným cílem byl VPS, ne fyzický počítač: rozhodnutí zní, že první vydání podporuje jen VPS (KVM) a bare metal přijde po něm. Testovali jsme na VPS u Contabo s procesorem AMD EPYC (rodina 23, Zen 1), 4 vCPU a 8 GiB RAM, se sítí virtio-net a diskem virtio-scsi. První pokus nás překvapil: ISO připojené jako virtuální CD spustilo výchozí položku, produkční obraz odmítl běžet z média jen pro čtení a resetoval se, takže vznikla nekonečná smyčka nabídka, jádro, reset bez čehokoli čitelného. Dnes fatální chyba v produkčním obrazu nechá zprávu na konzoli 60 sekund před resetem a z optického média vypíše, že bylo spuštěno z média jen pro čtení, a zastaví se. Živý režim v RAM (O3) později tento problém pro běžný případ obešel.

Diagnostická položka vznikla z této zkušenosti: stroj, který nevidíme, se musíme umět zeptat, co má. Vypisuje CPU, RAM, síť, disky a zařízení PCI, měří propustnost paměti, disk a kryptografii a stejná měření vypisuje jako JSON na sériový port. Zápis na disk je povolený jen v nepřiděleném prostoru a až po zadání WIPE; na snímku níže byl přeskočen.

Co zůstává otevřené. Skutečný hardware. Po prvním vydání přijde bare metal (zavádění z USB, NVMe a AHCI, síťová karta skutečného počítače) spolu s IOMMU a Secure Bootem, protože bez IOMMU může zlovolné nebo vadné zařízení zapisovat do celé paměti. V této verzi o tom nic netvrdíme.

Handshake: z 1,2 ms na 0,24 ms

První měření diagnostiky na VPS dalo nepříjemné číslo: mTLS handshake, jen kryptografie na straně serveru, trval 1,2 ms. Na aarch64 jsme už používali hardwarové instrukce AES a SHA, ale x86_64 nemělo nic podobného pro veřejný klíč: RustCrypto je přenositelné a constant-time, a tedy i pomalé. Srazily to tři změny.

• Pro P-256 jsme převzali assembler nistz256 z OpenSSL a ring (ADR-130), spolu s tabulkami s pevnou bází pro podpis a ověření podpisu CA (ADR-110, ADR-111).
• X25519 bylo přepsáno na čtyři 64bitové končetiny s instrukcemi MULX/ADX (ADR-131).
• Poté jsme zprofilovali i zbytek (ADR-132, ADR-200).

Čísla se mezi spuštěními liší asi o 10 %, proto jsme zapsali rozsah místo jedné hodnoty. Celkově je to zhruba pětkrát méně CPU času na handshake.

Co jsme se naučili o memcpy. Když kryptografie klesla, profil ukázal něco, co jsme nečekali: funkce mem* (memcpy, memmove, memset) spotřebovávaly 7 % handshaku, 13 až 39 % cesty TLS záznamu (39 % pro 64 B, 13 % pro 4 KiB) a 17 až 34 % rozdělování PUBLISH. Nahradili jsme je assemblerem SSE2 pro x86_64 (ADR-200), s diferenciálními testy proti referenční implementaci pro všechny velikosti, zarovnání a překryvy. Na jedno volání je to 55 až 75 cyklů oproti 7 až 12 pro 1 až 64 bajtů.

Jak číst graf: čím menší záznam, tím větší část času jde na kopírování, a tím větší je i zisk. U malých zpráv, které tvoří většinu provozu MQTT, to je to, co se počítá.

Co to neznamená. Na nativním x86_64 jsme OpenSSL 3.5.5 (ADR-130) měřili jen jako referenci pro assembler, ne jako srovnání produktů. Srovnání Linuxu s Mosquittem na stejném VPS (úkol X11) jsme ještě neudělali. Proto netvrdíme, že urMQTT je rychlejší než Linux: nebylo to změřeno. Čísla výše srovnávají urMQTT samo se sebou.

Přetížení bylo druhým výsledkem. Na VPS, z jednoho Macu (RTT 35 ms), dalo 128 klientů 618 handshaků za sekundu, 256 klientů 393 a 512 klientů 67, s tisíci odmítnutých spojení. Nebyla to plošina, ale zhroucení. Příčiny jsme našli v kódu (dvě jsou potvrzené v QEMU/HVF, na VPS se zopakovat nedaly), několik najednou: odmítnuté spojení vracelo klienta přes další segment, který nese platnou cookie SYN, odmítnutí pomocí RST říkalo klientovi, aby to hned zkusil znovu, a příjem byl O(fronta). Oprava (ADR-080 až ADR-082) zahazuje SYN, který by nebyl přijat, pamatuje si odmítnuté toky, drží příjem v O(1) a počítá handshaky na jádro. Je možné (hypotéza, neověřeno), že část příčiny byla i na straně klienta: nástroj pro zátěž zavíral spojení jako první, takže jeden Mac s 16 384 efemérními porty a TIME_WAIT 30 sekund byl omezen na zhruba 550 spojení za sekundu. Proto skutečný strop serveru stále nemáme změřený.

Slib 2: surový disk, ale opatrný

Co jsme plánovali. Zachovat vlastní rozvržení bez souborového systému a doplnit vše, co souborový systém obvykle dává: zarovnání, růst, discard, zálohy a kontroly. Proč ne souborový systém. Diskutovali jsme o tom a rozhodnutí se potvrdilo: urMQTT zapisuje jednu databázi, jeden telemetrický žurnál a vlastní metadata, nepotřebuje adresáře, oprávnění ani názvy souborů, a každá další vrstva by byla další kód v důvěryhodné části a další způsob, jak může zápis tiše zmizet. Disk je GPT s oddílem ESP a jedním datovým oddílem urMQTT, na kterém je vlastní rozvržení.

Co jsme postavili (S2 až S6).

• Rozvržení v2 (S2). Topologie disku, zarovnání na 1 MiB nebo optimální velikost I/O, celé fyzické bloky, A/B dvojice superbloků s generací (ADR-140). Rozvržení v1 jádro odmítne s jasnou zprávou a migruje ho offline nástroj urmqtt-disk migrate (ADR-141): výchozí je zkušební průchod, kopíruje se a teprve potom přepíná, s návratem a vkládáním chyb při každém zápisu.
• Růst (S3). Při startu může disk narůst (nikdy se nezmenšuje) a na virtio-blk i za běhu, přes přerušení změny konfigurace (ADR-142, ADR-143).
• Discard a write-zeroes (S4). Tence přidělené disky vracejí prostor hostiteli. V testu klesl soubor qcow2 na hostiteli z 62 na 16 MiB poté, co vypršely telemetrické segmenty, a obnova nikdy nedůvěřuje obsahu, který byl zahozen.
• Záloha databáze na disku (S5). Kopie A/B pomocí online backup API SQLite po krocích po 16 stránkách: nejdelší krok 4,6 ms oproti 445 ms při kopírování jedním voláním. Commity během kopie měly maximum 2,4 ms oproti 2,2 ms bez ní. Pokud quick_check při startu selže, databáze se obnoví z kopie.
• Čištění a omezený start (S6). Scrubber čte disk s omezeným rozpočtem I/O a hlásí poškozené záznamy a start čte jen nejnovější segment každého oddílu, takže doba startu neroste s velikostí telemetrické oblasti. Tím jsme uzavřeli problém, který jsme si předem spočítali: na velkém disku by úplná obnova trvala od minut do desítek minut.

Celá skupina kouřových testů pro úložiště prochází na obou architekturách: 79 úspěšných, 0 neúspěšných, na aarch64 pod HVF a na x86_64 pod TCG. Měřili jsme také, že S4 databázi nezpomalil: 53,3 tisíce vložení za sekundu v dávkách před i po, bez měřitelného rozdílu.

Co překvapilo. Kolik z „jednoduchého" rozvržení tvoří okrajové případy: virtio-scsi a virtio-blk hlásí topologii různými způsoby a neúplný zápis uprostřed migrace musí vždy ponechat alespoň jednu platnou verzi. Proto každý zápis na cestě migrace a růstu prošel vkládáním chyb.

Co zůstává otevřené. Stránky SQLite nemají kontrolní součet, takže změněný bit uvnitř hodnoty v řádku databáze neodhalí; telemetrické záznamy a obsah kopií mají CRC a odhalí se. Šifrování disku (S7) není hotové.

Slib 3: prokazatelně bezpečné, nakolik to dokážeme

Zpevnění (H4). Alokátor maže uvolněnou paměť a kontroluje ji při opětovném použití, odhaluje dvojí uvolnění, váže ukazatele volného seznamu pomocí XOR a nuluje klíče při uvolnění (ADR-170). Ochrana zásobníku (-Zstack-protector=strong, 1315 funkcí, a SQLite s -fstack-protector-strong, ADR-171). Hlášení chyb v produkci neobsahují registry ani adresy (ADR-172). KASLR na obou architekturách: jádro je PIE a Limine ho posouvá asi o 19 bitů, a náhodně se umísťují halda, zásobníky a okno MMIO (ADR-173). Na aarch64 MTE označuje haldu (ADR-174), ale jen pod TCG: HVF a x86 ho nemají. kCFI jsme vyhodnotili a nepřijali, protože překladač na připnutém nightly padá s vnitřní chybou; IOMMU je odloženo spolu s bare metalem (ADR-175, ADR-176).

Cena je změřená, ne předpokládaná. Na cestě handshaku (dp-bench, aarch64 HVF, plné handshaky TLS 1.3 + mTLS + CONNECT):

Celkově je tedy cena na cestě handshaku zhruba 5 % pro části měřené čistě a s PIE a značkami vychází asi 7 % na jednom a asi 11 % na čtyřech jádrech, ale toto měření je zašuměné. Považujeme ji za přijatelnou, ale neopakovali jsme ji na x86_64 VPS.

Stojí za to porovnat s číslem z prvního textu (862 handshaků za sekundu na jednom jádře). Stejný nástroj dnes, s ovladačem hardwarového šifrování na aarch64 (X0b) a řadou zrychlení, která od té doby přišla, dává před zpevněním 1941. Příspěvek každé změny jsme neizolovali, takže o příčině nic netvrdíme.

Jak je to ověřeno, a co ne. H5 přidal Miri na podmnožinu hostitelských crate, důkazy Kani, sanitizery, model-fuzzer pro ACL a hlášení o pokrytí. Kani dokázal record_len v TLS, parse v TCP a dvě aritmetiky kola časovačů. Nedokázáno (vypršel čas): oba dekodéry MQTT, obě parsování konfigurace a chování kola časovačů; úloha CI pro Kani proto zatím neblokuje. Miri neumí spouštět assembler. Dodavatelský řetězec (H9): SBOM CycloneDX s 215 komponentami, cargo-vet prochází s 39 plně zrevidovanými a 140 výjimkami, a cargo-deny je nakonfigurováno tak, že upozornění na zranitelnosti bere jako selhání CI (tyto úlohy CI byly zatím ověřeny jen lokálně, ne na GitHubu, a negativní test nebyl spuštěn), spolu s VULNERABILITY-HANDLING.md. Poctivý stav: ze 67 verzí cizích crate linkovaných do jádra je 53 výjimek, ne revizí. Vet dokazuje, že množinu závislostí nelze změnit bez viditelného rozdílu, ne že TCB byla zkontrolována. Vlastní revizi žádného crate jsme nenapsali.

SNTP (T1) je v tomto smyslu malý příběh o bezpečnosti: je volitelné, jen vůči soukromým serverům IPv4, s maximálním skokem a podmínkou shody zdrojů (medián, většina do jedné sekundy). Hodiny, které může kdokoli na cestě posunout, nejsou hodiny, kterým smíme věřit při platnosti certifikátů.

Na Macu: aarch64 nativně a x86_64 emulací

Vyvíjíme na Macu a ten má dva způsoby, jak spustit stejný kód, a jsou velmi odlišné.

Pravidlo je jednoduché: čísla pod TCG jsou emulace a necitujeme je jako výkon. Výkon x86 měříme jen na skutečném VPS. Proto kryptografická čísla výše pocházejí z VPS u Contabo, ne z Macu.

Lekce

• Měřte na skutečném stroji, než začnete optimalizovat. První přístup byl optimalizovat to, co jsme považovali za pomalé; teprve diagnostika na VPS ukázala 1,2 ms a kam přesně čas odchází.
• Přetížení je samostatná vlastnost. Systém, který je rychlý pod zátěží, se může nad ní zhroutit; odmítnutí musí být levnější než přijetí.
• Profil překvapuje. Největší jednotlivý zisk pro malé zprávy nebyl v kryptografii, ale v kopírování paměti.
• Disk bez souborového systému vyžaduje víc práce, ne méně. To, co souborový systém obvykle dává (zarovnání, růst, discard, kopie, kontroly), musíme napsat a ověřit sami, každý krok s vkládáním chyb.
• Poctivost v číslech. Měření paměti na sdíleném VPS kolísají až 10krát mezi spuštěními a o kódu nic nevypovídají, proto je neuvádíme. Kryptografická čísla jsou stabilní do asi 10 %.
• Rychlost vývoje není zralost. Testy a ADR rostou s kódem, ale čtyři dny nejsou skutečný provoz.

Co následuje

• H6: SQLite izolované na úrovni EL0, aby chyba v databázi neotevřela jádro.
• H7: zbytek bezpečnosti času (NTS a zpracování skoků); SNTP je teprve první krok.
• X11: srovnání s Linuxem a Mosquittem na stejném VPS, teprve pak má smysl mluvit o relativní rychlosti.
• Vydání: první veřejné vydání pro VPS (KVM), s podepsanými artefakty a návody.
• Po vydání: bare metal (X12 až X16), IOMMU a Secure Boot a šifrování disku.

Kód je na github.com/zeljan-alduk/urMQTT a docs/PROGRESS.md je pořád jediným zdrojem pravdy o tom, co skutečně funguje. Pre-alfa, jako dřív; hlášení chyb a bezpečnostní hlášení podle pokynů v SECURITY.md jsou vítána.

Tak vznikl urMQTT: unikernel, který je MQTT broker. Jádro, TCP/IP, TLS 1.3, MQTT a vestavěná databáze v jediném binárním programu v Rustu, který se spouští z jediného ISO. Žádné procesy, žádná systémová volání, žádný shell. První platforma, na které vzniká a je testován, je aarch64, a stejný kód míří na x86_64, přes UEFI i klasický BIOS, a na skutečný hardware: cílem je jedno ISO, které nabootuje na všech. Projekt je open source pod licencí MIT nebo Apache 2.0 a v tomto textu chceme zaznamenat, kde jsme, jak je uvnitř poskládaný a co jsme se cestou naučili.

Co přesně znamená „unikernel"

Běžný broker je program, který běží na operačním systému. urMQTT pod sebou žádný operační systém nemá: zavádí se sám přes firmware UEFI a bootloader Limine, nastavuje si vlastní stránkové tabulky, programuje řadič přerušení a časovač, nachází zařízení virtio přes PCIe, získá adresu pomocí DHCP a naslouchá na jediném portu. Všechno, co by jinak dělalo jádro, ovladače, síťový zásobník a aplikace, je tady jediný ELF běžící na úrovni EL1.

Srovnání s typickou instalací mluví samo za sebe:

Priority jsou v tomto pořadí: bezpečnost, škálovatelnost, vícejádrový výkon, malá stopa a neměnná instalace. Kdykoli jsou dva cíle v rozporu, vítězí ten, který je na tomto seznamu výše.

Kde jsme teď

Projekt je v pre-alfa fázi, ale uzavřeli jsme sedmnáct vývojových milníků, od M0 do M17. Dnes urMQTT obsluhuje MQTT 3.1.1 přes TLS 1.3 s povinnými klientskými certifikáty a stav ukládá do SQLite na surovém disku. Stručně, co už funguje:

• Jádro: vlastní vektory výjimek s dekódovanými hlášeními, vlastní stránkové tabulky s vynuceným W^X, ochranné stránky, PAC a BTI tam, kde je procesor má, GICv3 a GICv2, generický časovač, SMP až do 64 jader.
• Detekce hardwaru z DTB nebo ACPI do jednoho popisu platformy, s totožným výsledkem z obou zdrojů.
• Ovladače: PCIe ECAM, MSI-X, virtio-net, virtio-blk, virtio-scsi a virtio-rng, a také CSPRNG osazený hardwarovou entropií.
• Síť: vlastní DHCPv4, ARP, ICMP a přísné IPv4, dále vlastní TCP pouze pro stranu serveru: SYN cookies, hierarchické kolo časovačů, NewReno, slučování ACK, bez stavu TIME_WAIT.
• TLS: pouze TLS 1.3, povinné mTLS, identita zařízení z CN nebo SAN URI; handshake zajišťuje rustls, po něm následuje vlastní vrstva záznamů s AES-128-GCM a ChaCha20-Poly1305. Obnovení relace pomocí PSK ticketů, seznam odvolaných certifikátů, řízení příjmu už při handshaku.
• MQTT: kodek bez kopírování, fuzzovaný a testovaný se skutečnými klienty mosquitto; QoS 0 a 1, zástupné znaky, retained zprávy, závěť (LWT), trvalé relace, ACL s omezením na devices/{id}/#, limity rychlosti na zařízení.
• Úložiště: SQLite uvnitř jádra přes VFS nad surovým diskem, v režimu WAL, s kontrolou integrity při startu; registr zařízení, odvolání, retained zprávy, trvalé relace s frontami zpráv pro zařízení, která jsou offline; na každé jádro samostatný telemetrický žurnál s CRC u každého záznamu a obnovou po pádu.
• Provoz a dohled: watchdog časovač pro obslužné rutiny, kontrola zdraví, omezené logování, syslog a statsd přes UDP, řízení příjmu, které přežije bouře opakovaných připojení.
• Dodání: bitově shodné opakované sestavení ověřované v CI, ISO a surový obraz disku GPT, podpisy minisign, návody pro KVM, Proxmox a Hetzner.

Každý krok je označen milníkem, který jej přinesl, a soubor docs/PROGRESS.md v repozitáři je jediným zdrojem pravdy o tom, co skutečně funguje.

Architektura ve třech obrázcích

Celý návrh je popsán v docs/ARCHITECTURE.md a důvody každého důležitějšího rozhodnutí jsou zapsány jako ADR v docs/DECISIONS.md. Zde je přehled.

Vrstvy

Odshora dolů: broker (relace, strom témat, QoS, retained zprávy, závěti, ACL, limity), kodek MQTT, TLS, TCP, síťová vrstva a pak ovladače. Vedle této hlavní cesty stojí úložiště (SQLite a telemetrický žurnál) a pod vším správa paměti, detekce platformy a konfigurace přeložená v době sestavení do konstant, spolu s vestavěným certifikátem CA, serverovým certifikátem a klíčem. Hypervizor se zařízeními virtio je jediné, co je mimo obraz.

Vlákno na jádro, bez sdíleného stavu

Každé datové jádro točí vlastní smyčku s vlastním zásobníkem TCP, stavy TLS, částí brokeru (relace a strom témat), cache haldy a oddílem telemetrie. Jádra nesdílejí žádný měnitelný stav, jen omezené prstence bez zámků, po jednom pro každou uspořádanou dvojici jader. Nejvyšší jádro spouští SQLite a nic jiného.

Síťová karta má dnes jeden pár front, který drží jádro 0. To každý tok MQTT podle Toeplitzova hashe jeho čtveřice směruje na jedno z pracovních jader a odesílá to, co pracovní jádra vrátí. Relace žije na svém domovském jádře, určeném hashem identifikátoru klienta, takže převzetí, závěti a trvanlivost nikdy nepřekračují hranice jader. Spojení, které přistane na jiném jádře, si tam ponechá svůj TCP a TLS, a běžný MQTT předává domovskému jádru s řízením toku založeným na kreditech. Každá směrovaná zpráva se rozesílá také ostatním částem brokeru, z nichž každá drží repliku retained zpráv.

Tento model drží pohromadě tři pravidla. Zpracování do konce: přijatý paket se zpracuje celý na jednom jádře, od TCP přes dešifrování TLS na místě, parsování MQTT a směrování až po šifrovanou odpověď, bez front úloh a bez kopírování do aplikačních vyrovnávacích pamětí. Adaptivní dotazování: pod zátěží se přijímací fronty aktivně dotazují, v klidu se jádro vrací k přerušením a WFI; obslužné rutiny přerušení pouze potvrdí přerušení a označí práci. Watchdog časovač: tik 10 ms na jádro zachytí obslužné rutiny, které překročí svůj rozpočet.

Život jednoho PUBLISH

Zařízení pošle záznam TLS. Síťová karta jej předá smyčce jádra deskriptorem, bez kopírování. Smyčka zkontroluje TCP, dešifruje TLS na místě a parsuje MQTT z vypůjčené vyrovnávací paměti, poté v paměti zkontroluje ACL, limit rychlosti a cestu stromem témat. Pokud má o toto téma zájem jiné jádro, dostane směrovací zprávu s odkazem na obsah a identifikátorem tématu; databáze dostane telemetrický záznam nebo aktualizaci retained zprávy, v dávce. Odpověď PUBACK se šifruje přímo do odchozí vyrovnávací paměti a sloučí se s TCP ACK, takže zařízení odchází jediný segment. Jiné jádro zpráva stojí jedno šifrování na odběratele v okamžiku odeslání.

Kolik stojí jedno spojení

Cílem je nejvýše 512 bajtů na nečinné TLS spojení, s ambicí dosáhnout 256. Dokud spojení odpočívá, nic se pro něj nedrží ve vyrovnávací paměti: přijatá data se zpracovávají přímo ze síťového rámce a vyrovnávací paměti pro odesílání, záznamy a MQTT existují jen tehdy, když je něco nedokončeno nebo nepotvrzeno. Jádro to samo měří: přesné čítače haldy v požadovaných bajtech i v blocích, které zabírají, zapisované každých deset sekund jako halda nad základní úrovní na otevřené spojení.

Naměřeno pod HVF se čtyřmi virtuálními jádry, z toho třemi pracovními, přičemž každé zařízení drží spojení mTLS a jedno předplatné s QoS 1, včetně zaokrouhlování alokátoru:

Fond síťových rámců je pevný, zhruba 2 MiB, což je přibližně 200 B na spojení při deseti tisících spojení a asi 2 B při milionu. Více jsme změřit nedokázali: uživatelská síť QEMU na macOS přestala přijímat spojení na 10 197, zhruba na hranici 10 240 deskriptorů procesu QEMU. Číslo klesá, jak se pevné části rozkládají na více spojení, takže neroste s jejich počtem.

Bezpečnostní model

Bezpečnost je první priorita a vyhrává všechny rozpory s ostatními cíli. Model má několik vrstev:

• Jeden port. TCP 8883, pouze TLS 1.3, povinné klientské certifikáty podepsané CA vestavěnou do obrazu. Identifikátor klienta MQTT musí být shodný s identifikátorem zařízení z certifikátu.
• Žádný vstup. Žádný shell, konzolový vstup, SSH, administrační API, dynamický kód, SQL dostupný po síti ani souborový systém.
• Paměťová bezpečnost. Rust, s forbid(unsafe_code) v protokolových balíčcích; každý blok unsafe má komentář // SAFETY:, který kontroluje lint, a na vnější vstup nedochází k panice: clippy v balíčcích na datové cestě zakazuje unwrap, expect, indexování a panic!.
• Zmírnění zneužití. W^X se vynucuje kódováním deskriptorů a bitem SCTLR_EL1.WXN a revidují se při každém startu. Stránkové tabulky jsou po startu pouze pro čtení, bez zapisovatelného aliasu. Dolní polovina adresního prostoru je vyloučena. Každý zásobník má ochranné stránky a výjimky běží na samostatném zásobníku. PAC a BTI se zapínají, když je procesor podporuje, a ověřují to kouřové testy.
• Odolnost proti zneužití. SYN cookies; řízení příjmu odmítá nová spojení, ještě před jakoukoli kryptografií, když je halda nízká, když databáze zaostává, když je příliš mnoho probíhajících handshaků na jádro nebo na zdrojovou adresu nebo když je rychlost handshaků příliš vysoká. Limity rychlosti na zařízení, omezené fronty, TCP okno vázané na protitlak brokeru, omezené logování, watchdog časovač a kontrola zdraví.
• Neměnnost. Konfigurace, CA a serverový klíč jsou vestavěny do obrazu. Změna čehokoli znamená nový obraz.

Model hrozeb je zapsán v docs/SECURITY.md.

Úložiště bez souborového systému

Data žijí na samostatném disku, virtio-blk nebo virtio-scsi, na kterém není souborový systém. Rozvržení je minimální a vlastní:

LBA 0      [ superblok: magické číslo · verze rozvržení · uuid · tabulka oblastí · CRC-32C ]
LBA 8, 16  [ tabulka velikostí souborů, sloty A/B (vítězí nejnovější platný) ]
LBA 64     [ hlavní databáze SQLite ½ ][ SQLite WAL ⅛ ][ žurnál 1 MiB ][ telemetrický žurnál: 8 oddílů … ]
poslední 4 KiB [ prostor pro sebetest blokového zařízení při startu ]

SQLite (vendorovaná verze 3.54.1, s kontrolou otisku při sestavení) je přeložen do jádra clangem, bez standardní knihovny, a používá pevnou haldu memsys5. Jeho VFS mapuje tři pevné soubory na oblasti disku. Běží v režimu WAL s locking_mode=EXCLUSIVE, takže nepotřebuje index ve sdílené paměti, a se synchronous=FULL; pokud quick_check při startu najde chybu, systém se bezpečně zastaví. V databázi jsou registr zařízení, odvolání, retained zprávy a trvalé relace s frontami zpráv QoS 1 pro zařízení, která nejsou připojena.

Jádro pro databázi, to s nejvyšším číslem, spouští SQLite a nic jiného. Datová rovina mu posílá změny stavu přes prstenec SPSC bez zámků; ono je shromažďuje do jedné transakce každých 5 ms nebo každých 512 operací a potvrzení vrací druhým prstencem. Prázdný disk se naformátuje při prvním startu; nic jiného se nikdy nepřeformátovává.

Telemetrie jde jinou cestou. Každý přijatý PUBLISH na tématech z storage.telemetry_topics odchází do oddílu telemetrického žurnálu svého jádra: prstenec segmentů s CRC u každého záznamu, osolený sekvencí segmentu, takže se staré průchody prstencem nikdy znovu neobjeví. Jádra předávají záznamy databázi vlastním prstencem, bez kopírování, a ta je zapisuje každých 5 ms nebo každých 256 KiB. Při startu obnova zachová každý zapsaný záznam, odřízne nedokončený konec a pokračuje v novém segmentu. Uchovávání je podle velikosti, přes prstenec, i podle stáří, přes retention_days. Ověřili jsme to s milionem záznamů a s kill -9 uprostřed zápisu.

Čísla

Nástroj pro zátěž v tools/loadgen dělá tři věci: bouři handshaků TLS 1.3 s mTLS a CONNECT, dlouhodobá spojení s PINGREQ, která každou sekundu publikují telemetrii, a bouře opakovaných připojení. make bench na Apple M4 Pro pod HVF dává:

Číslo v hostu, kde jsou klient i server uvnitř téhož virtuálního stroje a každé pracovní jádro běží samo za sebe, ukazuje, že datová rovina škáluje lineárně. Síťové číslo je omezeno jednovláknovou uživatelskou sítí QEMU, ne hostem; i to je zapsáno jako ADR-032.

Bouře opakovaných připojení testujeme tak, že se všechna zařízení připojí najednou, odmítnuté pokusy opakují se zpožděním a pak všechna spadnou bez DISCONNECT. Parametr heap_limit_mb= ve vývojovém režimu přiměje řízení příjmu považovat haldu za menší, než je, takže bouři větší než halda lze vyzkoušet s malým počtem socketů. V jednom takovém kole s 3 000 zařízeními se připojilo 1 368 za 36 sekund a 5 619 pokusů bylo řádně odmítnuto, při limitu 8 MiB; paměť se po bouři vrátila.

Jak pracujeme

Projekt řídí psaná specifikace, PROMPT.md, s plánem milníků, a každý milník končí stejným rituálem: make check a make smoke zelené, jeden commit se štítkem M<n>, zápis v docs/PROGRESS.md a ADR pro každé rozhodnutí, které není zřejmé. Pravidla jsou krátká a nevyjednáváme o nich: žádná panika na vnější vstup, unsafe jen v hardwarových balíčcích a balíčcích FFI a vždy s komentářem, žádné alokace na horké cestě, komentář u každého pořadí atomických operací, každý limit pochází z konfigurace a záměrné provizorní části selhávají nahlas.

CI dělá víc, než bychom stihli ručně: fmt, clippy pro host i pro aarch64-unknown-none, typos, actionlint a shellcheck; testy na Linuxu a macOS na arm64; sestavení jádra pro vývojovou i produkční konfiguraci s velikostí ELF v souhrnu; start pod QEMU se všemi scénáři kouřového testu a ukládáním sériových logů; cargo-deny pro bezpečnostní upozornění, licence a zdroje; minutu fuzzingu na každý z jedenácti cílů a v noci deset minut na cíl s korpusem v cache. K tomu CodeQL, OpenSSF Scorecard, Dependabot a vydání s původem SLSA. Každá cizí akce je připnutá na úplný SHA commitu.

Reprodukovatelnost chápeme doslova: make repro sestaví HEAD dvakrát v čerstvých pracovních stromech a porovná ELF, ISO i surový obraz bajt po bajtu. Vydání jsou podepsána minisign a artefakty lze ověřit pomocí gh attestation verify. Produkční obraz obsahuje soukromý klíč serveru, takže samotné ISO je tajemství; obrazy u vydání na GitHubu jsou vývojové, s dočasnými klíči, a slouží jen k vyzkoušení.

Co jsme se naučili

Několik lekcí, které změnily plán:

• Vlastní TCP se přece jen vyplatilo. Prototyp běžel na smoltcp a dobře nám sloužil do M13. Server, který drží stovky tisíc spojení, ale nepotřebuje klientské TCP, potřebuje SYN cookies, kolo časovačů a stav o 96 bajtech. V M14 jsme smoltcp nahradili vlastním zásobníkem pouze pro stranu serveru, s testy simulované ztráty a fuzzingem segmentů.
• Paměť měřte zevnitř. Odhady na spojení byly k ničemu, dokud jádro samo nezačalo počítat haldu v blocích alokátoru, a ne v požadovaných bajtech. Teprve pak jsme viděli, kam 512 bajtů skutečně odchází, a sestoupili jsme na 494.
• Nástroj pro testování je součást produktu. Největším omezením nebylo jádro, ale uživatelská síť QEMU a počet efemérních portů na vývojovém počítači. Pro sto tisíc a více spojení je potřeba vmnet-shared na macOS nebo Linux s KVM, rozhraním tap a více klientskými adresami.
• SQLite bez operačního systému je možné, ale jen za přísných podmínek: pevná halda, exkluzivní zamykání bez sdílené paměti, VFS, které o souborech neví, a řízení příjmu, které nepustí databázi do zpoždění.
• Bouře opakovaných připojení jsou běžný stav, ne výjimka. Když spadne mobilní síť a vrátí se, tisíce zařízení klepou současně. Proto řízení příjmu odmítá spojení před jakoukoli kryptografií a každé odmítnuté spojení stojí téměř nic.

Co následuje

Práce po M17 je naplánována ve třech směrech a pořadí mezi nimi je zapsáno v docs/PLAN.md. Nic z toho zatím není postaveno.

• Jedno ISO pro více platforem. Stejný soubor urmqtt-<env>-<verze>.iso a jeden surový obraz GPT, které se zavádějí na aarch64 UEFI, x86_64 UEFI a x86_64 BIOS, ve virtuálních strojích i na skutečném hardwaru, počínaje jedním Intel PC. Stále zařízení se vším uvnitř, reprodukovatelné a podepsané.
• Surový disk, bez souborového systému. Specifikace formátu na úrovni bajtů, hostitelský nástroj urmqtt-disk, který sdílí parsery s jádrem, zarovnání oblastí na 1 MiB, růst disku s daty, discard pro tence alokované disky, snímky databáze A/B, kontrola bitů a volitelně šifrování AES-256-XTS s hardwarovým AES.
• Prokazatelně bezpečné. Odvolání a seznam povolených zařízení za běhu přes podepsaný řídicí kanál, bez nového obrazu; diferenciální a konformační testování vlastního TLS a TCP; KASLR, ochrana zásobníku, kCFI, MTE a zpevněný alokátor; SQLite izolovaný na úrovni EL0; Secure Boot; SBOM a cargo-vet; a nakonec balíček pro externí audit.

Platformy, které nabízejí jen zařízení jiná než virtio, jako AWS ENA nebo Azure MANA, zatím nejsou podporovány. Raspberry Pi 4 a 5 jako hostitel KVM, Hetzner CAX a Oracle Ampere A1 jsou zdokumentovány a podporovány kódem, ale zatím nebyly vyzkoušeny na skutečné službě.

Vyzkoušejte

Repozitář je na github.com/zeljan-alduk/urMQTT. S Rustem s připnutým nightly toolchainem a QEMU stačí make certs, make run a jeden klient mosquitto k prvnímu PUBLISH přes mTLS na vlastním počítači. Upozornění ze začátku platí i na konci: je to pre-alfa a vše, co funguje, je napsáno v docs/PROGRESS.md. Hlášení chyb, otázky k návrhu a bezpečnostní hlášení podle pokynů v SECURITY.md jsou vítány. O každém dalším milníku se zde ozveme.

Na tomto blogu si zapisujeme, co jsme se cestou naučili. Ne marketingové texty, ale konkrétní poznámky: co se pokazilo, jak jsme to vyřešili a co bychom dnes udělali jinak.

O čem budeme psát

• Odbavení cestujících ve veřejné dopravě. Bezkontaktní karty, moduly SAM, práce bez sítě a všechno, co musí terminál vydržet ve vozidle, které se dvanáct hodin denně třese.
• Mobilní aplikace v terénu. Android a Flutter na zařízeních, která nejsou obyčejné telefony: se čtečkami karet, tiskárnami a bateriemi, které musí vydržet celou směnu.
• Backend a dohled nad flotilou. Jak poznat, že zařízení ve vozidle má problém, dřív než ho nahlásí řidič.
• Hardware. Od prototypu na stole po desku, která jde do sériové výroby, a všechny chyby mezi tím.
• Lokální modely AI. Kde dávají smysl modely na vlastním hardwaru a kde jsou cloud a API prostě lepší volba.

Jak budeme psát

Krátce a konkrétně, s kódem a čísly tam, kde je máme. Publikovat budeme, když budeme mít co říct, ne podle rozvrhu. Příspěvky píšeme chorvatsky a překládáme je do všech jazyků tohoto webu; sledovat nás můžete i přes RSS.

Pokud vás zajímá nějaké téma nebo řešíte podobný problém, napište nám na info@aldo.tech.