urMQTT egy valódi ARM64 VPS-en: nincs képernyő, nincs hardveres véletlenszám-generátor, és egy kézfogás, amely túl lassú volt

Az előző írás, az urMQTT v0.3.0, négy tétellel zárult a „Mi következik" alatt: döntés a nyilvános demo brókerről (D1), a PCI és virtio parserek fuzzingja és egy teszt a zárolt lapozótáblákra, egy kulcsmegadó párbeszédablak az építő oldalon, és a bare metal. A négyből ebben a körben egyik sem készült el, és ezt mondjuk el először. Helyette azt csináltuk, ami végig hiányzott: lefuttattuk az urMQTT-t egy valódi ARM64 szerveren KVM alatt, és az alábbiak szinte mind erről az egy gépről származnak. A régi lista első tétele, a CI, rendbe lett téve (a korábbi írást és a kiadási megjegyzéseket, amelyek pirosnak nevezték, kijavítottuk)

Az előzetes megjegyzés ugyanaz marad: a projekt pre-alpha, a számok a kódot, a teszteket és konkrét kísérleteket mérnek egy gépen, nem az éles üzemi érettséget. Ahol egy számot nem a célgépen mértünk, azt kimondjuk.

Hogyan nézett ki ez időben

Az utolsó írás óta (november 3., 02:43) mostanáig (november 4., 03:18) a main ágon 29 új commit van, összesen 244. Mint korábban, a projekt Claude Code-dal készül (a commitok Co-Authored-By: Claude sort viselnek). A számokat az utolsó két írás módszerével számoltuk (minden .rs fájl a vendor/ és a fuzz/ könyvtáron kívül, a #[test] függvények, a ## ADR- címsorok a docs/DECISIONS.md fájlban); a módszer a régi commiton ugyanazokat a számokat adja, mint akkor.

Időpont	Commit	Idő	Rust-sorok	Tesztek	ADR-ek	Commitok
utolsó írás	f1a7fbc	nov. 3., 02:43	115 148	962	133	215
ma	efddf6e	nov. 4., 03:18	117 084	978	134	244

Növekedés: +1 936 sor, +16 teszt, +1 ADR. Megint kevés az új kód; maga a P-256 assembly (1 509 sor) átvett (vendored) kód, és nincs benne a sorszámban.

Egy második valódi gép

Eddig a projektnek egy valódi szervere volt: egy Contabo VPS AMD EPYC-cel (x86_64, KVM), amelyen a Mosquittóval való teljesítményösszehasonlítás futott. Az ARM64 csak QEMU-ban futott, Macen hardveres gyorsítással, a CI-ban anélkül. Az új gép egy netcup VPS 500 ARM G12.5: egy Neoverse N1 mag nagyjából 3 GHz-en, 2 vCPU, 3,9 GiB RAM, 64 GiB virtio lemez, QEMU/KVM UEFI firmware-rel, virtio hálózati kártya. Mindent a szolgáltató REST API-ján át, parancssori klienssel vezéreltünk: feltöltjük az ISO-t, virtuális CD-ként csatoljuk, átállítjuk az indítóeszközt, áramtalanítjuk és újraindítjuk.

Mit csináltunk rajta, sorrendben:

1. Először pillanatkép az eredeti rendszerről. UEFI-vel online pillanatkép nem lehetséges, ezért a szervert kikapcsoltuk, és offline pillanatképet készítettünk.
2. Telepítés. Az ISO telepítője kiírta a képet a lemezre (a 30 másodperces visszaszámlálással együtt összesen nagyjából 40 másodperc), majd a gépet tervezetten magától kikapcsolta.
3. Indítás a telepített lemezről nagyjából 35 másodpercig tartott egy TLS-kézfogásig.
4. Egy megtartott (retained) üzenet túlélt egy kemény áramtalanítást. Közzétettük, az API-n át megszakítottuk az áramellátást, újraindítottuk, és visszaolvastuk.
5. A telepített lemez, a Diagnosztikai bejegyzéssel mérve (csak olvasás; az írásteszt kimaradt, mert a telepített elrendezés nem hagy nem lefoglalt területet, és ez szándékos): szekvenciális olvasás 332 MiB/s, véletlenszerű 4 KiB-os olvasás 22 147 másodpercenként, p50 10,4 µs, p90 28,3 µs, p99 671 µs, maximum 9,9 ms (2 000 olvasás).

Öt tétel nem tesztcsomag: ez egy gép, mindenből egy futás, és a telepítési útvonalat egyszer próbáltuk ki a valódi lemezen. Azt viszont megmutatja, hogy a kernel saját virtio-blk meghajtója, a telepítő és az indítás működik egy valódi felhős vendégen, és nem csak egy laboratóriumi emulátorban.

Nincs képernyő, ezért a diagnosztika a hálózaton megy

A v0.3.0 Diagnosztikai bejegyzése a framebufferre rajzolja a számait. Ezen a szerveren a szolgáltató konzolja azt mondja: „Display output is not active": a virtuális gépnek van virtio grafikus kártyája, amelyhez nincs meghajtónk, a soros port pedig nincs kivezetve. A számok léteztek, és senki sem tudta elolvasni őket.

A megoldás egy indítási szó, a diag-serve: a gép lefuttatja ugyanazokat a méréseket, aztán normál élő brókerként indul, és a jelentést egyetlen JSON dokumentumként a $SYS/diag/report megtartott üzenetben teszi közzé, amelyet csak operátori tanúsítvánnyal lehet olvasni. Egy kis eszköz, az urmqtt-diag-png, ebből a JSON-ból rajzolja ki a műszerfalat ugyanazzal a kóddal, amelyet a kernel a képernyőn használ (ugyanaz az elrendezés, ugyanaz a 8x8-as betűkészlet), így a kép az a képernyő, amelyet a gép megmutatott volna:

Útközben két dolgot adtunk a képernyőhöz, mert hiányoztak: a CPU órajelét (a PMU ciklusszámlálója az időalaphoz képest: itt 2,95-2,98 GHz; ahol csak fix frekvenciájú időzítő olvasható, ott „nem mérhető" áll ahelyett, hogy az időzítő frekvenciáját a CPU-énak írnánk) és egy panelt a véletlenszám-generátornak.

Miből áll a véletlenszám-generátor

A panel megmondja, honnan kapta a generátor a magját, és friss bájtokat tesztel minden hardveres forrásból. Ezen a gépen ezt mutatja:

• virtio-rng: nincs eszköz. RNDR (a CPU saját utasítása): ezen a CPU-n nem érhető el.
• A betöltő EFI véletlenszám-generátora: 8 érték a 8-ból nem nulla.
• A CPU-időzítési jitteren alapuló tartalék (ADR-038): 1 024 minta, egyenként 64 lépés a PMU ciklusszámlálóján át, mintánként 3 bit becsült érték, 768 bit jóváírva (a becslés negyede, szándékosan), az egészségi tesztek átmentek.
• A generátor kimenete, 4 096 bájton végzett épségteszt: 49,6 % egyes, a leghosszabb futam 16 bit. Ez annak ellenőrzése, hogy semmi sem ragadt be és semmi sem torzít, nem statisztikai tanúsítás.

A generátor ezen a szerveren tehát a jitter-tartalékra és arra támaszkodik, amit a firmware átadott. Pontosan ezt írja le az ADR-038, és ez a leggyengébb magolás, amelyet a kernel elfogad. Nem nevezzük töröttnek: a jóváírt bitek meghaladják azt a küszöböt, amelyet a kernel megkövetel (256), és a becslő óvatos. Azt sem tudjuk bizonyítani, hogy olyan jó, mint egy hardveres forrás. Hogy egy éles képnek meg kell-e tagadnia az indulást hardveres forrás nélkül, hacsak az operátor nem vállalja, az a tulajdonos nyitott kérdése (az ütemtervben szerepel, lent). A gyakorlatban a szolgáltatónak is kérdés: a virtuális gép hardveres véletlenszám-eszköze eldöntené.

Egy kézfogás, amely túl lassú volt

A Diagnosztikai bejegyzés azt is megmutatta, mibe kerül egy teljes kölcsönös TLS-kézfogás a szerveren: 1,08 ms. Szinte az egész nyilvános kulcsú aritmetika: két ECDSA P-256 ellenőrzés (a kliens tanúsítványa és a kliens bizonyítéka), egyenként nagyjából 508 µs, X25519 176 µs, egy ECDSA aláírás 141 µs. Az x86_64-en ezt korábban megoldottuk (ADR-130, az OpenSSL/Intel assembly: a P-256 három-négyszer gyorsabb); ARM64-en még a hordozható RustCrypto kód futott.

Ugyanezt megcsináltuk ARM64-re (ADR-255). Az assembly az OpenSSL ARMv8 nistz256 kódja (Apache-2.0), a ring 0.17.14 verziójából véve, átvéve (vendored) a származásával és minden mechanikus változtatás leírásával. A részletekben ez számított:

• Csak egész számokkal. Az assembly nem használ NEON regisztereket. A két táblaválasztó függvény, amelyet az upstream NEON-nal ír, kikerült, és konstans idejű, maszkolt keresést írtunk helyettük Rustban (egy 12 µs-os aláírásból legfeljebb 1,4 µs-ba kerülnek).
• Ugrásvédelem. A kernel BTI-vel és mutatóhitelesítéssel (pointer authentication) épül. A 8 exportált belépési pont mindegyikének van landing pad-je, a kernel diszasszemblerében ellenőrizve, és a hat, amely elmenti a link regisztert, alá is írja azt.
• Tesztek, mert ez kriptográfia abban az alapban, amelyben megbízunk. Az x86_64 teljes tesztcsomagja most aarch64 Linuxon is fut: a mező- és skaláraritmetika egy iskolai szorzású referenciával szemben, a teljes generátortábla (2 368 elem) a RustCrypto-val szemben, az aláírások bitre egyenlők a RustCrypto-éval, az ellenőrzési ítéletek, az ECDH görbén kívüli és nulla bemenetekkel, és az ismert válaszú tesztek, amelyek minden indításkor lefutnak az éles útvonalakon. Egy négymagos virtuális gépben, megszakításvihar alatt 59 526 ismert válaszú kör futott 0 eltéréssel.
• Időzítési teszt kontrollal, és egy jel, amely a saját tesztünk volt. Egy szándékosan szivárgó szorzás |t| értéke 482 és 1 755 között van, tehát a teszt lát szivárgást ebben a nagyságrendben. Egy konténerben futó Apple magon az ECDH 0,2-2,1-et, az aláírás 0,5-1,9-et, a kulcsgenerálás 0,8-5,5-öt ért el. A CI-futtató arm64 szervermagján az ECDSA-aláírás három próbában |t| = 8,6, 9,1 és 8,3 értéket ért el, a mi 7-es határunk felett, miközben az ECDH (3,9) és a kulcsgenerálás (1,9) ugyanazon a gépen átment. Az ismétlődő eredmény nem zaj, ezért nyitott megállapításként felírtuk (A255-W1), és néhány órára ennél az egy esetnél 12-re emeltük a határt, hogy a build átmenjen. Aztán megtaláltuk az okot, és a tesztkeret volt: az eset egyetlen rögzített üzenetet írt alá, így a ritka kulcs minden alkalommal ugyanazt az aláírást adta, a véletlen kulcsok pedig minden alkalommal mást, és egy ismétlődő aláírás DER-kódolása gyorsabb (|t| = 49-57 a kódolásra egyedül). Ha mindkét osztályban mérésenként véletlen üzenetet használunk, az eset 1,4 és 1,8 értéket ér el a futtatón (egy Neoverse N2 virtuális gép), a nonce generálása egyedül 2,7 és 1,1 értéket, és a határ visszatért 7-re. Egy dolog nyitva marad (A255-W2): az a processzorjelző, amely az Arm magokon adatfüggetlenné teszi a szorzó időzítését (DIT), sehol sincs beállítva, sem a kernel által, sem a gazdagép-oldali hívások körül. Egyetlen mérés sem mutat különbséget, de a futtató virtuális gépe nem teszi elérhetővé ezt a képességet, így a teszt sem tudta megmutatni.

Mit nyertünk vele

Először a mikrobenchmark azon a gépen, ahol fejlesztettük, egy Apple M4 Pro (nem a célprocesszor, ezért az arányok a szerveren eltérhetnek), ugyanazzal a kóddal, amelyet a kézfogás hív, előtte és utána:

Művelet	előtte (µs)	utána (µs)	arány
kulcsgenerálás	30,8	7,0	4,4x
ECDH P-256	135,2	25,0	5,4x
ECDSA aláírás	34,7	11,6	3,0x
ECDSA ellenőrzés (ismeretlen kulcs)	147,4	29,1	5,1x
CA-ellenőrzés (regisztrált kiállító)	54,2	9,6	5,6x
X25519 (változatlan kód)	20,4	20,1	1,0x
kézfogásbecslés (a fentiek összege)	292	104	2,8x

Aztán az igazi: ugyanaz a terheléskeltő, ugyanaz a módszer, mint a korábbi teljesítményírásban (teljes TLS 1.3 kézfogás kliens tanúsítvánnyal, folytatás nélkül, MQTT CONNECT, a szerver zár elsőként), a szervertől 9 ms-ra lévő gépről futtatva, ugyanazon netcup VPS ellen, a változtatás előtt és után. A benchmark kép kézfogási korlátai fel vannak lazítva, mint az x86_64-es összehasonlításban; három ismétlés, a szám a medián.

Szálak	előtte (kapcs./s)	utána (kapcs./s)	arány	hibák
32	848 (408-855)	1 317 (957-1 317)	1,55x	0
64	827 (815-839)	1 398 (1 352-1 416)	1,69x	0
128	778 (714-788)	1 316 (1 313-1 383)	1,69x	0
egy kapcsolat TLS-része, p50, 32 szál	18,5 ms	13 ms

A teljes kézfogások másodpercenkénti száma nagyjából 1,55-1,7-szeresére nőtt, nem a háromszorosára, amelyet az aritmetika önmagában adna. Az ok egyszerű, és érdemes kimondani: a P-256-ot gyorsítottuk, az X25519 (176 µs), a TCP/IP verem, a rekordréteg és az MQTT változatlan, így a megmaradó hányad súlya nő (Amdahl törvénye). A következő jelölt az X25519.

Tájékoztatásul, az előző írás x86_64 szervere mellett. Ezek nem hasonlíthatók össze versenyként: más CPU-k, más magszám (4 szemben 2-vel), más távolság a generátorig (15 ms szemben 9 ms-mal), és mindkét esetben megosztott terheléskeltő gép, amely a futások alatt a saját CPU-jának 5-60 %-át elvesztette. Az összehasonlítható oszlop a szerver saját CPU-költsége kézfogásonként:

	Contabo, x86_64 EPYC (asm)	netcup, ARM64 N1 előtte	netcup, ARM64 N1 utána
szerver CPU kézfogásonként	0,26 ms (a bróker konzolja)	1,08 ms (Diagnosztika)	0,55 ms (Diagnosztika, egy futás, lásd alább)
kézfogás/s, 32 szál	169 (bench)	848	1 317
kézfogás/s, 64 szál	278 (bench)	827	1 398
kézfogás/s, 128 szál	413 (bench)	778	1 316

Ugyanazon a napon a Diagnosztikai bejegyzés újra lefutott ezen a gépen, az assemblyvel (egy olyan buildben, amely a végén a frissítésben leírt grafikus meghajtót is tartalmazza): a szerver CPU-költsége egy kölcsönös TLS-kézfogásra 553 µs volt, szemben a korábbi 1,08 ms-mal, 1,95-ször kevesebb. Az ECDSA-ellenőrzés 192 µs-ig tartott (korábban 508 µs), az aláírás 78 µs (141 µs), az X25519 pedig 209 µs (176 µs; ez a kód változatlan, és ennek a futásnak a CPU-órajele 2,58 GHz volt a korábbiak 2,95-2,98 GHz-ével szemben, így az egyes számok ezen a megosztott gépen több tíz százalékot mozognak). Ez egyetlen futás, megosztott gazdagépen. Az, hogy a kézfogási sebesség 1,55-1,7-szeresére nőtt, miközben a szerver saját költsége kézfogásonként 1,95-ször csökkent, összefér egymással: egy kapcsolat többi része a verem, a generátor és a hálózat. A futások közötti zaj látszik a nyers fájlokban: mindegyik hármas tartalmaz egy kiugró értéket (408 előtte és 957 utána 32 szálnál), amikor a terheléskeltő gép a CPU-jának nagy részét más virtuális gépeknek adta át. 128 szálnál mindkét gépen a generátor van a határán, nem a szerver.

A tesztcsomag többi része ezen a gépen

Ugyanaz a tesztcsomag, mint az x86_64 szerverre (áteresztőképesség, késleltetés, szétosztás, tétlen kapcsolatok), teljes egészében lefutott az új buildre. Ezekhez a sorokhoz nincs „előtte": a futást leállítottuk az assembly építéséhez, így ezek a változtatás utáni állapotot mutatják, és az assembly ezeket az útvonalakat nem érinti, kivéve a kapcsolatokat megnyitó kézfogásokat. Egy tény megmagyarázza a következők nagy részét: ennek a virtuális gépnek két vCPU-ja van. A 0. mag végzi a hálózati kártyát, az elosztást és az összes MQTT- és TLS-munkát, az 1. mag az adatbázismag, és végig 2-3 %-on volt kihasználva. Az x86_64 szervernek négy vCPU-ja és két munkamagja volt. Az alábbiak tehát egymagos brókerteljesítmény.

Tétlen kapcsolatok	5 000	10 000	20 000
csatlakozott	5 000 az 5 000-ből 4,3 s alatt	10 000, 9,3 s alatt	20 000, 21,2 s alatt
a kernel heapjének növekedése kapcsolatonként	0,34 KB	0,41 KB	0,43 KB
hibák	0	0	0

(0,50-0,66 KB kapcsolatonként az x86_64 szerveren a H7 commitnál. A heap-szám a $SYS/broker/memory/used értéke mínusz az értéke az első kapcsolat előtt.)

Késleltetés mérsékelt ütemben (8 pár x 100 üzenet/s, 64 B)	p50	p99
QoS 0	4,0 ms	6,9 ms
QoS 1	4,1 ms	7,0 ms

Szétosztás (1 publikáló, 64 B)	kézbesítve másodpercenként	p50	p99
100 feliratkozó, QoS 0, 50 üzenet/s	5 000 (mind)	5,9 ms	8,6 ms
100 feliratkozó, QoS 1, 50 üzenet/s	5 000 (mind)	6,3 ms	10,0 ms
1 000 feliratkozó, QoS 0, 10 üzenet/s	8 805 a 10 000-ből	207 ms	5,4 s

Elárasztás, 16 pár, a publikálók olyan gyorsan, ahogy a bróker átveszi	publikálva/s	kézbesítve/s	p50 / p99	elveszett kapcsolatok
QoS 0, 64 B	231 317	85 140	1,36 s / 2,8 s	0
QoS 0, 1 KiB	62 110	25 506	336 ms / 873 ms	0
QoS 1, 64 B	107 349	55 965	21 ms / 29 ms	0
QoS 1, 1 KiB	51 369	25 054	47 ms / 60 ms	0
QoS 1, 64 B, 64 pár	130 462	69 411	69 ms / 87 ms	0

Hogyan olvasandó. A mérsékelt ütemű késleltetés a bróker hozzájárulása plusz egy út a generátorig: a generátor közelebb van ehhez a szerverhez, mint az x86_64-es összehasonlításban, ezért a két késleltetésoszlop nem összehasonlítható. A QoS 0 elárasztás a túlterhelt egyetlen mag szokásos képét mutatja: a bróker másodpercenként 231 000 üzenetet fogad el és 85 000-et kézbesít (a többit a visszanyomás-szabályok eldobják, ezért vannak), másodperces nagyságrendű késleltetéssel, és egyetlen kapcsolat sem veszett el; az x86_64 szerveren ugyanilyen elárasztás futásonként több kapcsolatot áldozott fel a 20 ms-os watchdognak (az ADR-221 azóta megváltoztatta, hogyan számolódik ez a keret). Az 1 000 feliratkozós sor ugyanolyan jellegű, mint korábban, másodperces farkakkal, részben a generátor sajátjaival. Az x86_64 szerveren a H7 commitnál mért számok a korábbi írásban vannak; nem tesszük őket egy táblába ezekkel, mert a két mérés között az adatútvonalon a kód megváltozott (ADR-221-től ADR-224-ig), és a gépek mindenben különböznek.

Hibák, amelyeket mi magunk találtunk

• A kép azt mondta, „nem találtunk lemezt", pedig a lemez benne volt a jelentésben. Az urmqtt-diag-png első változata egyáltalán nem olvasta a disks mezőt. A projekt tulajdonosa ránézett a képre, azt mondta, hogy rossznak látszik, és igaza volt. Javítva, és egy teszt most visszaolvas egy lemezt a JSON-ból.
• Túl korán jelentettük ki, hogy a telepítő végzett. A szerver állapota kétszer ment „off"-ra: egyszer az áramtalanítás végén, egyszer amikor a telepítő végzett. A szkriptünk az elsőt vette a másodiknak, lecsatolta az ISO-t, és a régi rendszert indította, amely aztán a régi verziószámot jelentette, és emiatt olyan hibát kerestünk a telepítőben, amely nem volt ott. A szkript most előbb egy friss indításra vár.
• Elveszett a haladási előzmény. Az ütemtervhez készült elemzés megállapította, hogy az S6 mérföldkő commitja a docs/PROGRESS.md fájlt (1 763 sor, M0-tól S5-ig a mérföldkövek) a saját 26 soros bejegyzésével váltotta le. Napokig észrevétlen maradt, pedig a README ezt a fájlt „igazságforrásnak" nevezi. Az előzményből visszaállítottuk.
• A CI az assembly után bukott, két helyen. Három füsttesztbe bele volt írva a bootkép mérete („10 MiB"), amely a nagyobb kerneltől 11 MiB-ra nőtt; már nem feltételezik a méretet. A másik bukás a fent leírt időzítési teszt volt: először zajnak tűnt egy megosztott futtatón, ezért háromszor ismételtettük a tesztet; mindhárom próbában megbukott, így tudtuk meg, hogy jel, és a jel a saját tesztünknek bizonyult (minden alkalommal ugyanazt az üzenetet írta alá). Ezt az egy határt néhány órára megemeltük, nyíltan kimondtuk, és újra leszállítottuk, amint az okot kijavítottuk.
• A dokumentáció három indítási szót számol, a kódban négy van (diag-serve), és a README mérföldkőtáblája a múlt hét munkáját még tervezettként mutatja. Mindkettő szerepel az ütemtervben javítandó tételként.

Egy ütemterv, kérdésekkel

Először van ütemterv: nagyjából 40 tétel három fázisban (v0.4 megerősítés és üzemeltetés; protokoll és hálózat; skálázás, több felhő és bare metal), mindegyik egy dokumentumból vett indokkal, ráfordítással, kockázattal és ellenőrzési móddal, 16 kérdéssel, amelyet csak a tulajdonos tud megválaszolni, és egy listával arról, ami hatókörön kívül van. Néhány dolgot világosan kimond: csak az MQTT 3.1.1 támogatott, a QoS 2 publikálás lezárja a kapcsolatot, nincs IPv6 (a szolgáltató egy /64-et ad), nincs WebSocket és nincs kimenő kapcsolat a brókertől, és nincsenek meghajtók a nagy felhők hálózati és tárolóeszközeihez.

Mi nincs még bizonyítva

• Az assemblyvel a kézfogásonkénti CPU-költséget a Neoverse magon csak egyszer mértük (553 µs, szemben a korábbi 1,08 ms-mal, alacsonyabb órajelen, megosztott gazdagépen); az 1,55-1,7-szeres szám a teljes kézfogási sebességből jön, a 3-5-szörös pedig egy Apple magból. A refaktor x86_64 oldalát (a külön fájlba mozgatott kódot) típusellenőriztük és lefordítottuk, de az egységteszteket nem futtattuk, és az x86_64 kernelt sem indítottuk el utána: az x86_64 tesztcsomagok nincsenek a CI-ban, kézzel futtatjuk őket a Contabo VPS-en, és ez ennél a változtatásnál még nem történt meg.
• Konstans idejűség: a P-256 kulcsgenerálásnál, az ECDH-nál és az aláírásnál (a kulcs és a nonce) a statisztikai teszt nem talált függést egy ritka titoktól. Apple magon és a CI-futtatón futott (egy Neoverse N2 virtuális gép), nem a netcup Neoverse N1 magján, és soha nem úgy, hogy a DIT jelző be lett volna állítva egy szervermagon (A255-W2, nyitott: a kernel nem állítja be). X25519-re vagy Ed25519-re nem futott. Egy fekete dobozos teszt csak azt korlátozza, amit a mintaméreténél fel tud oldani.
• Egy szerver, egy szolgáltató, egy telepítés. Több eredmény (telepítés, áramkimaradás) egyetlen futás. A kézfogásokat leszámítva a teljesítménysoroknak nincs „előtte", és egy két vCPU-s gép a brókernek egy adatmagot ad.
• A véletlenszám-generátor ezen a szerveren jitterből és a firmware-ből kap magot, ahogy fent leírtuk.
• Az aláíró kulcs még mindig próbakulcs, a kiadási képek fejlesztői buildek, és ennek az írásnak a fordításait AI írta, anyanyelvi beszélők nem ellenőrizték.
• Nincs független audit, nincs bare metal, nincs IOMMU.

Mi következik

1. X25519 assemblyben ARM64-re (ez a megmaradó kézfogásból 176 µs), és a kézfogásonkénti mérés megismétlése a Neoverse magon, egynél többször.
2. Döntés a véletlenszám-generátor alapértelmezéséről: megtagadni az indulást hardveres forrás nélkül, hacsak az operátor másként nem rendelkezik, vagy megtartani a jitter-tartalékot, és hangosan megmondani.
3. A régi lista: döntés a D1-ről, a PCI és virtio parserek fuzzingja, a kulcsmegadó párbeszédablak az építő oldalon.
4. Az ütemtervből, a következő kiadásra: valódi aláíró kulcs és éles PKI, MQTT 5.0 és QoS 2.

A kód a github.com/zeljan-alduk/urMQTT oldalon van; a docs/PROGRESS.md továbbra is az igazságforrás arról, hogy mi működik, a docs/PERFORMANCE.md arról, hogy mit mértünk (a 10. szakaszban vannak az assembly számai), a docs/AUDIT.md pedig arról, hogy mi nincs bizonyítva. Pre-alpha, mint eddig; a hibajelentéseket és a biztonsági bejelentéseket a SECURITY.md útmutatása szerint szívesen fogadjuk.

Frissítés, november 4., ugyanazon a napon később. Négy dolog a szöveg megjelenése utáni órákból.

1. A hiányzó szám. A Diagnosztikai bejegyzés újra lefutott a netcup szerveren az assemblyvel, és megadta az első táblázatból hiányzó számot: 553 µs szerver CPU kölcsönös TLS-kézfogásonként, szemben a korábbi 1,08 ms-mal (részletek a táblázat alatt).
2. Az aláírási jel a mi tesztünk volt. A fent leírt időzítési jel okát megtaláltuk és kijavítottuk a tesztkeretben (minden alkalommal ugyanazt az üzenetet írta alá); a határ visszatért 7-re. Ami nyitva marad, az az, hogy a DIT jelző sehol sincs beállítva (A255-W2).

3. A képernyőprobléma megoldódott, és a main ágon van. Írtunk egy meghajtót a virtio grafikus kártyához (csak 2D, ADR-256), amelyet egy, a képbe beleépített konfigurációs kulcs kapcsol (console.virtio_gpu, alapértelmezetten off, az auto és az on az 5-ös konfigurációs formátumot igényli). on esetén a szolgáltató Screen lapja élőben mutatja a Diagnosztika műszerfalát a netcup szerveren, ugyanazt a képet, mint fent, beleértve az utolsó képernyőt is a „press any key" felirattal. A fuzz célpontja valódi hibát talált az első változatban: a specifikációnál négy bájttal rövidebb kijelzőinformációs választ érvényesnek fogadott el (A256-W1); egy valódi eszköz mindig a teljes választ küldi, így a szervert ez nem érintette, és a parser most elutasítja a rövidet. Amit nem ellenőriztünk: hogy a sötét kijelző tényleg abból jött-e, hogy a firmware visszaállítja a kártyát, amikor átadja a kernelnek (valószínű, nem megerősített), a Secure Boot-tal való kölcsönhatást, és az x86_64-et valódi gépen (csak emuláció alatt futott). Egy ismert korlát (A256-W2): az auto beállítás nem tudja megkülönböztetni a virtio kártya mellett élő emulált framebuffert egy holttól, ezért ebben az egy konfigurációban a virtio kártyát választja. A meghajtó a hipervizor válaszainak egy parserét adja a kernelhez, ezért ki van kapcsolva, hacsak a konfiguráció nem kéri.

4. A kiadás. Mindez a v0.4.0-ban van, amelyet ugyanazon az estén pre-releaseként tettünk közzé (GitHub-kiadás). Az oldalunk építő oldala ezt kínálja elsőként; a 6-os konfigurációs formátumot igényli, a régebbi sablonok (v0.2.0-tól v0.3.0-ig) pedig elutasítják az új kulcsokat egy olyan üzenettel, amely újabb kiadás használatát kéri. A v0.3.0 korlátai megmaradnak: az aláíró kulcs még mindig próbakulcs, a képek pedig fejlesztői buildek próbatanúsítványokkal. A CI a kiadás commitján csak azután lett zöld, hogy egy jobot újra lefuttattunk (egy kliensteszt egy füstteszt-forgatókönyvben egyszer időtúllépéssel megbukott, másodszorra átment). Amit a közzétett fájlokon ellenőriztünk: a minisign-aláírást, az ellenőrző összegeket, a kernel és az SBOM build-attesztációit, valamint az új kulcsokat tartalmazó sablont (a v0.4.0 elfogadja őket, a v0.3.0 elutasítja). Az új virtio eszközök (konzol, balloon, input, vsock) meghajtója benne van a kiadásban, de alapértelmezetten ki van kapcsolva, és valódi szerveren nem futott.