urMQTT na skutočnom ARM64 VPS: bez obrazovky, bez hardvérového generátora náhodných čísel a s handshakeom, ktorý bol príliš pomalý

Minulý text, urMQTT v0.3.0, skončil štyrmi bodmi pod „Čo bude ďalej": rozhodnutie o verejnom demo brokeri (D1), fuzzing parserov PCI a virtio a test pre uzamknuté stránkové tabuľky, dialóg pre kľúč na stránke zostavovača a bare metal. Žiadny zo štyroch sa v tomto kole nespravil a hovoríme to ako prvé. Spravili sme niečo iné, čo celý čas chýbalo: spustili sme urMQTT na skutočnom serveri ARM64 s KVM a takmer všetko nižšie pochádza z tohto jedného stroja. Prvá položka starého zoznamu, CI, je upratané (skorší text i poznámky k vydaniu, ktoré ho označovali za červené, sú opravené).

Poznámka vopred ostáva rovnaká: projekt je pre-alpha, čísla merajú kód, testy a konkrétne pokusy na jednom stroji, nie zrelosť v produkcii. Kde číslo nebolo namerané na cieľovom stroji, hovorí sa to.

Ako to vyzeralo v čase

Od minulého textu (3. novembra o 02:43) do dneška (4. novembra o 03:18) pribudlo v main 29 nových commitov, spolu 244. Ako predtým, projekt sa stavia s Claude Code (commity nesú Co-Authored-By: Claude). Čísla sú vypočítané metódou z posledných dvoch textov (všetky súbory .rs mimo vendor/ a fuzz/, funkcie #[test], nadpisy ## ADR- v docs/DECISIONS.md); metóda dáva na starom commite rovnaké čísla ako vtedy.

Okamih	Commit	Čas	Riadkov Rustu	Testov	ADR	Commitov
minulý text	f1a7fbc	3. 11., 02:43	115 148	962	133	215
dnes	efddf6e	4. 11., 03:18	117 084	978	134	244

Rast: +1 936 riadkov, +16 testov, +1 ADR. Zasa málo nového kódu; samotný assembler P-256 (1 509 riadkov) je vendorovaný a do počtu riadkov nepatrí.

Druhý skutočný stroj

Doteraz mal projekt jeden skutočný server: Contabo VPS s AMD EPYC (x86_64, KVM), použitý na porovnanie výkonu s Mosquittom. ARM64 bežalo iba v QEMU, na Macu s hardvérovou akceleráciou a v CI bez nej. Nový stroj je netcup VPS 500 ARM G12.5: jadro Neoverse N1 s približne 3 GHz, 2 vCPU, 3,9 GiB RAM, 64 GiB disk virtio, QEMU/KVM s firmvérom UEFI, sieťová karta virtio. Všetko sme riadili cez REST API poskytovateľa príkazovým klientom: nahráme ISO, pripojíme ho ako virtuálne CD, prepneme bootovacie zariadenie, vypneme a znova zapneme napájanie.

Čo sme na ňom robili, v poradí:

1. Najprv snímka pôvodného systému. Online snímka s UEFI nie je možná, preto sme server vypli a urobili offline snímku.
2. Inštalácia. Inštalátor z ISO zapísal obraz na disk (aj s 30-sekundovým odpočítavaním spolu asi 40 sekúnd) a stroj sám vypol, ako je navrhnuté.
3. Štart z nainštalovaného disku trval asi 35 sekúnd po TLS handshake.
4. Uchovaná správa (retained) prežila tvrdý výpadok prúdu. Zverejnili sme ju, prerušili napájanie cez API, znova nabootovali a správu prečítali.
5. Nainštalovaný disk, zmeraný Diagnostickou položkou (iba čítanie; test zápisu sa preskočil, lebo nainštalované rozloženie nenecháva nepridelené miesto, čo je zámer): sekvenčné čítanie 332 MiB/s, náhodné čítania po 4 KiB 22 147 za sekundu s p50 10,4 µs, p90 28,3 µs, p99 671 µs, maximum 9,9 ms (2 000 čítaní).

Päť bodov nie je testovacia sada: je to jeden stroj, po jednom behu každej veci a inštalačná cesta sa na skutočnom disku vyskúšala raz. Ukazuje však, že vlastný ovládač virtio-blk v jadre, inštalátor a boot fungujú na skutočnom cloudovom hosťovi a nielen v laboratórnom emulátore.

Bez obrazovky, takže diagnostika ide cez sieť

Diagnostická položka z v0.3.0 kreslí svoje čísla na framebuffer. Na tomto serveri konzola poskytovateľa hlási „Display output is not active": virtuálny stroj má grafickú kartu virtio, pre ktorú nemáme ovládač, a sériový port nie je vystavený. Čísla existovali a nikto ich nemohol prečítať.

Oprava je bootovacie slovo diag-serve: stroj spraví tie isté merania, potom nabootuje ako normálny živý broker a zverejní správu ako jeden dokument JSON v retained správe $SYS/diag/report, ktorú smie čítať iba certifikát operátora. Malý nástroj urmqtt-diag-png z tohto JSON nakreslí dashboard tým istým kódom, ktorý používa jadro na obrazovke (rovnaké rozloženie a rovnaké písmo 8x8), takže obrázok je presne tá obrazovka, ktorú by stroj ukázal:

Na obrazovku pribudli pri tom ešte dve veci, lebo nám chýbali: takt CPU (počítadlo cyklov PMU oproti časovej základni: tu 2,95 až 2,98 GHz; kde sa dá čítať iba časovač s pevnou frekvenciou, hlási „nemerateľné", namiesto aby frekvenciu časovača vypísal ako frekvenciu CPU) a panel pre generátor náhodných čísel.

Z čoho je zložený generátor náhodných čísel

Panel hovorí, odkiaľ bol generátor zaseedovaný, a testuje čerstvé bajty z každého hardvérového zdroja. Na tomto stroji hovorí:

• virtio-rng: žiadne zariadenie. RNDR (vlastná inštrukcia CPU): na tomto CPU nie je dostupná.
• Generátor náhodných čísel EFI v zavádzači: 8 z 8 hodnôt nenulových.
• Záložná možnosť s kolísaním časovania CPU (ADR-038): 1 024 vzoriek po 64 krokov cez počítadlo cyklov PMU, odhadnuté 3 bity na vzorku, 768 bitov uznaných (štvrtina odhadu, podľa návrhu), zdravotné testy prešli.
• Výstup generátora, test zdravého rozumu nad 4 096 bajtmi: 49,6 % jednotiek, najdlhšia séria 16 bitov. Je to kontrola, že nič nie je zaseknuté ani skreslené, nie štatistická certifikácia.

Generátor na tomto serveri teda stojí na záložnej možnosti s kolísaním a na tom, čo odovzdal firmvér. Presne to opisuje ADR-038 a je to najslabšie seedovanie, ktoré jadro akceptuje. Nehovoríme, že je pokazené: uznané bity sú nad prahom, ktorý jadro vyžaduje (256), a odhadovač je konzervatívny. Rovnako nevieme dokázať, že je také dobré ako hardvérový zdroj. Či má produkčný obraz odmietnuť boot bez hardvérového zdroja, pokiaľ to operátor výslovne nepovolí, je otvorená otázka pre vlastníka (je v pláne, nižšie). V praxi je to otázka aj pre poskytovateľa: hardvérové zariadenie na náhodné čísla vo virtuálnom stroji by ju vyriešilo.

Handshake, ktorý bol príliš pomalý

Diagnostická položka ukázala aj to, koľko na serveri stojí plný obojstranný TLS handshake: 1,08 ms. Takmer všetko je aritmetika verejných kľúčov: dve overenia ECDSA P-256 (certifikát klienta a dôkaz klienta), každé asi 508 µs, X25519 176 µs, jeden podpis ECDSA 141 µs. Na x86_64 sme to vyriešili skôr (ADR-130, assembler OpenSSL/Intel: P-256 trikrát až štyrikrát rýchlejšie); na ARM64 stále bežal prenosný kód RustCrypto.

To isté sme spravili pre ARM64 (ADR-255). Assembler je OpenSSL-ovský ARMv8 nistz256 (Apache-2.0), prevzatý z ring 0.17.14 a vendorovaný so zapísaným pôvodom a každou mechanickou zmenou. Čo bolo dôležité v detailoch:

• Iba celé čísla. Assembler nepoužíva registre NEON. Dve funkcie na výber z tabuľky, ktoré pôvodný zdroj používa s NEON, sme vynechali a napísali sme maskované prehľadávania v Ruste s konštantným časom (stoja najviac 1,4 µs z 12 µs podpisu).
• Ochrana vetvenia. Jadro je preložené s BTI a autentifikáciou ukazovateľov. Každý z 8 exportovaných vstupných bodov má pristávaciu plochu (skontrolované vo výpise disassembly jadra) a šesť, ktoré ukladajú linkovací register, ho podpisuje.
• Testy, lebo je to kryptografia v základe, ktorému veríme. Celá sada x86_64 teraz beží aj na aarch64 Linuxe: aritmetika poľa a skalárov proti školskej referencii, celá tabuľka generátora (2 368 položiek) proti RustCrypto, podpisy bit po bite rovnaké ako v RustCrypto, verdikty overenia, ECDH so vstupmi mimo krivky a s nulou a testy známych odpovedí, ktoré bežia pri každom štarte cez produkčné cesty. V štvorjadrovom virtuálnom stroji pod búrkou prerušení bežalo 59 526 kôl známych odpovedí s 0 nezhodami.
• Časový test s kontrolou a signál, ktorým bol náš vlastný test. Zámerne unikajúce násobenie dosiahne |t| od 482 do 1755, takže test vidí únik v tomto rozsahu. Na jadre Apple v kontajneri dosiahlo ECDH 0,2 až 2,1, podpisovanie 0,5 až 1,9, generovanie kľúča 0,8 až 5,5. Na serverovom jadre arm64 runnera CI dosiahlo podpisovanie ECDSA v troch pokusoch |t| = 8,6, 9,1 a 8,3, nad našou hranicou 7, kým ECDH (3,9) a generovanie kľúča (1,9) na tom istom stroji prešli. Výsledok, ktorý sa opakuje, nie je šum, a tak sme ho zapísali ako otvorené zistenie (A255-W1) a na niekoľko hodín zvýšili hranicu pre tento jeden prípad na 12, aby build mohol prejsť. Potom sme našli príčinu a bol ňou testovací rámec: prípad podpisoval jednu pevnú správu, takže riedky kľúč dával zakaždým rovnaký podpis a náhodné kľúče zakaždým iný, a DER kódovanie opakovaného podpisu je rýchlejšie (|t| od 49 do 57 len pre kódovanie). S náhodnou správou pri každom meraní v oboch triedach prípad na runneri (virtuálnom stroji Neoverse N2) dosahuje 1,4 a 1,8, samotné generovanie nonce 2,7 a 1,1 a hranica je späť na 7. Jedna vec zostáva otvorená (A255-W2): príznak procesora, ktorý robí čas násobičky nezávislým od dát na jadrách Arm (DIT), nie je nastavený nikde, ani jadrom, ani okolo volaní na strane hostiteľa. Žiadne meranie nepreukazuje rozdiel, ale virtuálny stroj runnera túto funkciu nezverejňuje, takže ju nemohol preukázať ani test.

Čo to prinieslo

Najprv mikrobenchmark na stroji, kde sme vyvíjali, Apple M4 Pro (nie je to cieľový CPU, takže pomery na serveri sa môžu líšiť), s tým istým kódom, ktorý volá handshake, pred a po:

Operácia	pred (µs)	po (µs)	pomer
generovanie kľúča	30,8	7,0	4,4x
ECDH P-256	135,2	25,0	5,4x
podpis ECDSA	34,7	11,6	3,0x
overenie ECDSA (neznámy kľúč)	147,4	29,1	5,1x
overenie CA (registrovaný vydavateľ)	54,2	9,6	5,6x
X25519 (nezmenený kód)	20,4	20,1	1,0x
odhad handshaku (súčet vyššie)	292	104	2,8x

Potom skutočná vec: ten istý generátor záťaže, tá istá metóda ako v skoršom texte o výkone (plný TLS 1.3 handshake s certifikátom klienta, bez obnovenia, MQTT CONNECT, server zatvára ako prvý), spustený zo stroja vzdialeného od servera 9 ms, proti tomu istému netcup VPS, pred zmenou a po nej. Obraz na benchmark má uvoľnené limity handshakeov, ako pri porovnaní na x86_64; tri opakovania, číslo je medián.

Vlákna	pred (spoj./s)	po (spoj./s)	pomer	chyby
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
TLS časť spojenia, p50, 32 vlákien	18,5 ms	13 ms

Plných handshakeov za sekundu pribudlo asi 1,55 až 1,7-krát, nie trikrát, ako by dala samotná aritmetika. Dôvod je jednoduchý a stojí za to ho povedať: zrýchlili sme P-256, no X25519 (176 µs), zásobník TCP/IP, vrstva záznamov a MQTT sú nezmenené, takže zvyšný podiel nadobúda na význame (Amdahlov zákon). Ďalší kandidát je X25519.

Pre orientáciu popri x86_64 serveri zo skoršieho textu. Toto nie je porovnateľné ako preteky: iné CPU, iný počet jadier (4 oproti 2), iná vzdialenosť ku generátoru (15 ms oproti 9 ms) a v oboch prípadoch zdieľaný hostiteľ so záťažou, ktorý počas behov prišiel o 5 až 60 % vlastného CPU. Porovnateľný stĺpec je vlastná cena CPU servera na handshake:

	Contabo, x86_64 EPYC (asm)	netcup, ARM64 N1 pred	netcup, ARM64 N1 po
CPU servera na handshake	0,26 ms (konzola brokera)	1,08 ms (Diagnostika)	0,55 ms (Diagnostika, jeden beh, pozri nižšie)
handshakeov/s, 32 vlákien	169 (bench)	848	1 317
handshakeov/s, 64 vlákien	278 (bench)	827	1 398
handshakeov/s, 128 vlákien	413 (bench)	778	1 316

V ten istý deň sa Diagnostická položka na tomto stroji spustila znova, s assemblerom (v builde, ktorý obsahuje aj grafický ovládač opísaný v aktualizácii na konci): CPU náklad servera na jeden obojstranný TLS handshake bol 553 µs oproti 1,08 ms predtým, 1,95-krát menej. Overenie ECDSA trvalo 192 µs (predtým 508 µs), podpisovanie 78 µs (141 µs) a X25519 209 µs (176 µs; tento kód je nezmenený a takt CPU v tomto behu bol 2,58 GHz oproti 2,95 až 2,98 GHz v predchádzajúcich, takže jednotlivé čísla na tomto zdieľanom stroji sa hýbu o desiatky percent). Je to jeden beh, na zdieľanom hostiteľovi. To, že rýchlosť handshakeov vzrástla 1,55 až 1,7-krát, kým vlastný náklad servera na handshake klesol 1,95-krát, do seba zapadá: zvyšok spojenia je stack, generátor a sieť. Šum medzi behmi je viditeľný v surových súboroch: každá trojica má jeden odľahlý výsledok (408 pred a 957 po pri 32 vláknach), keď hostiteľ s generátorom stratil väčšinu CPU v prospech iných virtuálnych strojov. Pri 128 vláknach je na oboch strojoch na hranici generátor, nie server.

Zvyšok sady na tomto stroji

Tá istá sada ako pre x86_64 server (priepustnosť, latencia, rozosielanie, nečinné spojenia) bežala v plnom rozsahu proti novému buildu. Pre tieto riadky neexistuje „pred": beh bol zastavený kvôli zostaveniu assemblera, takže sú stavom po zmene, a assembler sa týchto ciest nedotýka, okrem handshakeov, ktoré otvárajú spojenia. Jeden fakt vysvetľuje väčšinu nasledujúceho: tento virtuálny stroj má dva vCPU. Jadro 0 robí sieťovú kartu, rozdeľovanie a všetku prácu MQTT a TLS, jadro 1 je databázové jadro a bolo po celý čas vyťažené na 2 až 3 %. Server x86_64 mal štyri vCPU a dve pracovné jadrá. Všetko nižšie je preto výkon brokera na jednom jadre.

Nečinné spojenia	5 000	10 000	20 000
pripojených	5 000 z 5 000 za 4,3 s	10 000 za 9,3 s	20 000 za 21,2 s
rast haldy jadra na spojenie	0,34 KB	0,41 KB	0,43 KB
chyby	0	0	0

(0,50 až 0,66 KB na spojenie na serveri x86_64 pri commite H7. Číslo haldy je $SYS/broker/memory/used mínus jeho hodnota pred prvým spojením.)

Latencia pri miernej rýchlosti (8 párov x 100 správ/s, 64 B)	p50	p99
QoS 0	4,0 ms	6,9 ms
QoS 1	4,1 ms	7,0 ms

Rozosielanie (1 publisher, 64 B)	doručené za sekundu	p50	p99
100 odberateľov, QoS 0, 50 správ/s	5 000 (všetky)	5,9 ms	8,6 ms
100 odberateľov, QoS 1, 50 správ/s	5 000 (všetky)	6,3 ms	10,0 ms
1 000 odberateľov, QoS 0, 10 správ/s	8 805 z 10 000	207 ms	5,4 s

Záplava, 16 párov, publisheri tak rýchlo, ako broker berie	zverejnené/s	doručené/s	p50 / p99	stratené spojenia
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árov	130 462	69 411	69 ms / 87 ms	0

Ako to čítať. Latencia pri miernej rýchlosti je príspevok brokera plus jedna cesta ku generátoru: generátor je tomuto serveru bližšie ako ten pri porovnaní na x86_64, takže stĺpce latencie nie sú porovnateľné. Záplava QoS 0 ukazuje obvyklý obraz preťaženého jedného jadra: broker prijme 231 000 správ za sekundu a doručí 85 000 (zvyšok zahodia pravidlá spätného tlaku, na čo slúžia) s latenciami v sekundách a nestratilo sa žiadne spojenie; na serveri x86_64 taká istá záplava stála za beh niekoľko spojení kvôli 20-milisekundovému strážnemu psovi (ADR-221 odvtedy zmenil, ako sa tento rozpočet počíta). Riadok s 1 000 odberateľmi má rovnaký charakter ako predtým, chvosty v sekundách, sčasti od samotného generátora. Čísla pri commite H7 na serveri x86_64 sú v skoršom texte; do jednej tabuľky ich nedávame, lebo sa kód medzi dvoma meraniami v dátovej ceste zmenil (ADR-221 až ADR-224) a stroje sa líšia vo všetkom.

Chyby, ktoré sme našli sami

• Obrázok hlásil „no disks found" a disk bol v správe. Prvá verzia urmqtt-diag-png pole disks vôbec nečítala. Vlastník projektu sa pozrel na obrázok, povedal, že vyzerá zle, a mal pravdu. Opravené a test teraz číta disk späť z JSON.
• Inštalátor sme vyhlásili za hotový priskoro. Stav servera prešiel dvakrát na „off": raz na konci cyklu napájania a raz, keď inštalátor skončil. Náš skript vzal prvé za druhé, odpojil ISO a nabootoval starý systém, ktorý potom hlásil staré číslo verzie a poslal nás hľadať chybu v inštalátore, ktorá tam nebola. Skript teraz najprv čaká na čerstvý boot.
• História postupu sa stratila. Analýza pre plán zistila, že commit pre míľnik S6 nahradil docs/PROGRESS.md (1 763 riadkov, míľniky M0 až S5) vlastným 26-riadkovým záznamom. Zostalo to dni nepovšimnuté, hoci README tento súbor nazýva „zdrojom pravdy". Obnovené z histórie.
• CI po assembleri zlyhalo na dvoch miestach. Tri smoke testy mali zapísanú veľkosť bootovacieho obrazu („10 MiB"), ktorá s väčším jadrom vyrástla na 11 MiB; veľkosť už nepredpokladajú. Druhým zlyhaním bol vyššie opísaný časový test: prvýkrát to vyzeralo ako šum na zdieľanom runneri, a tak sme test nechali opakovať trikrát; zlyhal vo všetkých troch pokusoch, a tak sme zistili, že ide o signál, a signálom sa ukázal náš vlastný test (podpisoval zakaždým tú istú správu). Túto jednu hranicu sme na niekoľko hodín zvýšili, povedali sme to otvorene a keď sa príčina opravila, znížili sme ju späť.
• Dokumentácia počíta tri bootovacie slová a kód má štyri (diag-serve) a tabuľka míľnikov v README stále ukazuje prácu posledného týždňa ako plánovanú. Oboje je v pláne ako položky na opravu.

Plán, s otázkami

Prvýkrát existuje plán: asi 40 položiek v troch fázach (v0.4 spevnenie a prevádzka; protokol a sieť; škálovanie, viac cloudov a bare metal), každá s dôvodom z dokumentu, náročnosťou, rizikom a spôsobom overenia, 16 otázok, na ktoré môže odpovedať iba vlastník, a zoznam toho, čo je mimo rozsahu. Niekoľko vecí hovorí priamo: podporované je iba MQTT 3.1.1, publikácia QoS 2 zatvorí spojenie, nie je IPv6 (poskytovateľ dáva /64), nie je WebSocket ani odchádzajúce spojenie brokera a nie sú ovládače pre sieťové a úložné zariadenia veľkých cloudov.

Čo ešte nie je dokázané

• CPU náklad na handshake s assemblerom sa na jadre Neoverse meral len raz (553 µs oproti 1,08 ms predtým, pri nižšom takte, na zdieľanom hostiteľovi); 1,55 až 1,7-krát pochádza z rýchlosti plných handshakeov a 3 až 5-krát z jadra Apple. Strana x86_64 refaktoringu (kód presunutý do vlastného súboru) bola typovo skontrolovaná a zostavená, ale jej unit testy sa nespúšťali a jadro x86_64 sa po nej nenaštartovalo: sady x86_64 nie sú v CI, spúšťajú sa ručne na Contabo VPS a pre túto zmenu sa to ešte nespravilo.
• Konštantný čas: pri generovaní kľúča P-256, ECDH a podpisovaní (kľúč a nonce) štatistický test nenašiel závislosť od riedkeho tajomstva. Bežal na jadre Apple a na runneri CI (virtuálnom stroji Neoverse N2), nie na jadre Neoverse N1 u netcupu, a nikdy s nastaveným príznakom DIT na serverovom jadre (A255-W2, otvorené: jadro ho nenastavuje). Nebežal pre X25519 ani Ed25519. Test čiernej skrinky ohraničuje len to, čo dokáže rozlíšiť pri svojej veľkosti vzorky.
• Jeden server, jeden poskytovateľ, jedna inštalácia. Viaceré výsledky (inštalácia, výpadok prúdu) sú jediný beh. Okrem handshakeov riadky výkonu nemajú „pred" a stroj s dvoma vCPU dáva brokerovi jedno dátové jadro.
• Generátor náhodných čísel na tomto serveri je seedovaný z kolísania a z firmvéru, ako je opísané vyššie.
• Podpisový kľúč je stále skúšobný, obrazy vydania sú vývojové buildy a preklady tohto textu napísala AI a rodení hovoriaci ich nekontrolovali.
• Žiadny nezávislý audit, žiadny bare metal, žiadne IOMMU.

Čo bude ďalej

1. X25519 v assembleri pre ARM64 (je to 176 µs zvyšného handshaku) a zopakovanie merania na handshake na jadre Neoverse viac než raz.
2. Rozhodnutie o predvolenom nastavení generátora náhodných čísel: odmietnuť boot bez hardvérového zdroja, pokiaľ operátor nepovie inak, alebo ponechať záložnú možnosť s kolísaním a povedať to nahlas.
3. Starý zoznam: rozhodnutie o D1, fuzzing parserov PCI a virtio, dialóg pre kľúč na stránke zostavovača.
4. Z plánu, pre ďalšie vydanie: skutočný podpisový kľúč a produkčná PKI, MQTT 5.0 a QoS 2.

Kód je na github.com/zeljan-alduk/urMQTT; docs/PROGRESS.md ostáva zdrojom pravdy o tom, čo funguje, docs/PERFORMANCE.md o tom, čo bolo zmerané (oddiel 10 má čísla assemblera), docs/AUDIT.md o tom, čo nie je dokázané. Pre-alpha, ako predtým; hlásenia chýb a bezpečnostné hlásenia podľa pokynov v SECURITY.md sú vítané.

Aktualizácia, 4. novembra, neskôr v ten istý deň. Štyri veci z hodín po zverejnení tohto textu.

1. Chýbajúce číslo. Diagnostická položka sa na serveri netcup znova spustila s assemblerom a dala číslo, ktoré chýba v prvej tabuľke: 553 µs CPU servera na obojstranný TLS handshake oproti 1,08 ms predtým (podrobnosti pod touto tabuľkou).
2. Signál pri podpisovaní bol náš test. Príčina vyššie opísaného časového signálu sa našla a opravila v testovacom ráme (podpisoval zakaždým tú istú správu); hranica je späť na 7. Otvorené zostáva, že príznak DIT nie je nastavený nikde (A255-W2).

3. Problém s obrazovkou je vyriešený a je na main. Napísali sme ovládač pre grafickú kartu virtio (iba 2D, ADR-256), ktorý zapína konfiguračný kľúč zapečený do obrazu (console.virtio_gpu, predvolene off, a auto a on potrebujú formát konfigurácie 5). S on karta Obrazovka u poskytovateľa ukazuje dashboard Diagnostiky naživo na serveri netcup, ten istý obraz ako vyššie, vrátane poslednej obrazovky s „press any key". Jeho fuzz cieľ našiel v prvej verzii skutočnú chybu: odpoveď s informáciami o displeji, o štyri bajty kratšia, než určuje špecifikácia, sa prijala ako platná (A256-W1); skutočné zariadenie vždy pošle celú odpoveď, takže server nebol dotknutý, a parser teraz kratšiu odmietne. Čo sme neoverili: že tmavý displej naozaj vznikol tým, že firmvér pri odovzdaní jadru resetuje kartu (pravdepodobné, nepotvrdené), súčinnosť so Secure Boot a x86_64 na skutočnom stroji (bežal len pod emuláciou). Známe obmedzenie (A256-W2): nastavenie auto nerozlíši živý emulovaný framebuffer popri karte virtio od mŕtveho, a tak v tejto jednej konfigurácii vezme kartu virtio. Ovládač pridáva do jadra parser odpovedí hypervízora, a preto je vypnutý, pokiaľ si ho konfigurácia nevyžiada.

4. Vydanie. Všetko toto je vo v0.4.0, zverejnenej v ten istý večer ako predbežné vydanie (vydanie na GitHube). Stránka zostavovača na tomto webe ju ponúka ako prvú; potrebuje formát konfigurácie 6 a staršie šablóny (v0.2.0 až v0.3.0) nové kľúče odmietnu správou, ktorá hovorí, aby sa použilo novšie vydanie. Obmedzenia v0.3.0 ostávajú: podpisový kľúč je stále skúšobný a obrazy sú vývojové buildy so skúšobnými certifikátmi. CI na commite vydania bolo zelené až po tom, čo sa jedna úloha spustila znova (klientsky test v smoke scenári raz vypršal a na druhý raz prešiel). Čo sme overili na zverejnených súboroch: podpis minisign, kontrolné súčty, atestácie zostavenia jadra a SBOM a šablónu s novými kľúčami (v0.4.0 ich prijme, v0.3.0 ich odmietne). Ovládač pre nové zariadenia virtio (konzola, balón, vstup, vsock) je vo vydaní, ale predvolene vypnutý a na skutočnom serveri nebežal.