urMQTT na skutečném ARM64 VPS: žádná obrazovka, žádný hardwarový generátor náhodných čísel a handshake, který byl příliš pomalý

Předchozí text, urMQTT v0.3.0, skončil čtyřmi body v části „Co bude dál": rozhodnutí o veřejném demo brokeru (D1), fuzzing parserů PCI a virtio a test zamčených stránkových tabulek, dialog pro klíč na stránce sestavovače a bare metal. Žádný ze čtyř se v tomto kole nestal a říkáme to jako první. Místo toho jsme udělali to, co celou dobu chybělo: spustili jsme urMQTT na skutečném ARM64 serveru pod KVM a téměř všechno níže pochází z tohoto jednoho stroje. První bod starého seznamu, CI, byl uklizen (dřívější text i poznámky k vydání, které ho označily za červené, jsme opravili)

Poznámka předem zůstává stejná: projekt je pre-alpha, čísla měří kód, testy a konkrétní pokusy na jednom stroji, ne zralost v produkci. Kde číslo nebylo změřeno na cílovém stroji, říkáme to.

Jak to vypadalo v čase

Od minulého textu (3. listopadu ve 02:43) do dneška (4. listopadu ve 03:18) přibylo ve větvi main 29 nových commitů, celkem 244. Jako dřív se projekt staví s Claude Code (commity nesou Co-Authored-By: Claude). Čísla jsou spočítána metodou posledních dvou textů (všechny soubory .rs mimo vendor/ a fuzz/, funkce #[test], nadpisy ## ADR- v docs/DECISIONS.md); na starém commitu dává metoda stejná čísla jako tehdy.

Okamžik	Commit	Čas	Řádků Rustu	Testů	ADR	Commitů
minulý text	f1a7fbc	3. 11., 02:43	115 148	962	133	215
dnes	efddf6e	4. 11., 03:18	117 084	978	134	244

Růst: +1 936 řádků, +16 testů, +1 ADR. Zase málo nového kódu; samotný assembler P-256 (1 509 řádků) je převzatý (vendored) a do počtu řádků se nezapočítává.

Druhý skutečný stroj

Dosud měl projekt jediný skutečný server: Contabo VPS s AMD EPYC (x86_64, KVM), na kterém běželo srovnání výkonu s Mosquittem. ARM64 běžel jen v QEMU, na Macu s hardwarovou akcelerací a v CI bez ní. Nový stroj je netcup VPS 500 ARM G12.5: jádro Neoverse N1 na zhruba 3 GHz, 2 vCPU, 3,9 GiB RAM, virtio disk 64 GiB, QEMU/KVM s firmwarem UEFI, síťová karta virtio. Všechno jsme řídili přes REST API poskytovatele pomocí klienta pro příkazovou řádku: nahrajeme ISO, připojíme ho jako virtuální CD, přepneme zaváděcí zařízení, vypneme a zapneme napájení.

Co jsme na něm udělali, popořadě:

1. Nejdřív snímek původního systému. S UEFI není online snímek možný, takže jsme server vypnuli a pořídili offline snímek.
2. Instalace. Instalátor z ISO zapsal obraz na disk (včetně 30sekundového odpočtu celkem asi 40 sekund) a stroj podle návrhu sám vypnul.
3. Boot z nainstalovaného disku trval asi 35 sekund do TLS handshaku.
4. Zachovaná (retained) zpráva přežila tvrdé vypnutí napájení. Publikovali jsme ji, přes API jsme odpojili napájení, znovu nabootovali a přečetli ji zpět.
5. Nainstalovaný disk, změřený Diagnostickou položkou (jen čtení; test zápisu byl přeskočen, protože nainstalované rozložení nenechává nepřidělené místo, což je záměr): sekvenční čtení 332 MiB/s, náhodná čtení po 4 KiB 22 147 za sekundu s p50 10,4 µs, p90 28,3 µs, p99 671 µs, maximem 9,9 ms (2 000 čtení).

Pět bodů není testovací sada: je to jeden stroj, od každého jeden běh a instalační cesta byla na skutečném disku vyzkoušena jednou. Ukazuje to ale to, že vlastní ovladač virtio-blk v jádře, instalátor i boot fungují na skutečném cloudovém hostu, a ne jen v laboratorním emulátoru.

Žádná obrazovka, takže diagnostika jde po síti

Diagnostická položka z v0.3.0 vykresluje svá čísla do framebufferu. Na tomto serveru konzole poskytovatele hlásí „Display output is not active": virtuální stroj má grafickou kartu virtio, pro kterou nemáme ovladač, a sériový port není vyvedený. Čísla existovala a nikdo je nemohl přečíst.

Řešením je slovo při bootu, diag-serve: stroj provede stejná měření, pak nabootuje jako běžný živý broker a zprávu publikuje jako jediný dokument JSON v zachované zprávě $SYS/diag/report, kterou smí číst jen certifikát operátora. Malý nástroj urmqtt-diag-png z tohoto JSONu vykreslí přehled stejným kódem, který jádro používá na obrazovce (stejné rozložení, stejné písmo 8x8), takže obrázek je obrazovka, kterou by stroj ukázal:

Cestou přibyly na obrazovku dvě věci, protože nám chyběly: takt CPU (čítač cyklů PMU proti časové základně: tady 2,95 až 2,98 GHz; kde je čitelný jen časovač s pevnou frekvencí, stojí tam „neměřitelné" místo toho, abychom frekvenci časovače vydávali za frekvenci CPU) a panel pro generátor náhodných čísel.

Z čeho je generátor náhodných čísel

Panel uvádí, odkud byl generátor inicializován, a testuje čerstvé bajty ze všech hardwarových zdrojů. Na tomto stroji říká:

• virtio-rng: žádné zařízení. RNDR (vlastní instrukce CPU): na tomto CPU není k dispozici.
• Generátor náhodných čísel EFI zavaděče: 8 z 8 hodnot nenulových.
• Záloha založená na jitteru časování CPU (ADR-038): 1 024 vzorků po 64 krocích přes čítač cyklů PMU, odhadem 3 bity na vzorek, 768 bitů připsáno (čtvrtina odhadu, záměrně), zdravotní testy prošly.
• Výstup generátoru, kontrolní test na 4 096 bajtech: 49,6 % jedniček, nejdelší řada 16 bitů. Je to kontrola, že nic nevázne a není zkreslené, ne statistická certifikace.

Generátor na tomto serveru tedy stojí na záloze s jitterem a na tom, co předal firmware. Přesně to popisuje ADR-038 a je to nejslabší inicializace, kterou jádro přijímá. Nenazýváme ji rozbitou: připsané bity jsou nad prahem, který jádro vyžaduje (256), a odhad je konzervativní. Nemůžeme ale ani dokázat, že je stejně dobrá jako hardwarový zdroj. Zda má produkční obraz odmítnout bootovat bez hardwarového zdroje, pokud to operátor výslovně nepovolí, je otevřená otázka pro vlastníka (je v plánu vývoje níže). V praxi je to otázka i pro poskytovatele: hardwarové zařízení náhodných čísel pro virtuální stroj by ji rozhodlo.

Handshake, který byl příliš pomalý

Diagnostická položka také ukázala, kolik na serveru stojí plný oboustranný TLS handshake: 1,08 ms. Téměř všechno je aritmetika s veřejnými klíči: dvě ověření 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 jsme to vyřešili dříve (ADR-130, assembler OpenSSL/Intel: P-256 třikrát až čtyřikrát rychlejší); na ARM64 pořád běžel přenositelný kód z RustCrypto.

Totéž jsme udělali pro ARM64 (ADR-255). Assembler je nistz256 pro ARMv8 z OpenSSL (Apache-2.0), převzatý z ring 0.17.14 se záznamem původu a každé mechanické změny. Na detailech záleželo:

• Jen celá čísla. Assembler nepoužívá registry NEON. Dvě funkce pro výběr z tabulky, které upstream NEON používá, jsme vyřadili a napsali jsme místo nich maskované průchody v konstantním čase v Rustu (stojí nejvýše 1,4 µs z podpisu o 12 µs).
• Ochrana skoků. Jádro se překládá s BTI a autentizací ukazatelů. Každý z 8 exportovaných vstupních bodů má landing pad, ověřeno v disassembly jádra, a šest těch, které ukládají link registr, ho podepisuje.
• Testy, protože je to kryptografie v základu, kterému věříme. Celá sada pro x86_64 nyní běží i na aarch64 Linuxu: aritmetika v tělese a skalárech proti školní referenci, celá tabulka generátoru (2 368 položek) proti RustCrypto, podpisy bit po bitu shodné s podpisy RustCrypto, verdikty ověření, ECDH s body mimo křivku a s nulovými vstupy a testy se známými odpověďmi, které běží při každém bootu přes produkční cesty. Ve čtyřjádrovém virtuálním stroji pod bouří přerušení proběhlo 59 526 kol testů se známými odpověďmi s 0 neshodami.
• Časový test s kontrolou a signál, který byl náš vlastní test. Záměrně děravé násobení dosáhne |t| 482 až 1 755, takže test na této úrovni únik vidí. Na jádru Apple v kontejneru dosáhl ECDH 0,2 až 2,1, podpis 0,5 až 1,9, generování klíče 0,8 až 5,5. Na serverovém jádru arm64 runneru CI dosáhl podpis ECDSA ve třech pokusech |t| = 8,6, 9,1 a 8,3, tedy nad naší mezí 7, zatímco ECDH (3,9) a generování klíče (1,9) na stejném stroji prošly. Výsledek, který se opakuje, není šum, a tak jsme ho zapsali jako otevřený nález (A255-W1) a na pár hodin zvýšili mez pro tento jediný případ na 12, aby build mohl projít. Pak jsme našli příčinu a byl to testovací rámec: případ podepisoval jednu pevnou zprávu, takže řídký klíč dával pokaždé stejný podpis a náhodné klíče pokaždé jiný, a DER kódování opakovaného podpisu je rychlejší (|t| = 49 až 57 jen u kódování). S náhodnou zprávou pro každé měření v obou třídách dosahuje případ na runneru (virtuální stroj Neoverse N2) 1,4 a 1,8, samotné generování nonce 2,7 a 1,1, a mez je zpět na 7. Jedna věc zůstává otevřená (A255-W2): příznak procesoru, který činí časování násobičky na jádrech Arm nezávislé na datech (DIT), není nastaven nikde, ani kernelem, ani kolem volání na straně hostitele. Žádné měření neukazuje rozdíl, ale virtuální stroj runneru tuto funkci nezpřístupňuje, takže ho test ani nemohl ukázat.

Co to přineslo

Nejdřív mikrobenchmark na stroji, kde jsme vyvíjeli, Apple M4 Pro (není to cílový procesor, takže poměry na serveru se mohou lišit), stejným kódem, který volá handshake, před a po:

Operace	před (µs)	po (µs)	poměr
generování klíče	30,8	7,0	4,4x
ECDH P-256	135,2	25,0	5,4x
podpis ECDSA	34,7	11,6	3,0x
ověření ECDSA (neznámý klíč)	147,4	29,1	5,1x
ověření CA (registrovaný vydavatel)	54,2	9,6	5,6x
X25519 (nezměněný kód)	20,4	20,1	1,0x
odhad handshaku (součet výše uvedených)	292	104	2,8x

Pak ostrý test: stejný generátor zátěže, stejná metoda jako v dřívějším textu o výkonu (plný TLS 1.3 handshake s klientským certifikátem, bez obnovení, MQTT CONNECT, server zavírá první), spuštěný ze stroje vzdáleného 9 ms od serveru, proti stejnému netcup VPS, před změnou a po ní. Obraz pro benchmark má limity handshaku uvolněné jako ve srovnání na x86_64; tři opakování, číslo je medián.

Vlákna	před (spoj./s)	po (spoj./s)	poměr	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 část spojení, p50, 32 vláken	18,5 ms	13 ms

Počet plných handshaků za sekundu vzrostl asi 1,55 až 1,7krát, ne třikrát, jak by dala samotná aritmetika. Důvod je prostý a stojí za řeknutí: zrychlili jsme P-256, kdežto X25519 (176 µs), zásobník TCP/IP, vrstva záznamů a MQTT zůstaly beze změny, takže zbývající podíl nabývá na významu (Amdahlův zákon). Dalším kandidátem je X25519.

Pro orientaci vedle serveru x86_64 z dřívějšího textu. Jako závod srovnatelné nejsou: jiné CPU, jiný počet jader (4 proti 2), jiná vzdálenost ke generátoru (15 ms proti 9 ms) a v obou případech sdílený stroj se zátěží, který během běhů ztrácel 5 až 60 % vlastního CPU. Srovnatelný je sloupec s vlastními náklady CPU serveru na handshake:

	Contabo, x86_64 EPYC (asm)	netcup, ARM64 N1 před	netcup, ARM64 N1 po
CPU serveru na handshake	0,26 ms (konzole brokeru)	1,08 ms (Diagnostika)	0,55 ms (Diagnostika, jeden běh, viz níže)
handshaků/s, 32 vláken	169 (bench)	848	1 317
handshaků/s, 64 vláken	278 (bench)	827	1 398
handshaků/s, 128 vláken	413 (bench)	778	1 316

Téhož dne se Diagnostická položka na tomto stroji spustila znovu, s assemblerem (v buildu, který obsahuje i grafický ovladač popsaný v aktualizaci na konci): procesorový čas serveru na jeden oboustranný TLS handshake byl 553 µs oproti 1,08 ms předtím, tedy 1,95krát méně. Ověření ECDSA trvalo 192 µs (předtím 508 µs), podpis 78 µs (141 µs) a X25519 209 µs (176 µs; tento kód je beze změny a takt CPU v tomto běhu byl 2,58 GHz oproti 2,95 až 2,98 GHz v dřívějších, takže jednotlivá čísla na tomto sdíleném stroji kolísají o desítky procent). Je to jeden běh na sdíleném hostiteli. To, že rychlost handshaků vzrostla 1,55 až 1,7krát, zatímco vlastní náklad serveru na handshake klesl 1,95krát, do sebe zapadá: zbytek spojení je stack, generátor a síť. Šum mezi běhy je vidět v surových souborech: každá trojice má jednu odlehlou hodnotu (408 před a 957 po při 32 vláknech), když generátor zátěže přišel o většinu svého CPU ve prospěch jiných virtuálních strojů. Při 128 vláknech je na hranici generátor, ne server, na obou strojích.

Zbytek sady na tomto stroji

Stejná sada jako pro server x86_64 (propustnost, latence, rozesílání, nečinná spojení) proběhla plně proti novému buildu. Pro tyto řádky není žádné „před": běh byl zastaven kvůli sestavení assembleru, takže jde o stav po změně, a assembler se těchto cest nedotýká, kromě handshaků, které spojení otevírají. Jedna skutečnost vysvětluje většinu následujícího: tento virtuální stroj má dva vCPU. Jádro 0 obsluhuje síťovou kartu, rozdělování a veškerou práci s MQTT a TLS, jádro 1 je databázové jádro a po celou dobu bylo vytížené na 2 až 3 %. Server x86_64 měl čtyři vCPU a dvě pracovní jádra. Všechno níže je proto výkon brokeru na jednom jádru.

Nečinná spojení	5 000	10 000	20 000
připojeno	5 000 z 5 000 za 4,3 s	10 000 za 9,3 s	20 000 za 21,2 s
růst haldy jádra na spojení	0,34 KB	0,41 KB	0,43 KB
chyby	0	0	0

(0,50 až 0,66 KB na spojení na serveru x86_64 u commitu H7. Údaj o haldě je $SYS/broker/memory/used minus jeho hodnota před prvním spojením.)

Latence při mírné rychlosti (8 dvojic x 100 zpráv/s, 64 B)	p50	p99
QoS 0	4,0 ms	6,9 ms
QoS 1	4,1 ms	7,0 ms

Rozesílání (1 publikující klient, 64 B)	doručeno za sekundu	p50	p99
100 odběratelů, QoS 0, 50 zpráv/s	5 000 (všechny)	5,9 ms	8,6 ms
100 odběratelů, QoS 1, 50 zpráv/s	5 000 (všechny)	6,3 ms	10,0 ms
1 000 odběratelů, QoS 0, 10 zpráv/s	8 805 z 10 000	207 ms	5,4 s

Záplava, 16 dvojic, publikující klienti tak rychle, jak broker přijímá	publikováno/s	doručeno/s	p50 / p99	ztracená spojení
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 dvojic	130 462	69 411	69 ms / 87 ms	0

Jak to číst. Latence při mírné rychlosti je příspěvek brokeru plus jedna cesta ke generátoru: generátor je tomuto serveru blíž než ten ve srovnání na x86_64, takže oba sloupce latence nejsou srovnatelné. Záplava QoS 0 ukazuje obvyklý obraz přetíženého jednoho jádra: broker přijme 231 000 zpráv za sekundu a doručí 85 000 (zbytek zahodí pravidla zpětného tlaku, k čemu tam jsou) s latencemi v sekundách a žádné spojení nebylo ztraceno; na serveru x86_64 stejný druh záplavy stál několik spojení na běh kvůli 20ms watchdogu (ADR-221 od té doby změnil, jak se tento rozpočet počítá). Řádek s 1 000 odběrateli má stejný charakter jako dřív, chvosty v sekundách, zčásti vlastní generátoru. Čísla z commitu H7 na serveru x86_64 jsou v dřívějším textu; nedáváme je s těmito do jedné tabulky, protože se mezi dvěma měřeními změnil kód na datové cestě (ADR-221 až ADR-224) a stroje se liší ve všem.

Chyby, které jsme našli sami

• Obrázek říkal „žádné disky nenalezeny" a disk ve zprávě byl. První verze urmqtt-diag-png pole disks vůbec nečetla. Vlastník projektu se na obrázek podíval, řekl, že vypadá špatně, a měl pravdu. Opraveno a test nyní čte disk zpět z JSONu.
• Instalátor jsme prohlásili za hotový příliš brzy. Stav serveru přešel na „off" dvakrát: jednou na konci vypnutí a zapnutí napájení a jednou, když instalátor skončil. Náš skript vzal první za druhé, odpojil ISO a nabootoval starý systém, který pak hlásil staré číslo verze a nechal nás hledat v instalátoru chybu, která tam nebyla. Skript nyní nejdřív čeká na čerstvý boot.
• Ztratila se historie postupu. Analýza pro plán vývoje zjistila, že commit milníku S6 nahradil docs/PROGRESS.md (1 763 řádků, milníky M0 až S5) vlastním záznamem o 26 řádcích. Zůstalo to několik dní bez povšimnutí, přestože README tento soubor nazývá „zdrojem pravdy". Obnoveno z historie.
• CI po assembleru padalo na dvou místech. Do tří smoke testů byla zapsaná velikost bootovacího obrazu („10 MiB"), která s větším jádrem vzrostla na 11 MiB; velikost už nepředpokládají. Druhým pádem byl časový test popsaný výše: poprvé vypadal jako šum na sdíleném runneru, a tak jsme test nechali opakovat třikrát; padl ve všech třech pokusech, a tak jsme poznali, že jde o signál, a ten signál se ukázal být naším vlastním testem (podepisoval pokaždé stejnou zprávu). Tu jednu mez jsme na pár hodin zvýšili, řekli jsme to otevřeně a po opravě příčiny jsme ji znovu snížili.
• Dokumentace počítá tři slova při bootu a kód má čtyři (diag-serve) a tabulka milníků v README stále ukazuje práci posledního týdne jako plánovanou. Obojí je v plánu vývoje jako položka k opravě.

Plán vývoje s otázkami

Poprvé existuje plán vývoje: asi 40 položek ve třech fázích (v0.4 zpevnění a provoz; protokol a síť; škálování, další cloudy a bare metal), každá s důvodem převzatým z dokumentu, odhadem práce, rizikem a způsobem ověření, 16 otázek, na které může odpovědět jen vlastník, a seznam toho, co je mimo rozsah. Několik věcí říká jasně: podporováno je jen MQTT 3.1.1, publikování QoS 2 zavře spojení, není IPv6 (poskytovatel dává /64), není WebSocket ani odchozí spojení z brokeru a nejsou ovladače pro síťová a úložná zařízení velkých cloudů.

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

• Procesorový čas na handshake s assemblerem byl na jádru Neoverse změřen jen jednou (553 µs oproti 1,08 ms předtím, při nižším taktu, na sdíleném hostiteli); 1,55 až 1,7krát pochází z rychlosti plných handshaků a 3 až 5krát z jádra Apple. Stranu x86_64 u refaktoringu (kód přesunutý do vlastního souboru) jsme typově zkontrolovali a přeložili, ale její unit testy se nespustily a jádro x86_64 se po ní nespustilo: sady x86_64 nejsou v CI, spouštějí se ručně na VPS u Contabo a u této změny se to ještě neudělalo.
• Konstantní čas: u generování klíče P-256, ECDH a podpisu (klíč a nonce) statistický test nenašel žádnou závislost na řídkém tajemství. Běžel na jádru Apple a na runneru CI (virtuální stroj Neoverse N2), ne na jádru Neoverse N1 od netcup, a nikdy s nastaveným příznakem DIT na serverovém jádru (A255-W2, otevřeno: kernel ho nenastavuje). Pro X25519 ani Ed25519 neběžel. Test černé skříňky omezuje jen to, co dokáže rozlišit při své velikosti vzorku.
• Jeden server, jeden poskytovatel, jedna instalace. Několik výsledků (instalace, výpadek proudu) je jediný běh. Kromě handshaků nemají řádky o výkonu žádné „před" a stroj se dvěma vCPU dává brokeru jedno datové jádro.
• Generátor náhodných čísel na tomto serveru je inicializován z jitteru a z firmwaru, jak je popsáno výše.
• Podpisový klíč je stále zkušební, obrazy vydání jsou vývojové buildy a překlady tohoto textu psala AI a rodilí mluvčí je nezkontrolovali.
• Žádný nezávislý audit, žádný bare metal, žádné IOMMU.

Co bude dál

1. X25519 v assembleru pro ARM64 (je to 176 µs ze zbývajícího handshaku) a opakování měření na handshake na jádru Neoverse víc než jednou.
2. Rozhodnutí o výchozím nastavení generátoru náhodných čísel: odmítnout bootovat bez hardwarového zdroje, pokud operátor neřekne jinak, nebo ponechat zálohu s jitterem a říkat to nahlas.
3. Starý seznam: rozhodnutí o D1, fuzzing parserů PCI a virtio, dialog pro klíč na stránce sestavovače.
4. Z plánu vývoje pro příští vydání: skutečný podpisový klíč a produkční PKI, MQTT 5.0 a QoS 2.

Kód je na github.com/zeljan-alduk/urMQTT; docs/PROGRESS.md zůstává zdrojem pravdy o tom, co funguje, docs/PERFORMANCE.md o tom, co bylo změřeno (oddíl 10 obsahuje čísla k assembleru), docs/AUDIT.md o tom, co není prokázáno. Pre-alpha, jako dřív; hlášení chyb a bezpečnostní hlášení podle SECURITY.md jsou vítána.

Aktualizace, 4. listopadu, později téhož dne. Čtyři věci z hodin po zveřejnění tohoto textu.

1. Chybějící údaj. Diagnostická položka se na serveru u netcup spustila znovu s assemblerem a dala číslo, které chybí v první tabulce: 553 µs CPU serveru na oboustranný TLS handshake oproti 1,08 ms předtím (podrobnosti pod touto tabulkou).
2. Signál u podpisu byl náš test. Příčina časového signálu popsaného výše byla nalezena a opravena v testovacím rámci (podepisoval pokaždé stejnou zprávu); mez je zpět na 7. Otevřené zůstává, že příznak DIT není nastaven nikde (A255-W2).

3. Problém s obrazovkou je vyřešen a je na main. Napsali jsme ovladač pro grafickou kartu virtio (jen 2D, ADR-256), zapínaný konfiguračním klíčem, který je zapečený do obrazu (console.virtio_gpu, ve výchozím stavu off, auto a on vyžadují konfigurační formát 5). S on karta Screen u poskytovatele ukazuje na serveru u netcup Diagnostický panel živě, stejný obrázek jako výše, včetně poslední obrazovky s „press any key". Jeho fuzz cíl našel v první verzi skutečnou chybu: odpověď s informacemi o displeji kratší o čtyři bajty než podle specifikace byla přijata jako platná (A256-W1); skutečné zařízení posílá vždy celou odpověď, takže server zasažen nebyl, a parser nyní tu krátkou odmítá. Co jsme neověřili: že tmavý displej opravdu pocházel z toho, že firmware resetuje kartu při předání kernelu (pravděpodobné, nepotvrzené), součinnost se Secure Boot a x86_64 na skutečném stroji (běželo jen v emulaci). Známé omezení (A256-W2): nastavení auto nedokáže rozlišit živý emulovaný framebuffer vedle karty virtio od mrtvého, takže v této jediné konfiguraci vezme kartu virtio. Ovladač přidává do kernelu parser odpovědí hypervizoru, a proto je vypnutý, pokud to konfigurace nevyžaduje.

4. Vydání. Vše z toho je ve v0.4.0, zveřejněném téhož večera jako pre-release (vydání na GitHubu). Stránka sestavovače na tomto webu ho nabízí jako první; vyžaduje konfigurační formát 6 a starší šablony (v0.2.0 až v0.3.0) nové klíče odmítnou zprávou, která říká, ať se použije novější vydání. Omezení verze v0.3.0 zůstávají: podpisový klíč je stále zkušební a obrazy jsou vývojové buildy s testovacími certifikáty. CI na commitu vydání bylo zelené až poté, co se jedna úloha spustila znovu (klientský test uvnitř smoke scénáře jednou vypršel a napodruhé prošel). Co jsme ověřili na zveřejněných souborech: podpis minisign, kontrolní součty, atestace buildu jádra a SBOM a šablonu s novými klíči (v0.4.0 je přijímá, v0.3.0 je odmítá). Ovladač pro nová zařízení virtio (konzole, balloon, input, vsock) je ve vydání, ale ve výchozím stavu vypnutý a na skutečném serveru neběžel.