urMQTT na pravem ARM64 VPS-ju: brez zaslona, brez strojnega generatorja naključnih števil in z rokovanjem, ki je bilo prepočasno

Prejšnje besedilo, urMQTT v0.3.0, se je končalo s štirimi točkami pod »Kaj sledi«: odločitev o javnem demo posredniku (D1), fuzzing razčlenjevalnikov PCI in virtio ter test za zaklenjene tabele strani, pogovorno okno za ključ na strani graditelja in bare metal. Nobena od štirih v tem krogu ni bila narejena in to povemo najprej. Naredili smo nekaj drugega, kar je ves čas manjkalo: urMQTT smo zagnali na pravem strežniku ARM64 s KVM, in skoraj vse spodaj izvira z tega enega stroja. Prva točka starega seznama, CI, je počiščena (prejšnje besedilo in opombe ob izdaji, ki sta ga imeli za rdečega, sta popravljena).

Opomba vnaprej ostaja enaka: projekt je pred-alfa, številke merijo kodo, teste in določene poskuse na enem stroju, ne zrelosti v produkciji. Kjer številka ni bila izmerjena na ciljnem stroju, to piše.

Kako je to izgledalo v času

Od prejšnjega besedila (3. novembra ob 02:43) do danes (4. novembra ob 03:18) je v main 29 novih commitov, skupaj 244. Kot prej se projekt gradi s Claude Code (commiti nosijo Co-Authored-By: Claude). Številke so izračunane po metodi iz zadnjih dveh besedil (vse datoteke .rs zunaj vendor/ in fuzz/, funkcije #[test], naslovi ## ADR- v docs/DECISIONS.md); metoda na starem commitu da enake številke kot takrat.

Trenutek	Commit	Čas	Vrstic Rusta	Testov	ADR-jev	Commitov
prejšnje besedilo	f1a7fbc	3. nov., 02:43	115 148	962	133	215
danes	efddf6e	4. nov., 03:18	117 084	978	134	244

Rast: +1 936 vrstic, +16 testov, +1 ADR. Spet malo nove kode; sam zbirnik P-256 (1 509 vrstic) je vendoran in ni v številu vrstic.

Drugi pravi stroj

Doslej je imel projekt en pravi strežnik: Contabo VPS z AMD EPYC (x86_64, KVM), uporabljen za primerjavo zmogljivosti z Mosquittom. ARM64 je tekel samo v QEMU, na Macu s strojnim pospeševanjem, v CI-ju pa brez njega. Novi stroj je netcup VPS 500 ARM G12.5: jedro Neoverse N1 s približno 3 GHz, 2 vCPU, 3,9 GiB RAM-a, 64 GiB disk virtio, QEMU/KVM s firmverom UEFI, omrežna kartica virtio. Vse smo vodili prek REST API-ja ponudnika z ukazno vrstičnim odjemalcem: naložimo ISO, ga priklopimo kot virtualni CD, preklopimo zagonsko napravo, ugasnemo in znova vklopimo napajanje.

Kaj smo na njem naredili, po vrsti:

1. Najprej posnetek izvirnega sistema. Spletni posnetek z UEFI ni mogoč, zato smo strežnik ugasnili in naredili posnetek brez povezave.
2. Namestitev. Namestitveni program z ISO-ja je zapisal sliko na disk (vključno s 30-sekundnim odštevanjem skupaj okoli 40 sekund) in stroj sam ugasnil, kot je načrtovano.
3. Zagon z nameščenega diska je do rokovanja TLS trajal okoli 35 sekund.
4. Retained sporočilo je preživelo trd izpad napajanja. Objavili smo ga, napajanje prekinili prek API-ja, znova zagnali in sporočilo prebrali.
5. Nameščeni disk, izmerjen z Diagnostičnim vnosom (samo branje; test pisanja je bil preskočen, ker nameščena razporeditev ne pušča nedodeljenega prostora, kar je namerno): zaporedno branje 332 MiB/s, naključna branja po 4 KiB 22 147 na sekundo s p50 10,4 µs, p90 28,3 µs, p99 671 µs, največ 9,9 ms (2 000 branj).

Pet točk ni testna zbirka: to je en stroj, po en zagon vsake stvari, namestitvena pot pa je bila na pravem disku preizkušena enkrat. Pokaže pa, da jedrov lastni gonilnik virtio-blk, namestitveni program in zagon delujejo na pravem oblačnem gostu in ne samo v laboratorijskem emulatorju.

Brez zaslona, zato diagnostika teče prek omrežja

Diagnostični vnos iz v0.3.0 riše svoje številke na framebufferju. Na tem strežniku konzola ponudnika pravi »Display output is not active«: virtualni stroj ima grafično kartico virtio, za katero nimamo gonilnika, serijska vrata pa niso izpostavljena. Številke so obstajale, a jih nihče ni mogel prebrati.

Rešitev je zagonska beseda diag-serve: stroj opravi enake meritve, nato se zažene kot navaden živi posrednik in objavi poročilo kot en dokument JSON v retained sporočilu $SYS/diag/report, ki ga sme brati samo operaterjevo potrdilo. Majhno orodje urmqtt-diag-png iz tega JSON-a nariše nadzorno ploščo z isto kodo, ki jo uporablja jedro na zaslonu (ista razporeditev in ista pisava 8x8), zato je slika prav tisti zaslon, ki bi ga stroj pokazal:

Na zaslon sta med delom prišli še dve stvari, ker sta nam manjkali: takt CPU-ja (števec ciklov PMU proti časovni osnovi: tu 2,95 do 2,98 GHz; kjer je mogoče brati samo časovnik s stalno hitrostjo, piše »ni merljivo«, namesto da bi se frekvenca časovnika izpisala kot frekvenca CPU-ja) in plošča za generator naključnih števil.

Iz česa je sestavljen generator naključnih števil

Plošča pove, od kod je bil generator zasejan, in preizkusi sveže bajte iz vsakega strojnega vira. Na tem stroju piše:

• virtio-rng: ni naprave. RNDR (ukaz samega CPU-ja): na tem CPU-ju ni na voljo.
• Generator naključnih števil EFI v nalagalniku: 8 od 8 vrednosti različnih od nič.
• Rezervna možnost z nihanjem časovanja CPU-ja (ADR-038): 1 024 vzorcev po 64 korakov prek števca ciklov PMU, ocenjeni 3 biti na vzorec, 768 bitov priznanih (četrtina ocene, po načrtu), zdravstveni testi uspešni.
• Izhod generatorja, test razumnosti nad 4 096 bajti: 49,6 % enic, najdaljše zaporedje 16 bitov. To je preverjanje, da nič ni zataknjeno ali pristransko, ne statistična certifikacija.

Generator na tem strežniku torej temelji na rezervni možnosti z nihanjem in na tem, kar je predal firmver. Natanko to opisuje ADR-038 in to je najšibkejše zasejanje, ki ga jedro sprejme. Ne trdimo, da je pokvarjeno: priznani biti so nad pragom, ki ga jedro zahteva (256), ocenjevalnik pa je konservativen. Prav tako ne moremo dokazati, da je tako dober kot strojni vir. Ali naj produkcijska slika brez strojnega vira zavrne zagon, razen če operater to izrecno dovoli, je odprto vprašanje za lastnika (je v načrtu, spodaj). V praksi je to vprašanje tudi za ponudnika: strojna naprava za naključna števila v virtualnem stroju bi ga rešila.

Rokovanje, ki je bilo prepočasno

Diagnostični vnos je pokazal tudi, koliko na strežniku stane polno vzajemno rokovanje TLS: 1,08 ms. Skoraj vse je aritmetika javnih ključev: dva preverjanja ECDSA P-256 (potrdilo odjemalca in odjemalčev dokaz), vsako okoli 508 µs, X25519 176 µs, en podpis ECDSA 141 µs. Na x86_64 smo to rešili že prej (ADR-130, zbirnik OpenSSL/Intel: P-256 trikrat do štirikrat hitrejši); na ARM64 je še tekla prenosljiva koda RustCrypto.

Isto smo naredili za ARM64 (ADR-255). Zbirnik je OpenSSL-ov ARMv8 nistz256 (Apache-2.0), vzet iz ring 0.17.14 in vendoran z zapisanim izvorom in vsako mehansko spremembo. Kaj je bilo pomembno v podrobnostih:

• Samo cela števila. Zbirnik ne uporablja registrov NEON. Obe funkciji za izbiro iz tabele, ki ju izvorna koda uporablja z NEON, smo opustili in napisali maskirana pregledovanja v Rustu s konstantnim časom (stanejo največ 1,4 µs od 12 µs podpisa).
• Zaščita vej. Jedro je prevedeno z BTI in overjanjem kazalcev. Vsaka od 8 izvoženih vstopnih točk ima pristajalno ploščad (preverjeno v razstavljeni kodi jedra), šest, ki shranijo povezovalni register, pa ga podpiše.
• Testi, ker je to kriptografija v bazi, ki ji zaupamo. Celotna zbirka x86_64 zdaj teče tudi na aarch64 Linuxu: aritmetika polja in skalarjev proti šolski referenci, cela tabela generatorja (2 368 vnosov) proti RustCrypto, podpisi, ki so bit za bitom enaki podpisom RustCrypto, verdikti preverjanja, ECDH z vhodi izven krivulje in z ničlo ter testi znanih odgovorov, ki tečejo ob vsakem zagonu prek produkcijskih poti. V štirijedrnem virtualnem stroju pod nevihto prekinitev je teklo 59 526 krogov znanih odgovorov z 0 neujemanji.
• Časovni test s kontrolo in signal, ki je bil naš lastni test. Namenoma puščajoče množenje doseže |t| od 482 do 1755, zato test uhajanje v tej velikosti vidi. Na jedru Apple v vsebniku je ECDH dosegel 0,2 do 2,1, podpisovanje 0,5 do 1,9, generiranje ključa 0,8 do 5,5. Na strežniškem jedru arm64 tekača CI je podpisovanje ECDSA v treh poskusih doseglo |t| = 8,6, 9,1 in 8,3, nad našo mejo 7, medtem ko sta ECDH (3,9) in generiranje ključa (1,9) na istem stroju prestala. Rezultat, ki se ponovi, ni šum, zato smo ga zapisali kot odprto ugotovitev (A255-W1) in za nekaj ur dvignili mejo za ta en primer na 12, da je zgradba lahko prestala. Nato smo našli vzrok in bilo je preizkusno ogrodje: primer je podpisoval eno fiksno sporočilo, zato je redek ključ vsakič dal isti podpis, naključni ključi pa vsakič drugega, kodiranje DER ponovljenega podpisa pa je hitrejše (|t| = 49 do 57 samo za kodiranje). Z naključnim sporočilom pri vsaki meritvi v obeh razredih primer na tekaču (virtualnem stroju Neoverse N2) doseže 1,4 in 1,8, samo generiranje nonca 2,7 in 1,1, meja pa je spet pri 7. Ena stvar ostaja odprta (A255-W2): procesorska zastavica, ki naredi čas množilnika neodvisen od podatkov na jedrih Arm (DIT), ni nastavljena nikjer, niti v jedru niti okoli klicev na strani gostitelja. Nobena meritev ne kaže razlike, vendar virtualni stroj tekača te zmožnosti ne izpostavi, zato je tudi test ni mogel pokazati.

Kaj je prineslo

Najprej mikroizmerek na stroju, kjer smo razvijali, Apple M4 Pro (ni ciljni CPU, zato so razmerja na strežniku lahko drugačna), z isto kodo, ki jo kliče rokovanje, pred in po:

Operacija	prej (µs)	potem (µs)	razmerje
generiranje ključa	30,8	7,0	4,4x
ECDH P-256	135,2	25,0	5,4x
podpis ECDSA	34,7	11,6	3,0x
preverjanje ECDSA (neznan ključ)	147,4	29,1	5,1x
preverjanje CA (registriran izdajatelj)	54,2	9,6	5,6x
X25519 (nespremenjena koda)	20,4	20,1	1,0x
ocena rokovanja (vsota zgornjih)	292	104	2,8x

Nato prava stvar: isti generator obremenitve, ista metoda kot v prejšnjem besedilu o zmogljivosti (polno rokovanje TLS 1.3 s potrdilom odjemalca, brez nadaljevanja, MQTT CONNECT, strežnik zapre prvi), zagnan s stroja, ki je od strežnika oddaljen 9 ms, proti istemu VPS-ju netcup, pred spremembo in po njej. Slika za merjenje ima sproščene omejitve rokovanj, kot pri primerjavi na x86_64; tri ponovitve, številka je mediana.

Niti	prej (povezav/s)	potem (povezav/s)	razmerje	napake
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
Del povezave za TLS, p50, 32 niti	18,5 ms	13 ms

Polnih rokovanj na sekundo je bilo za približno 1,55 do 1,7-krat več, ne trikrat, kot bi dala sama aritmetika. Razlog je preprost in ga je vredno povedati: pospešili smo P-256, X25519 (176 µs), sklad TCP/IP, plast zapisov in MQTT pa so nespremenjeni, zato delež, ki ostane, pridobi na pomenu (Amdahlov zakon). Naslednji kandidat je X25519.

Za orientacijo ob strežniku x86_64 iz prejšnjega besedila. To ni primerljivo kot tekma: različni CPU-ji, različno število jeder (4 proti 2), različna razdalja do generatorja (15 ms proti 9 ms) in v obeh primerih skupen gostitelj z obremenitvijo, ki je med zagoni izgubil 5 do 60 % lastnega CPU-ja. Primerljiv stolpec je strežnikov lasten strošek CPU-ja na rokovanje:

	Contabo, x86_64 EPYC (asm)	netcup, ARM64 N1 prej	netcup, ARM64 N1 potem
CPU strežnika na rokovanje	0,26 ms (konzola posrednika)	1,08 ms (Diagnostika)	0,55 ms (Diagnostika, en zagon, glej spodaj)
rokovanj/s, 32 niti	169 (bench)	848	1 317
rokovanj/s, 64 niti	278 (bench)	827	1 398
rokovanj/s, 128 niti	413 (bench)	778	1 316

Isti dan se je Diagnostični vnos na tem stroju ponovno zagnal, z zbirnikom (v zgradbi, ki vsebuje tudi gonilnik za grafiko, opisan v posodobitvi na koncu): strežnikov strošek CPU-ja za eno vzajemno rokovanje TLS je bil 553 µs proti 1,08 ms prej, 1,95-krat manj. Preverjanje ECDSA je trajalo 192 µs (prej 508 µs), podpisovanje 78 µs (141 µs), X25519 pa 209 µs (176 µs; ta koda je nespremenjena, ura CPU-ja v tem zagonu pa je bila 2,58 GHz proti 2,95 do 2,98 GHz v prejšnjih, zato se posamezne številke na tem deljenem stroju premikajo za desetine odstotkov). Gre za en zagon, na deljenem gostitelju. To, da je hitrost rokovanj narasla 1,55 do 1,7-krat, strežnikov lasten strošek na rokovanje pa je padel 1,95-krat, gre skupaj: preostanek povezave so sklad, generator in omrežje. Šum med zagoni je viden v surovih datotekah: vsak niz treh ima enega osamelca (408 prej in 957 potem pri 32 nitih), ko je gostitelj z generatorjem večino CPU-ja izgubil drugim virtualnim strojem. Pri 128 nitih je na obeh strojih na meji generator, ne strežnik.

Preostanek zbirke na tem stroju

Ista zbirka kot za strežnik x86_64 (prepustnost, zakasnitev, razpošiljanje, mirujoče povezave) je v celoti stekla proti novi gradnji. Za te vrstice ni »prej«: zagon je bil ustavljen zaradi gradnje zbirnika, zato so stanje po spremembi, zbirnik pa teh poti ne zadeva, razen rokovanj, ki odpirajo povezave. Eno dejstvo pojasni večino spodaj: ta virtualni stroj ima dva vCPU-ja. Jedro 0 opravlja omrežno kartico, razporejanje ter vse delo MQTT in TLS, jedro 1 je jedro baze in je bilo ves čas zasedeno 2 do 3 %. Strežnik x86_64 je imel štiri vCPU-je in dve delovni jedri. Vse spodaj je zato zmogljivost posrednika na enem jedru.

Mirujoče povezave	5 000	10 000	20 000
povezanih	5 000 od 5 000 v 4,3 s	10 000 v 9,3 s	20 000 v 21,2 s
rast kopice jedra na povezavo	0,34 KB	0,41 KB	0,43 KB
napake	0	0	0

(0,50 do 0,66 KB na povezavo na strežniku x86_64 pri commitu H7. Številka kopice je $SYS/broker/memory/used minus njegova vrednost pred prvo povezavo.)

Zakasnitev pri zmerni hitrosti (8 parov x 100 sporočil/s, 64 B)	p50	p99
QoS 0	4,0 ms	6,9 ms
QoS 1	4,1 ms	7,0 ms

Razpošiljanje (1 objavitelj, 64 B)	dostavljeno na sekundo	p50	p99
100 naročnikov, QoS 0, 50 sporočil/s	5 000 (vse)	5,9 ms	8,6 ms
100 naročnikov, QoS 1, 50 sporočil/s	5 000 (vse)	6,3 ms	10,0 ms
1 000 naročnikov, QoS 0, 10 sporočil/s	8 805 od 10 000	207 ms	5,4 s

Poplava, 16 parov, objavitelji tako hitro, kot posrednik sprejema	objavljeno/s	dostavljeno/s	p50 / p99	izgubljene povezave
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 parov	130 462	69 411	69 ms / 87 ms	0

Kako brati. Zakasnitev pri zmerni hitrosti je prispevek posrednika plus ena pot do generatorja: generator je temu strežniku bližje kot tisti pri primerjavi na x86_64, zato stolpca zakasnitev nista primerljiva. Poplava QoS 0 kaže običajno sliko preobremenjenega enega jedra: posrednik sprejme 231 000 sporočil na sekundo in dostavi 85 000 (ostalo zavržejo pravila protitlaka, za kar so tudi namenjena) z zakasnitvami v sekundah, izgubljena pa ni bila nobena povezava; na strežniku x86_64 je enaka poplava na zagon stala več povezav zaradi 20-milisekundnega čuvaja (ADR-221 je od takrat spremenil, kako se ta proračun šteje). Vrstica s 1 000 naročniki ima enak značaj kot prej, repi v sekundah, deloma od samega generatorja. Številke pri commitu H7 na strežniku x86_64 so v prejšnjem besedilu; v isto tabelo jih ne damo, ker se je koda med meritvama v podatkovni poti spremenila (ADR-221 do ADR-224) in se stroja razlikujeta v vsem.

Napake, ki smo jih našli sami

• Slika je pisala »no disks found«, disk pa je bil v poročilu. Prva različica urmqtt-diag-png polja disks sploh ni brala. Lastnik projekta je pogledal sliko, rekel, da je videti narobe, in imel prav. Popravljeno, test zdaj prebere disk nazaj iz JSON-a.
• Namestitev smo razglasili za končano prezgodaj. Stanje strežnika je dvakrat prešlo na »off«: enkrat ob koncu ponovnega vklopa in enkrat, ko je namestitveni program končal. Naša skripta je prvo vzela za drugo, odklopila ISO in zagnala stari sistem, ki je nato poročal staro številko različice in nas poslal iskat napako v namestitvenem programu, ki je ni bilo. Skripta zdaj najprej počaka na svež zagon.
• Zgodovina napredka je bila izgubljena. Analiza za načrt je ugotovila, da je commit za mejnik S6 zamenjal docs/PROGRESS.md (1 763 vrstic, mejniki od M0 do S5) s svojim 26-vrstičnim vnosom. Ostalo je neopaženo več dni, čeprav README to datoteko imenuje »vir resnice«. Obnovljeno iz zgodovine.
• CI je po zbirniku padel na dveh mestih. Trije dimni testi so imeli v sebi zapisano velikost zagonske slike (»10 MiB«), ki je z večjim jedrom zrasla na 11 MiB; velikosti ne predpostavljajo več. Druga napaka je bil zgoraj opisani časovni test: prvič je izgledal kot šum na deljenem tekaču, zato smo test ponovili trikrat; padel je v vseh treh poskusih in tako smo izvedeli, da gre za signal, signal pa se je izkazal za naš lastni test (vsakič je podpisal isto sporočilo). To eno mejo smo za nekaj ur dvignili, to povedali odkrito in jo spet znižali, ko je bil vzrok popravljen.
• Dokumentacija našteva tri zagonske besede, koda jih ima štiri (diag-serve), tabela mejnikov v README pa dela zadnjega tedna še vedno kaže kot načrtovano. Oboje je v načrtu kot točka za popravek.

Načrt, z vprašanji

Prvič obstaja načrt: okoli 40 točk v treh fazah (v0.4 utrjevanje in obratovanje; protokol in omrežje; razširitev, več oblakov in bare metal), vsaka z razlogom iz dokumenta, naporom, tveganjem in načinom preverjanja, 16 vprašanj, na katera lahko odgovori samo lastnik, in seznam tega, kar je zunaj obsega. Nekaj stvari pove naravnost: podprt je samo MQTT 3.1.1, objava QoS 2 zapre povezavo, ni IPv6 (ponudnik dodeli /64), ni WebSocket in ni odhodne povezave posrednika, gonilnikov za omrežne in shrambene naprave velikih oblakov pa ni.

Kaj še ni dokazano

• Strošek CPU-ja na rokovanje z zbirnikom je bil na jedru Neoverse izmerjen le enkrat (553 µs proti 1,08 ms prej, pri nižji uri, na deljenem gostitelju); 1,55 do 1,7-krat izhaja iz hitrosti polnih rokovanj, 3 do 5-krat pa z jedra Apple. Stran x86_64 pri preoblikovanju (koda, premaknjena v svojo datoteko) je bila tipsko preverjena in zgrajena, a njeni enotni testi niso bili zagnani in jedro x86_64 po njej ni bilo zagnano: zbirke x86_64 niso v CI-ju, poganjajo se ročno na Contabo VPS, za to spremembo pa tega še nismo naredili.
• Konstanten čas: pri generiranju ključa P-256, ECDH in podpisovanju (ključ in nonce) statistični test ni našel odvisnosti od redke skrivnosti. Tekel je na jedru Apple in na tekaču CI (virtualnem stroju Neoverse N2), ne na jedru Neoverse N1 pri netcupu, in nikoli z nastavljeno zastavico DIT na strežniškem jedru (A255-W2, odprto: jedro je ne nastavi). Ni tekel za X25519 ali Ed25519. Test črne skrinjice omejuje le to, kar lahko loči pri svoji velikosti vzorca.
• En strežnik, en ponudnik, ena namestitev. Več rezultatov (namestitev, izpad napajanja) je en sam zagon. Razen rokovanj vrstice zmogljivosti nimajo »prej«, stroj z dvema vCPU-jema pa posredniku da eno podatkovno jedro.
• Generator naključnih števil na tem strežniku je zasejan z nihanjem in iz firmvera, kot je opisano zgoraj.
• Podpisni ključ je še vedno preizkusni, slike izdaje so razvojne gradnje, prevode tega besedila pa je napisala AI in jih niso preverili izvorni govorci.
• Neodvisne revizije ni, bare metala ni, IOMMU ni.

Kaj sledi

1. X25519 v zbirniku za ARM64 (to je 176 µs preostalega rokovanja) in ponovitev meritve na rokovanje na jedru Neoverse več kot enkrat.
2. Odločitev o privzeti vrednosti generatorja naključnih števil: zavrniti zagon brez strojnega vira, razen če operater reče drugače, ali obdržati rezervno možnost z nihanjem in to glasno povedati.
3. Stari seznam: odločitev o D1, fuzzing razčlenjevalnikov PCI in virtio, pogovorno okno za ključ na strani graditelja.
4. Iz načrta, za naslednjo izdajo: pravi podpisni ključ in produkcijski PKI, MQTT 5.0 in QoS 2.

Koda je na github.com/zeljan-alduk/urMQTT; docs/PROGRESS.md ostaja vir resnice o tem, kaj deluje, docs/PERFORMANCE.md o tem, kaj je izmerjeno (razdelek 10 ima številke zbirnika), docs/AUDIT.md o tem, kar ni dokazano. Pred-alfa, kot prej; prijave napak in varnostne prijave po navodilih v SECURITY.md so dobrodošle.

Posodobitev, 4. novembra, kasneje istega dne. Štiri stvari iz ur po objavi tega besedila.

1. Manjkajoča številka. Diagnostični vnos se je na strežniku netcup ponovno zagnal z zbirnikom in dal številko, ki manjka v prvi tabeli: 553 µs CPU-ja strežnika na vzajemno rokovanje TLS proti 1,08 ms prej (podrobnosti pod to tabelo).
2. Signal pri podpisovanju je bil naš test. Vzrok zgoraj opisanega časovnega signala je bil najden in popravljen v ogrodju (vsakič je podpisalo isto sporočilo); meja je spet pri 7. Odprto ostaja, da zastavica DIT ni nastavljena nikjer (A255-W2).

3. Težava z zaslonom je rešena in je na main. Napisali smo gonilnik za grafično kartico virtio (samo 2D, ADR-256), ki ga vklopi konfiguracijski ključ, vgrajen v sliko (console.virtio_gpu, privzeto off, auto in on pa potrebujeta obliko konfiguracije 5). Z on zavihek Zaslon pri ponudniku v živo prikazuje nadzorno ploščo Diagnostike na strežniku netcup, isto sliko kot zgoraj, vključno z zadnjim zaslonom s »press any key«. Njegov cilj fuzzinga je v prvi različici našel pravo napako: odgovor z informacijami o zaslonu, krajši za štiri bajte od specifikacije, je bil sprejet kot veljaven (A256-W1); prava naprava vedno pošlje celoten odgovor, zato strežnik ni bil prizadet, razčlenjevalnik pa zdaj krajšega zavrne. Česa nismo preverili: da je temen zaslon res prišel od strojne programske opreme, ki ponastavi kartico ob predaji jedru (verjetno, nepotrjeno), součinkovanja z Secure Boot in x86_64 na pravem stroju (tekel je le pod emulacijo). Znana omejitev (A256-W2): nastavitev auto ne loči delujočega emuliranega framebufferja ob kartici virtio od mrtvega, zato v tej eni konfiguraciji izbere kartico virtio. Gonilnik v jedro doda razčlenjevalnik odgovorov hipervizorja, zato je izklopljen, če konfiguracija ne zahteva drugače.

4. Izdaja. Vse to je v v0.4.0, ki je bila isti večer objavljena kot predizdaja (izdaja na GitHubu). Stran graditelja na tem spletnem mestu jo ponuja prvo; potrebuje obliko konfiguracije 6, starejše predloge (v0.2.0 do v0.3.0) pa nove ključe zavrnejo s sporočilom, naj uporabite novejšo izdajo. Omejitve v0.3.0 ostajajo: podpisni ključ je še vedno preizkusni, slike pa so razvojne gradnje s preizkusnimi certifikati. CI na commitu izdaje je bil zelen šele, ko smo ponovno zagnali eno opravilo (odjemalski test znotraj smoke scenarija je enkrat presegel časovno omejitev, drugič pa je uspel). Kaj smo preverili na objavljenih datotekah: podpis minisign, kontrolne vsote, atestacije gradnje jedra in SBOM ter predlogo z novimi ključi (v0.4.0 jih sprejme, v0.3.0 jih zavrne). Gonilnik za nove naprave virtio (konzola, balon, vhod, vsock) je v izdaji, a je privzeto izklopljen in ni tekel na pravem strežniku.