Az előzetes megjegyzés ugyanaz marad: a projekt pre-alfa, az első kiadás csak KVM-et használó VPS-ekre szól, a számok pedig a kódot, a teszteket és bizonyos kísérleteket mérik, nem az éles üzemi érettséget.

Hogyan nézett ki ez az időben

Az előző írás (10.31., 23:00) óta máig (11.1., 20:41) 59 új commit került a repóba, összesen 178. Mind egyetlen naptári napon készült, ezért ugyanaz a figyelmeztetés érvényes, mint korábban: a projekt Claude Code segítségével épül (a commitok Co-Authored-By: Claude záróelemet viselnek), a terv, a kód, a tesztek és az ADR-ek rövid, zárt ciklusokban készülnek, az alábbi számok pedig a kód és az ellenőrzések mennyiségéről szólnak, nem arról, mennyi emberi munka van bennük.

A számokat ugyanazzal a módszerrel számoltuk, mint az előző írásban: minden .rs fájl a vendor/ és a fuzz/ kívül, a #[test] függvények, a ## ADR- címek a docs/DECISIONS.md fájlban.

Több ágon párhuzamosan dolgoztunk, ezért a commitok sorrendje nem szigorúan a munka sorrendje. Az ADR-ek számozása 232-ig megy, de a számozásban vannak hézagok (egy részüket átnevezték az ágak egyesítésekor); a címeket számoljuk, nem a legnagyobb számot. Kiadások: v0.2.0 (11.1., 18:45 UTC) és v0.2.1 (11.1., 20:22 UTC), mindkettő pre-release-ként megjelölve.

H6: SQLite felhasználói módban

Mit terveztünk. Az SQLite 254 268 sornyi C-kód, amely az adatbázist, a WAL-t és a naplót parseolja a lemezről, a lemezt pedig elő lehet állítani vagy módosítani. Addig a magban futott, a mag jogaival. Mit építettünk (ADR-210–ADR-212): az SQLite, a hozzá tartozó libc-részek és a heap egy külön programba kerültek, a dbworker-be, amely EL0-n (aarch64), illetve ring 3-ban (x86_64) fut, saját címtérben. A mag már nem linkeli az SQLite-ot. A worker egy közös memóriaablakon és tizenkét rendszerhíváson át beszél a maggal, és minden visszaadott hosszt és eltolást használat előtt ellenőrzünk. A workerben fellépő hiba (tiltott hozzáférés, nem definiált utasítás, a 30 s-os időkeret túllépése) lezárja a hívást, a worker újraindul, az adatbázis pedig a WAL-ból nyílik meg, mint induláskor; percenként 5 újraindítás után a tároló hibásnak minősül, és nem indul újra a végtelenségig.

Az ár, aarch64-en, HVF alatt mérve, ugyanaz a VM, a beépített SQLite-os mag a workeres maggal szemben, mindkettőből hat váltakozó futtatás:

A lemezírások (1572) és a flushek (319) azonosak, ahogyan kell. Ez nincs szigetelve: a mag továbbra is hisz annak, amit a worker visszaad, az alak ellenőrzése után. Egy kompromittált worker hazudhat (például üres visszavont tanúsítványlistát adhat vissza, és ezzel „visszavonja a visszavonást"), de nem olvashatja a mag memóriáját, a TLS-kulcsokat és a jegykulcsokat. KPTI nincs, ezért a Spectre/Meltdown-típusú szivárgások nincsenek megakadályozva, és semmit nem állítunk róluk; a PAC-kulcson az EL0 és az EL1 osztozik. x86_64-en az átváltás árát KVM-en nem mértük meg (TCG alatt a szám értelmetlen lenne), magának a workernek és a protokollnak a fuzzolása pedig nincs kész. A tárolási tesztcsoport (79 forgatókönyv, mindegyik az SQLite-ot forgatja a workerben) átmegy aarch64 HVF-en és x86_64 TCG-n, aarch64 TCG-n 76 megy át (egyet kihagy, mert a TCG-nek nincs MSI-X-e).

A H7 lezárult, de nem úgy, ahogy bejelentettük. Az időalsó korlát (ADR-050) és a konszenzusos SNTP (T1) lefedi a H7 hatókörét; az NTS (RFC 8915) a hatókörön kívül marad, és megmaradó kockázatként van feljegyezve, nem működő dologként. Nem azt gondoljuk, hogy az idő biztonsága „megoldott", hanem azt, hogy a bizonyítható része kész.

Új hálózati opció. A Contabo nem ad DHCP-t egyéni ISO-nak, ezért a VPS-hez addig más képfájl kellett, mint a laboratóriumi VM-hez. Mostantól a network.mode = "auto" (ADR-214) először a DHCP-t kérdezi, és ha a címbérlet nem érkezik meg a megadott időn belül (dhcp_timeout_s, alapértelmezés 15 s), vagy elvész, az alapértelmezett statikus címet alkalmazza. Kézzel kipróbálva QEMU-n (DHCP-vel a bérletet használja, hálózat nélkül 5 s után visszaáll a statikus címre); füstteszt-forgatókönyv ehhez még nincs.

X11: összevetés a Mosquittóval ugyanazon a VPS-en

Ugyanolyan gép, mint az előző írásban (Contabo, 4 vCPU AMD EPYC, 8 GiB), a terhelés egy Linux gazdagépről érkezik 15 ms távolságból, kölcsönös TLS 1.3 mindkét oldalon ugyanazokkal a tanúsítványokkal, Mosquitto 2.0.21 Debian 13-on, tartósság nélkül. A módszer és a döntések az ADR-213-ban vannak, a nyers adatok a docs/perf-results/ könyvtárban. Három futtatás mediánja.

Mit jelent ez, és mit nem. A kézfogások mindkét szerverre alsó korlátok: a terheléskeltő egy megosztott VM volt 60–70% ellopott processzoridővel, és 128 szálnál közel volt a saját korlátjához, az urMQTT munkamagjai pedig csak 12–13%-ban voltak foglaltak. A 128 kliensnél mért arány (körülbelül 2,2-szeres) a legértelmezhetőbb; 32-nél és 64-nél többnyire a kliensek várakozását méri. A memóriaszámok nem ugyanazt számolják (magheap szemben a folyamat RSS-ével), ezért a „körülbelül 50-szer kevesebb" nagyságrend, nem pontos arány. A 14 ms-os késleltetés egyetlen hálózati kör (körülbelül 15 ms), tehát „nincs mérhető brókeridő"; a farkakat (p99 körülbelül 100–200 ms) mindkét bróker esetében a megosztott gazdagépek uralják. A körülbelül 20% alatti különbségeket nem állítjuk.

Ami nem nekünk kedvezett, és benne maradt a táblázatokban: egyetlen TCP-adatfolyam az urMQTT-n át 2–8-szor kevesebbet vitt, mint a Mosquittón át, a futtatások között nullától 7,7 ezer üzenet/másodpercig terjedő ingadozással, a kezelő 20 ms-os watchdogja pedig megszakította az élő kapcsolatokat, amikor a hipervizor leállította a vCPU-t (éles beállításban action = "drop", futtatásonként 6–8 kapcsolat QoS 0 elárasztásnál). Mindkettőt a következő szakasz írja le, mert az okaik a mi kódunkban voltak.

Miért volt lassú az egy adatfolyam: okok, nem kifogások

A legkönnyebb az lett volna, hogy „megosztott VPS". Nem ezt tettük, hanem ugyanazon a VPS-en, ugyanazzal a módszerrel okokat kerestünk. Öt okot találtunk, négyet az adatúton és egyet a watchdogban (ADR-221–ADR-224):

A leállások valódiak: ezen a VPS-en a 0–2. magoknak 5 másodpercenként medián 36–80 késett ütésük volt, az ablak legrosszabb leállása pedig medián körülbelül 70 ms, legfeljebb 0,9 s (3. mag, adatbázis és napló: legfeljebb 1,55 s), miközben a gazdagép nem jelent ellopott időt (host steal 0 us). Ezért a watchdognak második órára volt szüksége, nem nagyobb időkeretre.

Watchdog: 148 megszakadt kapcsolat 30 terhelt futtatásban előtte, 0 a 24 futtatásban utána; egy helyi eszközön, amely késlelteti és veszíti a kereteket, 0,1% veszteségnél egy 64 B-os adatfolyam, amely 14,3k üzenet/s-ot adott (az X11 magja), most 41,0k-t ad, 0,5%-nál pedig 5,0k helyett 17,7k-t.

Amit ez nem mond. Az urMQTT továbbra sem gyorsabb a Mosquittónál egy adatfolyamon: 64 B-nál a sebességének körülbelül 80%-át közli, és körülbelül 40%-át kézbesíti, mert eldobja a QoS 0-t, ha a feliratkozó adatfolyama lassabb a kiadóénál (a Mosquitto korlát nélkül sorba állítja). 1 KiB-nál a 16 páros elárasztásban a Mosquitto körülbelül 15%-kal előrébb van, ami a zajon belül van. A terheléskeltő ismét megosztott VM volt 58–77% ellopott idővel. A második kör (a heap zárolása az adatúton kívülre, SACK a küldési oldalon és más) a be nem épített perf-single-flow-wip ágon van; a számai még nem állítások, és itt nem közöljük őket.

Ígéret, amelyet nem tettünk, de teljesítettünk: a konfiguráció adat

Eddig minden konfiguráció új build volt: a kulcsok és a korlátok bele voltak építve a képfájlba. A C1 ezt megfordítja (ADR-215–ADR-219): a magot egyszer építjük, a konfiguráció pedig adat.

• Az urmqtt-cfg blob (C1a): verziózott, kanonikus írásmód (a mezők növekvő címkék szerint, SHA-256 ujjlenyomat, opcionális különálló Ed25519 aláírás), 70 mező alapértékekkel és korlátokkal, és egy dekóder, amely minden hibásat visszautasít.
• A mag Limine-modulként olvassa (C1b), bármi más előtt, aarch64-en és x86_64-en. Minden ENV-hez, a dev kivételével, egyetlen kiadott mag van (a release, prod és bench aarch64 ELF-jeinek azonos a SHA-256-ja; csak aarch64-en ellenőrizve). A kiadott mag visszautasítja a fejlesztői konfigurációt, konfiguráció nélkül pedig „refusing to serve" üzenetet ír, és semmit nem szolgál ki.
• A telepített lemez hordozza a konfigurációt, és a frissítés megtartja (C1c).
• Az urmqtt-config és az ISO-sablon (C1d): pack, show, verify, a pack --iso pedig a konfigurációs hely mindkét példányát és a 24 modulösszegzést cseréli a kész ISO-ban. Az eredmény bájtról bájtra azonos azzal az ISO-val, amelyet a mkiso.sh --config épít. A v0.2.0 kiadás sablonja 63 111 168 bájt.
• Bizalmi nyilatkozat (ADR-219): a konfigurált képfájl induláskor kiírja a konfiguráció ujjlenyomatát (config: fingerprint ...), az aláírás pedig opcionális és alapértelmezés szerint ki van kapcsolva. A módosított ISO-nak nincs hivatalos összegzése; az ujjlenyomat az eszköz arra, hogy lássuk, mi van benne.

Az építő az aldo.tech-en

Ugyanazt, amit az urmqtt-config pack --iso csinál, a weboldal is csinálja, ugyanazzal a kóddal: az eszközkönyvtár WebAssemblyre fordítva (1,06 MB, importok nélkül és unsafe blokk nélkül). Az oldal a aldo.tech/hu/termekek/urmqtt-builder/ címen érhető el, és az oldal mind a 15 nyelvén létezik (például hr).

• Semmi nem hagyja el a böngészőt. A tanúsítványok, a privát kulcsok és a kész ISO a számítógépen maradnak; az oldal csak a kiadási fájlokat tölti le erről a helyről, nincs követés, és nincs harmadik fél szkriptje. Az élő tesztben egyetlen kérés sem vitt kulcsanyagot.
• Kiadási tükör (ADR-227): óránként (systemd timer, alacsony prioritású) átmásolja a kiadásokat a GitHubról, mindegyiket közzététel előtt ellenőrzi, az oldal pedig a böngészőben az oldalba beépített kulccsal ellenőrzi a SHA256SUMS aláírását, és csak azután írja a konfigurációt a sablonba. A sikertelen ellenőrzés blokkolja a letöltést.
• Alapértelmezésben egyszerű, szükség esetén haladó (ADR-232): az első képernyő három lépés (hol fut, az Ön tanúsítványai, a képfájl neve). Egyetlen húzásos mező a tartalma alapján szétválogatja a tanúsítványt, a kulcsot és a CA-t. A haladó nézet megnyitja mind a 70 mezőt, keresést, valamint a TOML importját és exportját; mindkét nézet ugyanazt az állapotot szerkeszti. A sablon (63 MB) letöltődik, amíg a felhasználó tölti az űrlapot. Az élő próbában, próbatükörrel és próbakulccsal az ISO böngészőbeli felépítése 5–18 s-ig tartott.

Az emulátor, opcionálisan. A „ISO letöltése" mellett ott áll az „Kipróbálás emulátorban": a WebAssemblyre fordított QEMU a frissen épített képfájlt futtatja egy böngészőlapon. A kattintás előtt semmi nem töltődik le belőle (először körülbelül 3 MB). Az emulátor csak BIOS-os, hálózat nélküli (hogy a felhasználó forgalma ne haladjon át valamilyen közvetítőn, és ne sértse a „semmi nem hagyja el a böngészőt" elvet), körülbelül 1,5 GB memóriát kér, és asztali böngészőt igényel (Chrome-mal tesztelve; Firefoxszal és Safarival nem). Benne az urMQTT körülbelül 8 s alatt eljut a URMQTT READY üzenetig (a visszaszámlálás átugrásával), és ugyanazt a konfigurációs ujjlenyomatot írja ki, mint az oldal, ami bizonyíték arra, hogy éppen ez a konfiguráció indult el. Az indulás körülbelül 2-szer lassabb, mint az eredeti QEMU ugyanazon a Macen (0,82 s szemben 1,9 s-mal), a kriptográfia pedig körülbelül 58-szor lassabb, mert a hardveres utasítások emuláltak. Ezért az emulátorból semmilyen sebességre vonatkozó állítást nem vonunk le, az oldal pedig ezt a futtatás előtt kimondja. A build során négy bájtot kellett foltozni a .wasm-ban az eredeti emulátorban a POPCNT utasítás fordításában lévő hiba miatt (még nem jelentettük be); maga az emulátor GPL alatt áll, a forráskód felkínálásával.

Sima MQTT, csak olyan hálózatokra, amelyekben megbízunk

A sima MQTT (TCP 1883, TLS nélkül) nagyon gyakori az IoT-ban: alapértelmezett a Mosquittóban, az Arduino és ESP legtöbb firmware-ében, a Tasmotában, a Zigbee2MQTT-ben és a Home Assistantben, használják szegmentált ipari hálózatokban, VPN mögött és privát LAN-okon, sőt olyan eszközökön is, amelyeknek nincs órájuk (a tanúsítványokhoz dátum kell), vagy nincs elég flashük vagy processzoruk a TLS-hez. Megbízhatatlan hálózaton nem elfogadható: aki az úton van, olvassa és módosítja a forgalmat. Ezért a P1 (ADR-229–ADR-231) kifejezett, korlátozott választás, alapértelmezés szerint kikapcsolva, a TLS port pedig megmarad; ezzel a TLS nem kapcsol ki, a sima port mellette érkezik.

• A megengedett hálózatok listája kötelező (allow_from, CIDR-ek), és SYN-nél ellenőrzik: a listán kívül nincs SYN-ACK és nincs állapot. A teljes internethez (0.0.0.0/0) külön, kifejezett opció kell.
• Három bejelentkezési mód: jelszó (alapértelmezett, ha be van kapcsolva; PBKDF2-HMAC-SHA-256, só, 10 000 iteráció, állandó idejű összehasonlítás, zárolás cím szerint), anonim (egy beállított identitás saját ACL-lel) és cím szerint (ip). Az építő a jelszót a böngészőben hasheli, és a memóriában csak az összegzést tartja.
• Kevesebb jog, mint az mTLS-nél: a sima kliensnek soha nincs szolgáltatási, üzemeltetői és vezérlési joga, nincs $SYS-e és konzolja, saját munkamenetei vannak ($plain/<identitás>/<kliens azonosítója>, csak tiszták), és a saját korlátok és az engedélyezettek jegyzéke továbbra is kötelezi.
• Amit elveszítünk, a SECURITY.md-ben áll: a bizalmasság, az integritás, a bróker hitelessége és a rögzített bejelentkezés újrajátszása. Ezt konfigurációval nem lehet kijavítani; ilyen, ha nincs TLS.

Laptopon mérve (Apple silicon, HVF, QEMU felhasználói hálózat), 16 pár, 64 B, három 10 s-os futtatás: 8000 üzenet/s mellett a TLS-es és a sima út minden üzenetet azonos késleltetéssel kézbesít (p50 0,17 ms szemben 0,13–0,18 ms-mal), új kapcsolatok másodpercenként: TLS körülbelül 2600–2750, anonim sima körülbelül 4900–7800, a jelszavas bejelentkezés pedig a drága rész: egy PBKDF2 körülbelül 2,5 ms-ba kerül, ezért az új bejelentkezések száma körülbelül 200-ra korlátozódik adatmagonként másodpercenként (két magon 308–342-t mértünk). Az elárasztás azon a gépen nem stabil műszer (20k–440k kézbesített másodpercenként a futtatások között), és belőle nem vonunk le következtetést. A sima út összevetése a Mosquittóval VPS-en még nem készült el. Tesztek: a plaintext füstteszt-csoport 7 a 7-ből aarch64 HVF-en és x86_64 TCG-n, új fuzz-cél a plain_input (2,3 millió futtatás lelet nélkül).

Hibák, amelyeket az élő üzem talált

Két dolgot nem a tesztek fogtak meg, hanem az első bekapcsolás a valódi helyen:

• Az oldal a kiadási fájlokat egy könyvtárral feljebb kereste, ezért minden aláírás-ellenőrzés 404-et adott (javítás: 13af301). A teszt egy másik útvonalon lévő próbatükröt használt.
• Az emulátor billentyűzete soha nem jutott el a vendégig: az ok nem a billentyűk rossz fordítása volt, hanem az, hogy a párbeszédablak egyáltalán nem figyelte a billentyűket (javítás az ADR-232-ben, billentyűk nélküli indítási bejegyzéssel).

Tanulságok

• Az okot keressük, ne a környezetet hibáztassuk. Az egy adatfolyam gyengeségeinek többsége és az összes megszakadt kapcsolat a miénk volt; a hipervizor valódi, de mérni kellett, nem feltételezni.
• Egy másik termékkel való összevetésnek a veszteségeket is tartalmaznia kell. Egy táblázat, amelyben csak a mi győzelmeink szerepelnek, nem lenne összevetés.
• A mérőműszernek vannak határai. Egy megosztott terheléskeltő 60–70% ellopott idővel megváltoztatja, mit jelentenek a számok; ezért írunk „alsó korlátot", és nem állítunk 20% alatti különbségeket.
• A szigetelés nem bizonyíték. Az SQLite EL0-n azt csökkenti, mit tehet egy hiba benne, nem azt, miről hazudhat.
• A valódi telepítés megtalálja azt, amit a tesztek nem kérdeznek: a rosszul összerakott útvonalat és a billentyűket, amelyeket senki nem figyel.

Ami még nincs bizonyítva

• A kiadás aláírókulcsa egyelőre próbakulcs; a v0.2.0 és a v0.2.1 pre-release, a hozzájuk tartozó képfájlok pedig fejlesztői képfájlok próbatanúsítványokkal (a sablon kivételével, amely konfiguráció nélküli).
• Az építőoldal 13 fordítását (és ezét az írásét) AI írta, és tesztek meg mintavételek ellenőrizték, nem anyanyelvi beszélők.
• A Mosquittóval való összevetés egy ülés, egy út és egy megosztott terheléskeltő, megosztott VPS-en; a 20% alatti különbségek nem állítások.
• A sima utat nem mértük VPS-en, és nem a Mosquitto ellen.
• A Lighthouse az új egyszerű nézeten nincs megerősítve (a régi nézet: akadálymentesség 95 vagy több).
• Bare metal, a worker x86_64-es ára KVM-en, Firefox és Safari az emulátorhoz: nincs mérve.

Mi következik

• D1: nyilvános demo bróker. A böngészős emulátort nem tehetjük nyilvánossá: egyetlen látogató lapján él, 20–100-szor lassabb a KVM-nél, nincs bejövő hálózata, és a lap bezárásával eltűnik; az internet átirányítása valaki más böngészőjébe ráadásul visszaélés lenne. Lehetséges egy valódi demo bróker: az urMQTT egy VPS-en, az aldo.tech egyik neve mögött, közzétett próba-CA-val, szigorú ACL-lel és kis korlátokkal. Ez egyelőre csak ötlet, nem építés, és kifejezett hozzájárulás kell a nyilvános kitételhez.
• A második kör az egy adatfolyamhoz (perf-single-flow-wip ág): csak akkor, ha VPS-en megmértük és beépítettük.
• A sima út a Mosquitto ellen VPS-en, a sima MQTT-hez a fiókok bejelentkezése és visszavonása aláírt vezérlőcsatornán át.
• A kiadás után: bare metal (X12–X16), IOMMU és Secure Boot, lemeztitkosítás.

A kód a github.com/zeljan-alduk/urMQTT címen van, a docs/PROGRESS.md pedig továbbra is az egyetlen igazságforrás arról, mi működik valóban, a docs/PERFORMANCE.md arról, mit mértünk. Pre-alfa, mint korábban; a hibabejelentéseket és a biztonsági bejelentéseket a SECURITY.md útmutatása szerint szívesen fogadjuk.

Egy megjegyzés előre: a projekt továbbra is pre-alfa. Az írásban szereplő számok a kódot és a teszteket mérik, nem az éles üzemi érettséget, az első kiadás pedig szándékosan csak a KVM-et használó VPS-ekre korlátozódik. A bare metal későbbre marad.

Hogyan nézett ki ez az időben

Az első commit 2026. október 28-án 23:48-kor született (M0). Október 31-ig 23:00-ig a repóban 119 commit van, naptári napok szerint 3, 39, 38 és 39 eloszlásban. Rögtön el is mondjuk, hogyan lehetséges ez: a projekt Claude Code segítségével épül, a commitok pedig Co-Authored-By: Claude záróelemet viselnek. A négy naptári nap története nem azt jelenti, hogy egy ember négy nap alatt 90 000 sort írt meg; azt jelenti, hogy a tervezés, a megvalósítás, a tesztek és az ADR-ek rövid, zárt ciklusokban készülnek, és minden lépés ugyanazzal az ellenőrzési rituáléval zárul, mint korábban. Az alábbi számok a kód és a tesztek mennyiségét mutatják, nem azt, mennyi tényleges munka állt mögöttük.

A grafikon három görbét mutat, amelyek szinte együtt emelkednek, és ez a szándék: a tesztek és a leírt döntések követik a kódot, nem maradnak le mögötte. A meredekség október 29-én a legnagyobb, amikor elkészül az egész út a kerneltől a brókerig. Később a sorok lassabban szaporodnak, a tesztek viszont gyorsabban nőnek, mint a kód (27 teszt 1,6 ezer sorra az elején, 739 teszt 89,8 ezer sorra ma).

A sorok a vendor/ és a fuzz/ mappán kívüli összes .rs fájl, a tesztek pedig a #[test] függvények. Hogy melyik rész mit adott hozzá, a git-előzmények dátumai szerint:

1. ígéret: egyetlen ISO több platformra

Mit terveztünk. Egyetlen fájl, amely elindul aarch64 UEFI-n, x86_64 UEFI-n és x86_64 BIOS-on. Mit építettünk. Az x86_64 portot (X0–X10) és a Limine bootloaderes univerzális ISO-t: egyetlen hibrid ISO, amelyről mindezek a kombinációk elindulnak; a füsttesztek négy virtuális gépen indítják el. A menünek három tétele van: urMQTT (élő mód, a RAM-ból fut, semmit nem ír a lemezre), telepítés annak a gépnek a lemezére, amelyen elindították (a telepítő GPT-t és adatokat ír, majd leállítja a gépet), és Diagnosztika (hardverfelismerés és mérések).

Az első valódi cél egy VPS volt, nem fizikai számítógép: a döntés az, hogy az első kiadás csak VPS-t (KVM) támogat, a bare metal pedig utána jön. Contabo VPS-en teszteltünk, AMD EPYC processzorral (23-as család, Zen 1), 4 vCPU-val és 8 GiB RAM-mal, virtio-net hálózattal és virtio-scsi lemezzel. Az első kísérlet meglepett bennünket: a virtuális CD-ként csatlakoztatott ISO az alapértelmezett tételt indította el, az éles kép pedig nem volt hajlandó írásvédett adathordozóról működni, és újraindult, így végtelen ciklust kaptunk menü, kernel, újraindítás között, bármiféle olvasható üzenet nélkül. Ma egy végzetes hiba az éles képben 60 másodpercig kint hagyja az üzenetet a konzolon az újraindítás előtt, optikai adathordozóról pedig kiírja, hogy írásvédett adathordozóról indult el, és megáll. Az élő mód a RAM-ban (O3) később a szokásos esetben megkerülte ezt a problémát.

A diagnosztikai tétel ebből a tapasztalatból született: egy olyan gépet, amelyet nem látunk, meg kell tudnunk kérdezni, mije van. Kiírja a CPU-t, a RAM-ot, a hálózatot, a lemezeket és a PCI-eszközöket, megméri a memória áteresztőképességét, a lemezt és a kriptográfiát, ugyanezeket a méréseket pedig JSON-ként a soros portra is kiírja. Lemezre írni csak a le nem foglalt területen szabad, és csak a WIPE begépelése után; az alábbi felvételen ezt kihagytuk.

Mi maradt nyitva. A valódi hardver. Az első kiadás után jön a bare metal (USB-ről indítás, NVMe és AHCI, egy valódi számítógép hálózati kártyája), az IOMMU-val és a Secure Boottal együtt, mert IOMMU nélkül egy rosszindulatú vagy hibás eszköz az egész memóriába írhat. Ebben a verzióban erről semmit nem állítunk.

Kézfogás: 1,2 ms-ról 0,24 ms-ra

A diagnosztika első mérése a VPS-en kellemetlen számot adott: az mTLS-kézfogás, csak a szerveroldali kriptográfia, 1,2 ms-ig tartott. Aarch64-en már használtunk hardveres AES- és SHA-utasításokat, de x86_64-en nem volt semmi hasonló a nyilvános kulcsokhoz: a RustCrypto hordozható és constant-time, ezért lassú is. Három változtatás vitte le.

• A P-256-hoz átvettük az nistz256 assemblert az OpenSSL-ből és a ringből (ADR-130), rögzített bázisú táblákkal az aláíráshoz és a CA aláírásainak ellenőrzéséhez (ADR-110, ADR-111).
• Az X25519-et négy 64 bites végtagra írtuk át MULX/ADX utasításokkal (ADR-131).
• Ezután a maradékot is profiloztuk (ADR-132, ADR-200).

A számok futásonként nagyjából 10%-kal különböznek, ezért egyetlen érték helyett tartományt rögzítettünk. Összességében ez nagyjából ötször kevesebb CPU-idő egy kézfogásra.

Amit a memcpy-ról tanultunk. Miután a kriptográfia lecsökkent, a profil olyat mutatott, amire nem számítottunk: a mem* függvények (memcpy, memmove, memset) a kézfogás 7%-át, a TLS-rekordút 13–39%-át (39% 64 B-nál, 13% 4 KiB-nál) és a PUBLISH szétosztásának 17–34%-át emésztették fel. Lecseréltük őket SSE2 assemblerre x86_64-en (ADR-200), a referencia-implementációval szembeni differenciális tesztekkel minden méretre, igazításra és átfedésre. Hívásonként ez 55–75 ciklus a 7–12 helyett 1–64 bájtnál.

A grafikon olvasata: minél kisebb a rekord, annál nagyobb része megy a másolásra, így annál nagyobb a nyereség is. A kis üzeneteknél, amelyek az MQTT-forgalom nagy részét teszik ki, ez a lényeg.

Amit ez nem jelent. Natív x86_64-en az OpenSSL 3.5.5-öt csak az assembler referenciájaként mértük (ADR-130), nem termékösszehasonlításként. A Linux plusz Mosquitto összehasonlítást ugyanazon a VPS-en (X11 feladat) még nem végeztük el. Ezért nem állítjuk, hogy az urMQTT gyorsabb a Linuxnál: nincs megmérve. A fenti számok az urMQTT-t önmagával hasonlítják össze.

A túlterhelés volt a második eredmény. A VPS-en, egyetlen Macről (RTT 35 ms) 128 kliens 618 kézfogást adott másodpercenként, 256 kliens 393-at, 512 kliens pedig 67-et, ezernyi elutasított kapcsolat mellett. Ez nem plató volt, hanem összeomlás. Az okokat a kódban találtuk meg (kettőt QEMU-ban/HVF-en megerősítettünk, a VPS-en nem sikerült reprodukálni), egyszerre többet is: egy elutasított kapcsolat visszaengedte a klienst a következő olyan szegmensen át, amely érvényes SYN-sütit hordoz, az elutasítás RST-vel azt mondta a kliensnek, hogy azonnal próbálkozzon újra, a vétel pedig O(sor) volt. A javítás (ADR-080–ADR-082) eldobja azt a SYN-t, amelyet nem fogadnának el, megjegyzi az elutasított folyamokat, a vételt O(1)-ben tartja, és magonként számolja a kézfogásokat. Lehetséges (hipotézis, nincs ellenőrizve), hogy az ok egy része a kliensoldalon volt: a terhelésgenerátor zárta le elsőként a kapcsolatot, így egyetlen Mac 16 384 efemer porttal és 30 másodperces TIME_WAIT mellett nagyjából 550 kapcsolat/másodpercre korlátozódott. Ezért a szerver valódi határát még nem mértük meg.

2. ígéret: nyers lemez, de körültekintően

Mit terveztünk. Megtartani a saját, fájlrendszer nélküli elrendezést, és hozzáadni mindazt, amit egy fájlrendszer egyébként ad: igazítást, növekedést, discardot, biztonsági másolatokat és ellenőrzéseket. Miért nem fájlrendszer. Ezt megvitattuk, és a döntést megerősítettük: az urMQTT egy adatbázist, egy telemetriai naplót és saját metaadatokat ír, nincs szüksége könyvtárakra, jogosultságokra és fájlnevekre, minden további réteg pedig még több kód lenne a megbízható részben, és még egy mód arra, hogy egy írás csendben eltűnjön. A lemez GPT egy ESP partícióval és egyetlen urMQTT-adatpartícióval, amelyen a saját elrendezés van.

Mit építettünk (S2–S6).

• Elrendezés v2 (S2). Lemeztopológia, igazítás 1 MiB-ra vagy az optimális I/O-méretre, egész fizikai blokkok, A/B szuperblokkpár generációval (ADR-140). A v1 elrendezést a kernel érthető üzenettel elutasítja, a migrálást pedig az urmqtt-disk migrate offline eszköz végzi (ADR-141): alapértelmezés szerint próbafutás, először másol, csak utána vált át, visszaállítással és hibainjektálással minden írásnál.
• Növekedés (S3). Induláskor a lemez megnőhet (soha nem csökken), virtio-blk-n pedig üzem közben is, a konfigurációváltozási megszakításon keresztül (ADR-142, ADR-143).
• Discard és write-zeroes (S4). A vékonyan kiosztott lemezek visszaadják a helyet a gazdagépnek. Egy tesztben a gazdagépen lévő qcow2 fájl 62-ről 16 MiB-ra esett vissza, miután a telemetriai szegmensek lejártak, a helyreállítás pedig soha nem bízik az eldobott tartalomban.
• Az adatbázis biztonsági mentése a lemezen (S5). A/B másolat az SQLite online backup API-jával 16 oldalas lépésekben: a leghosszabb lépés 4,6 ms, szemben a 445 ms-mal, ha egy hívásban másolunk. A másolás alatti commitok maximuma 2,4 ms volt, a nélküle mért 2,2 ms ellenében. Ha a quick_check induláskor hibázik, az adatbázis a másolatból áll vissza.
• Tisztítás és korlátozott indulás (S6). A scrubber korlátozott I/O-költségvetéssel olvassa a lemezt, és jelzi a sérült rekordokat, az indulás pedig minden partíció csak a legújabb szegmensét olvassa, így az indulási idő nem nő a telemetriai régió méretével. Ezzel lezártuk a problémát, amelyet előre kiszámoltunk: nagy lemezen a teljes helyreállítás percektől több tíz percig tartott volna.

A tárolás füsttesztjeinek teljes csoportja mindkét architektúrán átmegy: 79 sikeres, 0 sikertelen, aarch64-en HVF alatt és x86_64-en TCG alatt. Azt is megmértük, hogy az S4 nem lassította az adatbázist: 53,3 ezer beszúrás másodpercenként kötegekben előtte és utána is, mérhető különbség nélkül.

Mi lepett meg. Mennyi múlik a „egyszerű" elrendezésben a szélső eseteken: a virtio-scsi és a virtio-blk különböző módon jelenti a topológiát, a migráció közepén megszakadt írásnak pedig mindig hagynia kell legalább egy érvényes változatot. Ezért a migráció és a növekedés útján minden írás átment hibainjektáláson.

Mi maradt nyitva. Az SQLite-oldalaknak nincs ellenőrző összegük, így egy sor értékén belül megváltozott bitet az adatbázis nem vesz észre; a telemetriai rekordoknak és a másolatok tartalmának van CRC-je, ezért ezeket észleljük. A lemeztitkosítás (S7) nincs kész.

3. ígéret: bizonyíthatóan biztonságos, amennyire csak sikerül

Megerősítés (H4). Az allokátor törli a felszabadított memóriát és újrahasználatkor ellenőrzi, felismeri a dupla felszabadítást, a szabadlista mutatóit XOR-ral köti, a kulcsokat pedig felszabadításkor nullázza (ADR-170). Veremvédelem (-Zstack-protector=strong, 1315 függvény, az SQLite pedig -fstack-protector-strong mellett, ADR-171). Az éles hibajelentések nem tartalmaznak regisztereket és címeket (ADR-172). KASLR mindkét architektúrán: a kernel PIE, és a Limine nagyjából 19 bittel tolja el, a heap, a vermek és az MMIO-ablak pedig véletlenszerűen helyezkedik el (ADR-173). Aarch64-en az MTE jelöli a heapet (ADR-174), de csak TCG alatt: a HVF és az x86 nem rendelkezik vele. A kCFI-t megvizsgáltuk, de nem fogadtuk el, mert a fordító a rögzített nightlyn belső hibával összeomlik; az IOMMU-t a bare metallal együtt elhalasztottuk (ADR-175, ADR-176).

Az ár megmérve, nem feltételezve. A kézfogás útján (dp-bench, aarch64 HVF, teljes TLS 1.3 + mTLS + CONNECT kézfogások):

Összességében tehát az ár a kézfogás útján nagyjából 5% a tisztán mért részekre, PIE-vel és címkékkel pedig körülbelül 7% egy és körülbelül 11% négy magon, de ez a mérés zajos. Elfogadhatónak tartjuk, de x86_64 VPS-en nem ismételtük meg.

Érdemes összevetni az első írás számával (862 kézfogás másodpercenként egy magon). Ugyanez az eszköz ma, az aarch64 hardveres titkosításának meghajtójával (X0b) és az azóta érkezett gyorsítások sorával, 1941-et ad a megerősítés előtt. Az egyes változtatások hozzájárulását nem különítettük el, ezért az okról semmit nem állítunk.

Hogyan ellenőriztük, és mit nem. A H5 hozzáadta a Mirit a host crate-ek egy részhalmazára, a Kani-bizonyításokat, a sanitizereket, az ACL modell-fuzzerét és a lefedettségi jelentéseket. A Kani bebizonyította a record_len függvényt a TLS-ben, a parse függvényt a TCP-ben és az időzítőkerék két aritmetikáját. Nincs bebizonyítva (időtúllépés): mindkét MQTT-dekóder, mindkét konfigurációelemzés és az időzítőkerék viselkedése; a Kani CI-feladata ezért még nem blokkol. A Miri nem tud assemblert futtatni. Ellátási lánc (H9): CycloneDX SBOM 215 összetevővel, a cargo-vet átmegy 39 teljesen átvizsgált és 140 kivétel mellett, a cargo-deny pedig úgy van beállítva, hogy a sérülékenységi tanácsokat CI-hibaként kezelje (ezeket a CI-feladatokat eddig csak helyben ellenőriztük, GitHubon nem, a negatív tesztet pedig nem futtattuk le), a VULNERABILITY-HANDLING.md mellett. Az őszinte állapot: a 67 kernelbe linkelt harmadik fél crate-verzióból 53 kivétel, nem átvizsgálás. A vet azt bizonyítja, hogy a függőségek halmaza nem változhat látható különbség nélkül, nem azt, hogy a TCB át van vizsgálva. Egyetlen crate-ről sem írtunk saját átvizsgálást.

Az SNTP (T1) ebben az értelemben egy kis biztonsági történet: opcionális, csak privát IPv4-szerverek felé, maximális ugrással és azzal a feltétellel, hogy a források egyetértenek (medián, többség egy másodpercen belül). Az az óra, amelyet bárki elmozdíthat az úton, nem olyan óra, amelyben megbízhatnánk a tanúsítványok érvényességének ellenőrzésénél.

Macen: aarch64 natívan és x86_64 emulációval

Macen fejlesztünk, és ennek két módja van ugyanannak a kódnak a futtatására, amelyek nagyon különböznek.

A szabály egyszerű: a TCG alatti számok emulációt mérnek, és nem idézzük őket teljesítményként. Az x86 teljesítményét csak valódi VPS-en mérjük. Ezért a fenti kriptográfiai számok a Contabo VPS-ről származnak, nem a Macről.

Tanulságok

• Mérjen valódi gépen, mielőtt optimalizál. Az első megközelítés az volt, hogy azt optimalizáltuk, amiről azt hittük, hogy lassú; csak a VPS-en futó diagnosztika mutatta meg az 1,2 ms-ot és azt, hogy pontosan hová megy az idő.
• A túlterhelés külön tulajdonság. Az a rendszer, amely terhelés alatt gyors, felette összeomolhat; az elutasításnak olcsóbbnak kell lennie az elfogadásnál.
• A profil meglep. A kis üzenetek legnagyobb egyedi nyeresége nem a kriptográfiában volt, hanem a memóriamásolásban.
• A fájlrendszer nélküli lemez több munkát kér, nem kevesebbet. Amit a fájlrendszer egyébként ad (igazítás, növekedés, discard, másolatok, ellenőrzések), azt magunknak kell megírnunk és ellenőriznünk, minden lépést hibainjektálással.
• Őszinteség a számokban. A megosztott VPS-en a memóriamérések futások között akár 10-szeresen is ingadoznak, és semmit nem mondanak a kódról, ezért nem közöljük őket. A kriptográfiai számok nagyjából 10%-on belül stabilak.
• A fejlesztés sebessége nem érettség. A tesztek és az ADR-ek a kóddal együtt nőnek, de négy nap nem valódi üzem.

Mi következik

• H6: az SQLite EL0 szinten izolálva, hogy egy adatbázishiba ne nyissa meg a kernelt.
• H7: az időbiztonság maradéka (NTS és az ugrások kezelése); az SNTP csak az első lépés.
• X11: összehasonlítás a Linuxszal és a Mosquittóval ugyanazon a VPS-en, csak ezután van értelme relatív sebességről beszélni.
• Kiadás: az első nyilvános megjelenés VPS-ekre (KVM), aláírt artefaktumokkal és útmutatókkal.
• A kiadás után: bare metal (X12–X16), IOMMU és Secure Boot, valamint lemeztitkosítás.

A kód a github.com/zeljan-alduk/urMQTT címen érhető el, a docs/PROGRESS.md pedig továbbra is az egyetlen igazságforrás arról, hogy mi működik valójában. Pre-alfa, mint korábban; a hibajelentéseket és a biztonsági bejelentéseket a SECURITY.md útmutatása szerint szívesen fogadjuk.

Így született meg az urMQTT: egy unikernel, amely maga az MQTT bróker. A mag, a TCP/IP, a TLS 1.3, az MQTT és egy beágyazott adatbázis egyetlen Rust binárisban, amelyet egyetlen ISO-ról lehet elindítani. Nincsenek folyamatok, nincsenek rendszerhívások, nincs shell. Az első platform, amelyen épül és tesztelődik, az aarch64, ugyanez a kód pedig x86_64 felé is halad, UEFI-n és klasszikus BIOS-on keresztül, valamint valódi hardver felé: a cél egyetlen ISO, amely mindezeken elindul. A projekt nyílt forráskódú, MIT vagy Apache 2.0 licenc alatt, és ebben az írásban szeretnénk rögzíteni, hol tartunk, hogyan épül fel belülről, és mit tanultunk útközben.

Mit jelent pontosan az „unikernel"

Egy hagyományos bróker olyan program, amely egy operációs rendszeren fut. Az urMQTT alatt nincs operációs rendszer: maga indítja el magát az UEFI firmware-en és a Limine bootloaderen keresztül, beállítja a saját laptábláit, programozza a megszakításvezérlőt és az időzítőt, PCIe-n megkeresi a virtio eszközöket, DHCP-vel címet kap, és egyetlen porton hallgatózik. Mindaz, amit egyébként a kernel, az eszközmeghajtók, a hálózati verem és az alkalmazás végezne, itt egyetlen ELF, amely EL1 szinten fut.

Egy tipikus telepítéssel való összehasonlítás önmagáért beszél:

A prioritásaink ebben a sorrendben: biztonság, skálázhatóság, többmagos teljesítmény, kis lábnyom és megváltoztathatatlan telepítés. Ha két cél ütközik, az nyer, amelyik ezen a listán feljebb áll.

Hol tartunk most

A projekt pre-alfa fázisban van, de tizenhét fejlesztési mérföldkő lezárult, M0-tól M17-ig. Az urMQTT ma MQTT 3.1.1-et szolgál ki TLS 1.3-on, kötelező klienstanúsítványokkal, az állapotát pedig SQLite-ban őrzi, nyers lemezen. Röviden, ez az, amit már tud:

• Mag: saját kivételvektorok dekódolt jelentésekkel, saját laptáblák érvényesített W^X-szel, őrlapok, PAC és BTI, ahol a processzor támogatja, GICv3 és GICv2, általános időzítő, SMP legfeljebb 64 maggal.
• Hardverfelismerés DTB-ből vagy ACPI-ból egyetlen platformleírásba, mindkét forrásból azonos eredménnyel.
• Eszközmeghajtók: PCIe ECAM, MSI-X, virtio-net, virtio-blk, virtio-scsi és virtio-rng, valamint hardveres entrópiával kezdeti értékkel ellátott CSPRNG.
• Hálózat: saját DHCPv4, ARP, ICMP és szigorú IPv4, majd saját, csak szerveroldali TCP: SYN-sütik, hierarchikus időzítőkerék, NewReno, ACK-ok összevonása, TIME_WAIT állapotok nélkül.
• TLS: csak TLS 1.3, kötelező mTLS, az eszközazonosító a CN-ből vagy a SAN URI-ból származik; a kézfogást a rustls végzi, utána saját rekordréteg következik AES-128-GCM-mel és ChaCha20-Poly1305-tel. Munkamenet-folytatás PSK-jegyekkel, visszavonási lista, már a kézfogásnál működő befogadás-vezérlés.
• MQTT: másolásmentes kodek, fuzzolva és valódi mosquitto kliensekkel tesztelve; QoS 0 és 1, helyettesítő karakterek, megőrzött üzenetek, végrendelet (LWT), tartós munkamenetek, a devices/{id}/# mintára szűkített ACL, eszközönkénti sebességkorlátok.
• Tárolás: SQLite a magon belül, nyers lemez feletti VFS-en keresztül, WAL módban, indításkor integritásellenőrzéssel; eszközregiszter, visszavonások, megőrzött üzenetek, tartós munkamenetek üzenetsorokkal az offline eszközök számára; magonként külön telemetriai napló rekordonkénti CRC-vel és összeomlás utáni helyreállítással.
• Üzemeltetés és felügyelet: watchdog időzítő a kezelőkhöz, állapotellenőrzés, korlátozott naplózás, syslog és statsd UDP-n, az újracsatlakozási viharokat átvészelő befogadás.
• Szállítás: CI-ben ellenőrzött, bitre azonos újraépítések, ISO és nyers GPT lemezkép, minisign aláírások, útmutatók KVM-hez, Proxmoxhoz és Hetznerhez.

Minden lépést az azt elhozó mérföldkő jelöl, a repóban lévő docs/PROGRESS.md fájl pedig az egyetlen igazságforrás arról, hogy mi működik valójában.

Az architektúra három képben

A teljes tervet a docs/ARCHITECTURE.md írja le, minden fontosabb döntés indoklása pedig ADR-ként található a docs/DECISIONS.md fájlban. Íme az áttekintés.

A rétegek

Fentről lefelé: a bróker (munkamenetek, témafa, QoS, megőrzött üzenetek, végrendeletek, ACL, korlátok), az MQTT kodek, a TLS, a TCP, a hálózati réteg, majd a meghajtók. E fő útvonal mellett áll a tárolás (SQLite és a telemetriai napló), mindez alatt pedig a memóriakezelés, a platformfelismerés és a build időben konstansokká fordított konfiguráció, a beágyazott CA-tanúsítvánnyal, a szervertanúsítvánnyal és a kulccsal együtt. Egyedül a virtio eszközökkel rendelkező hipervizor van a képen kívül.

Szál magonként, megosztott állapot nélkül

Minden adatmag saját ciklust forgat, saját TCP-veremmel, TLS-állapotokkal, a bróker egy szeletével (munkamenetek és témafa), heap-gyorsítótárral és telemetriai partícióval. A magok semmilyen módosítható állapotot nem osztanak meg, csak korlátos, zármentes gyűrűket, minden rendezett magpárhoz egyet. A legfelső mag az SQLite-ot futtatja, és semmi mást.

A hálózati kártyának ma egyetlen sorpárja van, amelyet a 0. mag tart kézben. Ez minden MQTT-folyamot a négyes Toeplitz-hash-e alapján az egyik munkamagra irányít, és elküldi mindazt, amit a munkamagok visszaadnak. A munkamenet a saját otthoni magján él, amelyet a kliensazonosító hash-e határoz meg, így az átvétel, a végrendeletek és a tartósság sosem lépi át a magok határát. Az a kapcsolat, amely egy másik magra érkezik, ott tartja a TCP- és TLS-állapotát, az egyszerű MQTT-t pedig kredit alapú forgalomszabályozással továbbítja az otthoni magnak. Minden irányított üzenet a bróker többi szeletére is szétterjed, amelyek mindegyike a megőrzött üzenetek egy replikáját tartja.

Három szabály tartja egyben ezt a modellt. Végigvitt feldolgozás: a beérkezett csomagot egyetlen mag teljes egészében feldolgozza, a TCP-től a helyben történő TLS-visszafejtésen, az MQTT-elemzésen és az útválasztáson át a titkosított válaszig, feladatsorok nélkül és az alkalmazási pufferekbe való másolás nélkül. Adaptív lekérdezés: terhelés alatt a vételi sorokat aktívan lekérdezzük, tétlenség esetén a mag visszatér a megszakításokhoz és a WFI-hez; a megszakításkezelők csak nyugtázzák a megszakítást és megjelölik a munkát. Watchdog időzítő: magonkénti 10 ms-os ütem elkapja azokat a kezelőket, amelyek túllépik a költségvetésüket.

Egy PUBLISH élete

Az eszköz elküld egy TLS-rekordot. A hálózati kártya leíróval, másolás nélkül átadja a mag ciklusának. A ciklus ellenőrzi a TCP-t, helyben visszafejti a TLS-t, és egy kölcsönzött pufferből elemzi az MQTT-t, majd a memóriában ellenőrzi az ACL-t, a sebességkorlátot és az útvonalat a témafán át. Ha egy másik magot érdekel az adott téma, útválasztási üzenetet kap a tartalomra mutató hivatkozással és a témaazonosítóval; az adatbázis telemetriai rekordot vagy megőrzött üzenet frissítést kap, kötegelve. A PUBACK válasz közvetlenül a kimenő pufferbe titkosítódik, és egyesül a TCP ACK-kal, így az eszköz felé egyetlen szegmens indul. A másik magnak az üzenet előfizetőnként egy titkosításba kerül a küldés pillanatában.

Mennyibe kerül egy kapcsolat

A cél legfeljebb 512 bájt tétlen TLS-kapcsolatonként, 256 felé törekedve. Amíg a kapcsolat nyugszik, semmit nem tartunk pufferben érte: a beérkezett adatokat közvetlenül a hálózati keretből dolgozzuk fel, a küldési, a rekord- és az MQTT-pufferek pedig csak addig léteznek, amíg valami befejezetlen vagy nyugtázatlan. A mag ezt maga is méri: pontos heapszámlálók kért bájtokban és a ténylegesen lefoglalt blokkokban, tíz másodpercenként rögzítve, nyitott kapcsolatonkénti, alapszint feletti heapként.

Mérve HVF alatt, négy virtuális maggal, ebből három munkamag, ahol minden eszköz egy mTLS-kapcsolatot és egy QoS 1-es előfizetést tart, a foglaló kerekítésével együtt:

A hálózati keretek készlete fixen körülbelül 2 MiB, ami tízezer kapcsolatnál nagyjából 200 B kapcsolatonként, egymillió kapcsolatnál nagyjából 2 B. Ennél többet nem tudtunk mérni: a QEMU felhasználói módú hálózata macOS-en 10 197 kapcsolatnál nem fogadott el több kapcsolatot, nagyjából a QEMU-folyamat 10 240 leírós határánál. A szám csökken, ahogy a fix részek több kapcsolatra oszlanak szét, így nem nő a kapcsolatok számával.

Biztonsági modell

A biztonság az első prioritás, és minden ütközést megnyer a többi céllal szemben. A modell több rétegből áll:

• Egyetlen port. TCP 8883, csak TLS 1.3, kötelező klienstanúsítványok, amelyeket a képfájlba ágyazott CA ír alá. Az MQTT-kliensazonosítónak meg kell egyeznie a tanúsítványban szereplő eszközazonosítóval.
• Nincs bejárat. Nincs shell, konzolbemenet, SSH, adminisztrációs API, dinamikus kód, hálózaton elérhető SQL, sem fájlrendszer.
• Memóriabiztonság. Rust, a protokollcsomagokban forbid(unsafe_code)-dal; minden unsafe blokkhoz // SAFETY: megjegyzés tartozik, amelyet egy lint ellenőriz, külső bemenetre pedig nincs pánik: a clippy az adatúton lévő csomagokban tiltja az unwrap, expect, indexelés és panic! használatát.
• Kihasználás elleni védelem. A W^X a leíró kódolásával és a SCTLR_EL1.WXN bittel érvényesül, és minden indításkor felülvizsgálatra kerül. A laptáblák indítás után csak olvashatók, írható alias nélkül. A címtér alsó fele ki van zárva. Minden veremnek van őrlapja, a kivételek külön veremen futnak. A PAC és a BTI akkor kapcsol be, ha a processzor támogatja, és ezt füsttesztek ellenőrzik.
• Visszaélésekkel szembeni ellenállás. SYN-sütik; a befogadás elutasítja az új kapcsolatokat, bármiféle kriptográfia előtt, ha kevés a heap, ha az adatbázis lemaradásban van, ha túl sok a folyamatban lévő kézfogás magonként vagy forráscímenként, vagy ha túl magas a kézfogások üteme. Eszközönkénti sebességkorlátok, korlátos sorok, a bróker ellennyomásához kötött TCP-ablak, korlátozott naplózás, watchdog időzítő és állapotellenőrzés.
• Megváltoztathatatlanság. A konfiguráció, a CA és a szerverkulcs a képfájlba van ágyazva. Bármi megváltoztatása új képfájlt jelent.

A fenyegetésmodell a docs/SECURITY.md fájlban található.

Tárolás fájlrendszer nélkül

Az adatok egy különálló lemezen élnek, virtio-blk vagy virtio-scsi eszközön, amelyen nincs fájlrendszer. Az elrendezés minimális és saját:

LBA 0      [ szuperblokk: varázsérték · elrendezés-verzió · uuid · régiótábla · CRC-32C ]
LBA 8, 16  [ fájlméret-tábla, A/B rések (a legújabb érvényes nyer) ]
LBA 64     [ SQLite főadatbázis ½ ][ SQLite WAL ⅛ ][ napló 1 MiB ][ telemetriai napló: 8 partíció … ]
utolsó 4 KiB [ terület a blokkeszköz indításkori önellenőrzéséhez ]

Az SQLite-ot (vendorolt 3.54.1, build közbeni ellenőrzőösszeg-vizsgálattal) clanggal fordítottuk a magba, szabványos könyvtár nélkül, és fix memsys5 heapet használ. A VFS-e három fix fájlt képez le lemezrégiókra. WAL módban fut locking_mode=EXCLUSIVE beállítással, így nincs szüksége megosztott memóriás indexre, valamint synchronous=FULL mellett; ha a quick_check indításkor hibát talál, a rendszer biztonságosan leáll. Az adatbázisban találhatók az eszközregiszter, a visszavonások, a megőrzött üzenetek és a tartós munkamenetek a nem csatlakozó eszközök QoS 1-es üzenetsoraival.

Az adatbázis magja, a legmagasabb sorszámú, az SQLite-ot futtatja és semmi mást. Az adatsík zármentes SPSC gyűrűn keresztül küldi neki az állapotváltozásokat; ő ezeket 5 ms-onként vagy 512 műveletenként egyetlen tranzakcióba gyűjti, a nyugtákat pedig egy másik gyűrűn adja vissza. Az üres lemezt az első indításkor formázza; minden mást soha nem formáz felül.

A telemetria más úton halad. Minden elfogadott PUBLISH a storage.telemetry_topics alatt felsorolt témákon a saját magja telemetriai naplójának partíciójába kerül: szegmensek gyűrűjébe, rekordonkénti CRC-vel, a szegmens sorszámával sózva, így a gyűrű régi köreinek tartalma soha nem bukkan fel újra. A magok a rekordokat saját gyűrűjükön, másolás nélkül adják át az adatbázis magjának, amely 5 ms-onként vagy 256 KiB-onként írja ki őket. Indításkor a helyreállítás minden kiírt rekordot megtart, levágja a befejezetlen farkat, és új szegmensben folytatja. A megőrzés méret szerint történik, a gyűrűn keresztül, és kor szerint, a retention_days beállításon keresztül. Ezt egymillió rekorddal és írás közben kiadott kill -9-cel ellenőriztük.

A számok

A tools/loadgen terhelésgenerátor három dolgot végez: mTLS-es és CONNECT-es TLS 1.3 kézfogási vihart, hosszú életű, PINGREQ-et küldő kapcsolatokat, amelyek másodpercenként telemetriát publikálnak, valamint újracsatlakozási viharokat. A make bench Apple M4 Pro gépen, HVF alatt a következőt adja:

A vendégen belüli szám, ahol a kliens és a szerver ugyanabban a virtuális gépben van, és minden munkamag önállóan dolgozik, azt mutatja, hogy az adatsík lineárisan skálázódik. A hálózati számot a QEMU egyszálú felhasználói hálózata korlátozza, nem a vendég; ezt is rögzítettük, ADR-032 néven.

Az újracsatlakozási viharokat úgy teszteljük, hogy az összes eszköz egyszerre csatlakozik, az elutasított próbálkozásokat késleltetéssel megismétli, majd mind leáll DISCONNECT nélkül. A fejlesztői módban a heap_limit_mb= paraméter arra készteti a befogadást, hogy a heapet a valóságosnál kisebbnek tekintse, így a heapnél nagyobb vihar is kipróbálható kevés sockettel. Egy ilyen, 3 000 eszközös körben 1 368 csatlakozott 36 másodperc alatt, 5 619 próbálkozást pedig rendben elutasítottunk, 8 MiB-os korlát mellett; a memória a vihar után visszaállt.

Hogyan dolgozunk

A projektet egy írott specifikáció, a PROMPT.md vezeti a mérföldkőtervvel, és minden mérföldkő ugyanazzal a rituáléval zárul: zöld make check és make smoke, egyetlen commit M<n> jelöléssel, bejegyzés a docs/PROGRESS.md fájlba és ADR minden olyan döntéshez, amely nem magától értetődő. A szabályok rövidek, és nem alkudozunk rajtuk: nincs pánik külső bemenetre, unsafe csak a hardveres és FFI-csomagokban és mindig megjegyzéssel, nincs allokáció a forró úton, megjegyzés minden atomi műveleti sorrendhez, minden korlát a konfigurációból származik, a szándékos ideiglenes részek pedig hangosan buknak el.

A CI többet végez, mint amennyit kézzel el tudnánk érni: fmt, clippy a hostra és az aarch64-unknown-none célra, typos, actionlint és shellcheck; teszteket Linuxon és macOS-en arm64-en; a mag építését fejlesztői és éles konfigurációval, az ELF méretével az összefoglalóban; indítást QEMU alatt a füsttesztek összes forgatókönyvével és a soros naplók elmentésével; cargo-deny a figyelmeztetésekre, licencekre és forrásokra; percenként fuzzolást a tizenegy cél mindegyikén, éjszaka pedig célonként tíz percet gyorsítótárazott korpusszal. Ehhez jön a CodeQL, az OpenSSF Scorecard, a Dependabot és a SLSA-eredetű kiadás. Minden idegen action a teljes commit SHA-hoz van rögzítve.

A reprodukálhatóságot szó szerint vesszük: a make repro kétszer építi meg a HEAD-et friss munkafákban, és bájtról bájtra összehasonlítja az ELF-et, az ISO-t és a nyers lemezképet. A kiadásokat minisignnel írjuk alá, az artefaktumok pedig ellenőrizhetők a gh attestation verify paranccsal. Az éles képfájl tartalmazza a szerver privát kulcsát, ezért maga az ISO titok; a GitHubon a kiadások mellett lévő képfájlok fejlesztői képek, ideiglenes kulcsokkal, és csak kipróbálásra valók.

Mit tanultunk

Néhány lecke, amely megváltoztatta a tervet:

• A saját TCP végül mégis megérte. A prototípus smoltcp-n futott, és az M13-ig jól szolgált minket. De egy szerver, amely százezres nagyságrendű kapcsolatot tart, nem kliens-TCP-t igényel, hanem SYN-sütiket, időzítőkereket és 96 bájtos állapotot. Az M14-ben a smoltcp-t saját, csak szerveroldali veremre cseréltük, szimulált veszteséges tesztekkel és szegmens-fuzzinggal.
• A memóriát belülről kell mérni. A kapcsolatonkénti becslések használhatatlanok voltak, amíg a mag maga nem kezdte számolni a heapet az allokátor blokkjaiban, nem pedig a kért bájtokban. Csak ekkor láttuk, hová megy valójában az 512 bájt, és ekkor jutottunk le 494-re.
• A tesztelőeszköz a termék része. A legnagyobb korlát nem a mag volt, hanem a QEMU felhasználói hálózata és az efemer portok száma a fejlesztői gépen. Százezer és több kapcsolathoz macOS-en vmnet-shared, vagy Linux KVM-mel, tap interfésszel és több klienscímmel van szükség.
• Az SQLite operációs rendszer nélkül is lehetséges, de csak szigorú feltételekkel: fix heap, kizárólagos zárolás megosztott memória nélkül, fájlokat nem ismerő VFS, és olyan befogadás, amely nem engedi lemaradni az adatbázist.
• Az újracsatlakozási viharok a normális állapot, nem a kivétel. Amikor a mobilhálózat leesik, majd visszatér, eszközök ezrei kopogtatnak egyszerre. Ezért a befogadás bármiféle kriptográfia előtt elutasítja a kapcsolatot, és minden elutasított kapcsolat szinte semmibe sem kerül.

Mi következik

Az M17 utáni munkát három irányban terveztük meg, a közöttük lévő sorrend pedig a docs/PLAN.md fájlban van rögzítve. Ezek közül egyik sincs még megépítve.

• Egyetlen ISO több platformra. Ugyanaz az urmqtt-<env>-<verzió>.iso fájl és egyetlen nyers GPT lemezkép, amely aarch64 UEFI-n, x86_64 UEFI-n és x86_64 BIOS-on is elindul, virtuális gépekben és valódi hardveren, egyetlen Intel PC-vel kezdve. Továbbra is mindent magában foglaló eszköz, reprodukálható és aláírt.
• Nyers lemez, fájlrendszer nélkül. Bájtszintű formátumspecifikáció, a magéval közös elemzőket használó urmqtt-disk host eszköz, 1 MiB-os régiózarás, a lemez növekedése az adatokkal, discard a vékonyan kiosztott lemezekhez, az adatbázis A/B pillanatképei, bitellenőrzés és választhatóan AES-256-XTS titkosítás hardveres AES-szel.
• Bizonyíthatóan biztonságos. Eszközök futásidejű visszavonása és engedélyezési listája aláírt vezérlőcsatornán, új képfájl nélkül; a saját TLS és TCP differenciális és konformanciatesztelése; KASLR, veremvédelem, kCFI, MTE és megerősített allokátor; EL0 szinten izolált SQLite; Secure Boot; SBOM és cargo-vet; végül külső auditra szánt csomag.

Azok a platformok, amelyek csak nem virtio eszközöket kínálnak, mint az AWS ENA vagy az Azure MANA, egyelőre nem támogatottak. A Raspberry Pi 4 és 5 KVM-hostként, a Hetzner CAX és az Oracle Ampere A1 dokumentált és kóddal támogatott, de valódi szolgáltatáson még nem próbáltuk ki őket.

Próbálja ki

A repó a github.com/zeljan-alduk/urMQTT címen érhető el. A rögzített nightly eszközlánccal rendelkező Rusttal és a QEMU-val a make certs, a make run és egyetlen mosquitto kliens elegendő az első PUBLISH-hoz mTLS-en keresztül a saját gépén. Az elején szereplő figyelmeztetés a végén is érvényes: ez pre-alfa, és mindent, ami működik, a docs/PROGRESS.md ír le. A hibajelentéseket, a tervezéssel kapcsolatos kérdéseket és a biztonsági bejelentéseket a SECURITY.md útmutatása szerint szívesen fogadjuk. Minden következő mérföldkőről itt fogunk beszámolni.

Ezen a blogon leírjuk, amit útközben megtanultunk. Nem marketingszövegeket, hanem konkrét jegyzeteket: mi romlott el, hogyan oldottuk meg, és mit csinálnánk ma másképp.

Miről fogunk írni

• Jegyértékesítés a tömegközlekedésben. Érintés nélküli kártyák, SAM-modulok, hálózat nélküli működés és minden, amit egy terminálnak ki kell bírnia egy napi tizenkét órát rázkódó járműben.
• Mobilalkalmazások a terepen. Android és Flutter olyan eszközökön, amelyek nem hétköznapi telefonok: kártyaolvasóval, nyomtatóval és egy egész műszakot kibíró akkumulátorral.
• Backend és flottafelügyelet. Honnan tudjuk, hogy a járműben lévő eszköznek gondja van, még mielőtt a sofőr jelentené.
• Hardver. Az asztali prototípustól a sorozatgyártásba kerülő panelig, és minden hiba a kettő között.
• Helyi MI-modellek. Hol van értelme a saját hardveren futó modelleknek, és hol egyszerűen jobb választás a felhő és egy API.

Hogyan fogunk írni

Röviden és konkrétan, kóddal és számokkal, ahol vannak. Akkor publikálunk, amikor van mit mondanunk, nem menetrend szerint. A bejegyzések horvátul íródnak, és az oldal minden nyelvére lefordítjuk őket; RSS útján is követhet minket.

Ha érdekli egy téma, vagy hasonló problémán dolgozik, írjon nekünk az info@aldo.tech címre.