urMQTT na pravom ARM64 VPS-u: bez ekrana, bez sklopovskog generatora slučajnih brojeva i s prespornim handshakeom

Prethodni tekst, urMQTT v0.3.0, završio je s četiri stavke pod "Što slijedi": odluka o javnom demo brokeru (D1), fuzzing PCI i virtio parsera uz test za zaključane tablice stranica, dijalog za ključ na stranici graditelja i bare metal. Nijedna od te četiri nije napravljena u ovom krugu, i to kažemo prvo. Napravili smo ono što je cijelo vrijeme nedostajalo: pokrenuli smo urMQTT na pravom ARM64 poslužitelju pod KVM-om, i gotovo sve u nastavku potječe s tog jednog stroja. Prva stavka starog popisa, CI, je počišćena (raniji tekst i napomene uz izdanje koji su ga navodili kao crven ispravljeni su)

Napomena unaprijed ostaje ista: projekt je pred-alfa, a brojke mjere kod, testove i određene pokuse na jednom stroju, ne zrelost u produkciji. Gdje neka brojka nije izmjerena na ciljnom stroju, to piše.

Kako je to izgledalo u vremenu

Od prošlog teksta (3.11. u 02:43) do danas (4.11. u 03:18) u grani main je 29 novih commitova, ukupno 244. Kao i prije, projekt se gradi uz Claude Code (commitovi nose Co-Authored-By: Claude). Brojke su izračunate metodom iz prošla dva teksta (svi .rs fajlovi izvan vendor/ i fuzz/, #[test] funkcije, naslovi ## ADR- u docs/DECISIONS.md); ta metoda na starom commitu daje iste brojke kao tada.

Trenutak	Commit	Vrijeme	Rust redaka	Testova	ADR-ova	Commitova
prošli tekst	f1a7fbc	3.11. 02:43	115 148	962	133	215
danas	efddf6e	4.11. 03:18	117 084	978	134	244

Rast: +1 936 redaka, +16 testova, +1 ADR. Opet malo novog koda; sam P-256 assembly (1 509 redaka) je vendored (preuzet u projekt) i ne ulazi u brojku redaka.

Drugi pravi stroj

Do sada je projekt imao jedan pravi poslužitelj: Contabo VPS s AMD EPYC-om (x86_64, KVM), korišten za usporedbu performansi s Mosquittom. ARM64 se vrtio samo u QEMU-u, sa sklopovskim ubrzanjem na Macu i bez njega u CI-ju. Novi stroj je netcup VPS 500 ARM G12.5: jezgra Neoverse N1 na oko 3 GHz, 2 vCPU-a, 3,9 GiB RAM-a, virtio disk od 64 GiB, QEMU/KVM s UEFI firmwareom, virtio mrežna kartica. Sve smo vodili preko REST API-ja pružatelja, naredbenim klijentom: učitamo ISO, priključimo ga kao virtualni CD, promijenimo uređaj za pokretanje, ugasimo i ponovno upalimo stroj.

Što smo na njemu napravili, redom:

1. Prvo snimka izvornog sustava. Snimka u radu nije moguća s UEFI-jem, pa je poslužitelj ugašen i napravljena je snimka u ugašenom stanju.
2. Instalacija. Instalacijski program s ISO-a upisao je sliku na disk (zajedno s odbrojavanjem od 30 sekundi, ukupno oko 40 sekundi) i sam ugasio stroj, kako je predviđeno.
3. Pokretanje s instaliranog diska do TLS handshakea trajalo je oko 35 sekundi.
4. Zadržana poruka (retained) preživjela je tvrdi prekid napajanja. Objavili smo je, prekinuli napajanje preko API-ja, ponovno pokrenuli stroj i pročitali je natrag.
5. Instalirani disk, izmjeren Dijagnostičkim unosom (samo čitanje; test pisanja je preskočen jer instalirani raspored ne ostavlja nedodijeljen prostor, što je namjerno): sekvencijalno čitanje 332 MiB/s, nasumična čitanja od 4 KiB 22 147 u sekundi uz p50 10,4 µs, p90 28,3 µs, p99 671 µs, maksimum 9,9 ms (2 000 čitanja).

Pet stavki nije testni paket: ovo je jedan stroj, po jedan pokus svake vrste, a put instalacije isproban je jednom na pravom disku. Ono što pokazuje jest da kernelov vlastiti virtio-blk driver, instalacijski program i pokretanje rade na pravom cloud gostu, a ne samo u laboratorijskom emulatoru.

Nema ekrana, pa dijagnostika ide preko mreže

Dijagnostički unos iz v0.3.0 crta svoje brojke na framebufferu. Na ovom poslužitelju konzola pružatelja kaže "Display output is not active": virtualni stroj ima virtio grafičku karticu za koju nemamo driver, a serijski port nije izložen. Brojke su postojale, a nitko ih nije mogao pročitati.

Rješenje je riječ za pokretanje, diag-serve: stroj napravi ista mjerenja, pa se pokrene kao običan live broker i objavi izvještaj kao jedan JSON dokument u zadržanoj poruci $SYS/diag/report, koju smije čitati samo certifikat operatora. Mali alat, urmqtt-diag-png, iz tog JSON-a crta nadzornu ploču istim kodom koji kernel koristi na ekranu (isti raspored i isti font 8x8), pa je slika upravo ekran koji bi stroj prikazao:

Usput su na ekran dodane dvije stvari koje smo propustili: takt procesora (brojač ciklusa PMU-a naspram vremenske baze: ovdje 2,95 do 2,98 GHz; gdje se može čitati samo mjerač s fiksnom frekvencijom, piše "not measurable" umjesto da se frekvencija mjerača ispiše kao frekvencija procesora) i ploča za generator slučajnih brojeva.

Od čega je sastavljen generator slučajnih brojeva

Ploča navodi odakle je generator inicijaliziran (seeded) i testira svježe bajtove iz svakog sklopovskog izvora. Na ovom stroju piše:

• virtio-rng: nema uređaja. RNDR (vlastita instrukcija procesora): nije dostupna na ovom procesoru.
• EFI generator slučajnih brojeva bootloadera: 8 od 8 vrijednosti različito od nule.
• Pričuva na temelju jittera vremena procesora (ADR-038): 1 024 uzorka od po 64 koraka preko brojača ciklusa PMU-a, procijenjeno 3 bita po uzorku, pripisano 768 bita (četvrtina procjene, namjerno), zdravstveni testovi prošli.
• Izlaz generatora, provjera ispravnosti nad 4 096 bajtova: 49,6 % jedinica, najdulji niz 16 bita. To je provjera da ništa nije zaglavljeno ni pristrano, ne statistička certifikacija.

Dakle, generator na ovom poslužitelju počiva na pričuvi s jitterom i na onome što je predao firmware. To je upravo ono što opisuje ADR-038, i to je najslabije inicijaliziranje koje kernel prihvaća. Ne tvrdimo da je pokvareno: pripisani biti iznad su praga koji kernel traži (256), a procjenitelj je konzervativan. Ne možemo ni dokazati da je jednako dobro kao sklopovski izvor. Treba li produkcijska slika odbiti pokretanje bez sklopovskog izvora osim ako operator to izričito dopusti, otvoreno je pitanje za vlasnika projekta (nalazi se u roadmapu, niže). U praksi je to pitanje i za pružatelja: sklopovski uređaj za slučajne brojeve u virtualnom stroju riješio bi ga.

Prespor handshake

Dijagnostički unos pokazao je i koliko puni uzajamni TLS handshake košta na poslužitelju: 1,08 ms. Gotovo sve je aritmetika javnih ključeva: dvije ECDSA P-256 provjere (certifikat klijenta i dokaz klijenta), po oko 508 µs, X25519 176 µs, jedan ECDSA potpis 141 µs. Na x86_64 smo to ranije riješili (ADR-130, OpenSSL/Intel assembly: P-256 tri do četiri puta brži); na ARM64 je i dalje radio prenosivi RustCrypto kod.

Isto smo napravili za ARM64 (ADR-255). Assembly je OpenSSL-ov ARMv8 nistz256 (Apache-2.0), preuzet iz ring 0.17.14 i vendored (preuzet u projekt) uz zapisano podrijetlo i svaku mehaničku promjenu. Što je bilo važno u detaljima:

• Samo cijeli brojevi. Assembly ne koristi NEON registre. Dvije funkcije za odabir iz tablice koje izvorni kod ipak koristi s NEON-om izbacili smo i napisali konstantnovremenske maskirane prolaze u Rustu (koštaju najviše 1,4 µs od potpisa od 12 µs).
• Zaštita grananja. Kernel je preveden s BTI-jem i autentikacijom pokazivača. Svaka od 8 izvezenih ulaznih točaka ima landing pad, provjeren u disassembly-ju kernela, a šest onih koje spremaju link registar potpisuje ga.
• Testovi, jer je ovo kriptografija u bazi kojoj vjerujemo. Cijeli x86_64 paket sada se vrti i na aarch64 Linuxu: aritmetika polja i skalara naspram školske referentne implementacije, cijela tablica generatora (2 368 unosa) naspram RustCrypta, potpisi bit po bit jednaki RustCryptovima, presude provjere, ECDH s ulazima izvan krivulje i nultim ulazima, te testovi s poznatim odgovorom koji se vrte pri svakom pokretanju kroz produkcijske putove. U virtualnom stroju s četiri jezgre pod olujom prekida izvedeno je 59 526 rundi testova s poznatim odgovorom, uz 0 nepodudaranja.
• Test vremena izvođenja s kontrolom i signal koji je bio naš vlastiti test. Namjerno propusno množenje daje |t| od 482 do 1 755, pa test vidi curenje na ovoj skali. Na Appleovoj jezgri u kontejneru ECDH je dao 0,2 do 2,1, potpisivanje 0,5 do 1,9, generiranje ključa 0,8 do 5,5. Na jezgri arm64 poslužitelja CI runnera potpisivanje ECDSA dalo je |t| = 8,6, 9,1 i 8,3 u tri pokušaja, iznad naše granice od 7, dok su ECDH (3,9) i generiranje ključa (1,9) na istom stroju prošli. Rezultat koji se ponavlja nije šum, pa smo ga upisali kao otvoreni nalaz (A255-W1) i nekoliko sati podigli granicu za taj jedan slučaj na 12 da izgradnja može proći. Zatim smo našli uzrok, i bio je to testni okvir (harness): slučaj je potpisivao jednu fiksnu poruku, pa je rijedak ključ svaki put davao isti potpis, a nasumični ključevi svaki put drugi, a DER kodiranje ponovljenog potpisa je brže (|t| = 49 do 57 samo za kodiranje). Uz nasumičnu poruku po mjerenju u obje klase slučaj na runneru daje 1,4 i 1,8 (virtualni stroj Neoverse N2), samo generiranje noncea 2,7 i 1,1, a granica je opet 7. Jedna stvar ostaje otvorena (A255-W2): zastavica procesora koja čini vrijeme množila neovisnim o podacima na jezgrama Arm (DIT) nigdje nije postavljena, ni u kernelu ni oko poziva na strani domaćina. Nijedno mjerenje ne pokazuje razliku, ali virtualni stroj runnera ne izlaže tu mogućnost, pa ni test to nije mogao pokazati.

Što je dobiveno

Prvo mikrobenchmark na stroju na kojem smo razvijali, Apple M4 Pro (nije ciljni procesor, pa omjeri na poslužitelju mogu biti drukčiji), isti kod koji handshake poziva, prije i poslije:

Operacija	prije (µs)	poslije (µs)	omjer
generiranje ključa	30,8	7,0	4,4x
ECDH P-256	135,2	25,0	5,4x
ECDSA potpis	34,7	11,6	3,0x
ECDSA provjera (nepoznat ključ)	147,4	29,1	5,1x
provjera CA (registrirani izdavatelj)	54,2	9,6	5,6x
X25519 (kod nepromijenjen)	20,4	20,1	1,0x
procjena handshakea (zbroj gornjeg)	292	104	2,8x

Zatim stvarna stvar: isti generator opterećenja, ista metoda kao u ranijem tekstu o performansama (puni TLS 1.3 handshake s klijentskim certifikatom, bez nastavka sesije, MQTT CONNECT, poslužitelj zatvara prvi), pokrenut sa stroja udaljenog 9 ms od poslužitelja, protiv istog netcup VPS-a, prije i poslije promjene. Slika za benchmark ima opuštena ograničenja handshakea, kao u usporedbi na x86_64; tri ponavljanja, brojka je medijan.

Niti	prije (veza/s)	poslije (veza/s)	omjer	grešaka
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 dio veze, p50, 32 niti	18,5 ms	13 ms

Puni handshakeovi u sekundi porasli su za otprilike 1,55 do 1,7 puta, a ne tri puta koliko bi dala sama aritmetika. Razlog je jednostavan i vrijedi ga reći: ubrzali smo P-256, a X25519 (176 µs), TCP/IP stog, sloj zapisa i MQTT nisu se promijenili, pa preostali dio dobiva na važnosti (Amdahlov zakon). Sljedeći kandidat je X25519.

Radi orijentacije uz x86_64 poslužitelj iz ranijeg teksta. Ovo nije usporedivo kao utrka: različiti procesori, različit broj jezgri (4 naspram 2), različita udaljenost do generatora (15 ms naspram 9 ms) i u oba slučaja dijeljeno računalo s generatorom opterećenja koje je tijekom pokretanja gubilo 5 do 60 % vlastitog procesora. Usporediv stupac je vlastiti trošak procesora poslužitelja po handshakeu:

	Contabo, x86_64 EPYC (asm)	netcup, ARM64 N1 prije	netcup, ARM64 N1 poslije
procesor poslužitelja po handshakeu	0,26 ms (konzola brokera)	1,08 ms (Dijagnostika)	0,55 ms (Dijagnostika, jedno pokretanje, vidi dolje)
handshakeova/s, 32 niti	169 (bench)	848	1 317
handshakeova/s, 64 niti	278 (bench)	827	1 398
handshakeova/s, 128 niti	413 (bench)	778	1 316

Isti dan Dijagnostički unos ponovno je pokrenut na ovom stroju, s assemblyjem (u izgradnji koja sadrži i grafički driver opisan u dopuni na kraju): procesorski trošak poslužitelja za jedan uzajamni TLS handshake bio je 553 µs naspram 1,08 ms prije, 1,95 puta manje. Provjera ECDSA trajala je 192 µs (prije 508 µs), potpisivanje 78 µs (141 µs), a X25519 209 µs (176 µs; taj kod je nepromijenjen, a takt procesora u ovom pokretanju bio je 2,58 GHz naspram 2,95 do 2,98 GHz u ranijima, pa se pojedinačne brojke na ovom dijeljenom stroju pomiču za desetke posto). To je jedno pokretanje, na dijeljenom domaćinu. Da je brzina handshakeova porasla 1,55 do 1,7 puta, a vlastiti trošak poslužitelja po handshakeu pao 1,95 puta, slaže se: ostatak veze čine stog, generator i mreža. Šum između pokretanja vidi se u sirovim datotekama: svaki skup od tri ima jednu odstupajuću vrijednost (408 prije i 957 poslije kod 32 niti), kad je računalo s generatorom izgubilo većinu svog procesora u korist drugih virtualnih strojeva. Kod 128 niti na granici je generator, ne poslužitelj, na oba stroja.

Ostatak paketa na ovom stroju

Isti paket kao za x86_64 poslužitelj (propusnost, latencija, fan-out, neaktivne veze) pokrenut je u cijelosti nad novom izvedbom. Za ove retke nema "prije": pokretanje je prekinuto radi gradnje assemblyja, pa su to stanja nakon promjene, a assembly ne dira te putove osim handshakeova koji otvaraju veze. Jedna činjenica objašnjava većinu onoga što slijedi: ovaj virtualni stroj ima dva vCPU-a. Jezgra 0 radi mrežnu karticu, raspoređivanje i sav MQTT i TLS posao, jezgra 1 je jezgra baze podataka i cijelo je vrijeme bila zauzeta 2 do 3 %. x86_64 poslužitelj imao je četiri vCPU-a i dvije radne jezgre. Sve u nastavku zato je performansa brokera na jednoj jezgri.

Neaktivne veze	5 000	10 000	20 000
spojeno	5 000 od 5 000 u 4,3 s	10 000 u 9,3 s	20 000 u 21,2 s
rast kernelove hrpe po vezi	0,34 KB	0,41 KB	0,43 KB
grešaka	0	0	0

(Na x86_64 poslužitelju kod H7 commita bilo je 0,50 do 0,66 KB po vezi. Brojka za hrpu je $SYS/broker/memory/used minus njegova vrijednost prije prve veze.)

Latencija pri skromnoj brzini (8 parova x 100 poruka/s, 64 B)	p50	p99
QoS 0	4,0 ms	6,9 ms
QoS 1	4,1 ms	7,0 ms

Fan-out (1 izdavač, 64 B)	isporučeno u sekundi	p50	p99
100 pretplatnika, QoS 0, 50 poruka/s	5 000 (sve)	5,9 ms	8,6 ms
100 pretplatnika, QoS 1, 50 poruka/s	5 000 (sve)	6,3 ms	10,0 ms
1 000 pretplatnika, QoS 0, 10 poruka/s	8 805 od 10 000	207 ms	5,4 s

Flood, 16 parova, izdavači onoliko brzo koliko broker prima	objavljeno/s	isporučeno/s	p50 / p99	izgubljenih veza
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 para	130 462	69 411	69 ms / 87 ms	0

Kako to čitati. Latencija pri skromnoj brzini je doprinos brokera plus jedan put do generatora: generator je bliže ovom poslužitelju nego onaj u usporedbi na x86_64, pa dva stupca latencije nisu usporediva. QoS 0 flood pokazuje uobičajenu sliku preopterećene jedne jezgre: broker prihvaća 231 000 poruka u sekundi, a isporučuje 85 000 (ostatak odbacuju pravila protutlaka, za što i služe) uz latencije od više sekundi, a nijedna veza nije izgubljena; na x86_64 poslužitelju ista vrsta flooda koštala je nekoliko veza po pokretanju zbog watchdoga od 20 ms (ADR-221 je od tada promijenio način na koji se taj proračun broji). Redak s 1 000 pretplatnika ima isti karakter kao prije, repove od više sekundi, dijelom i generatorove. Brojke kod H7 commita na x86_64 poslužitelju nalaze se u ranijem tekstu; ne stavljamo ih u istu tablicu s ovima jer se kod između dva mjerenja promijenio na putu podataka (ADR-221 do ADR-224), a strojevi se razlikuju u svemu.

Greške koje smo sami pronašli

• Slika je govorila "no disks found", a disk je bio u izvještaju. Prva inačica urmqtt-diag-png uopće nije čitala polje disks. Vlasnik projekta pogledao je sliku, rekao da izgleda krivo, i bio je u pravu. Popravljeno, a test sada čita disk natrag iz JSON-a.
• Instalacijski program proglasili smo gotovim prerano. Stanje poslužitelja dvaput je prešlo u "off": jednom na kraju ciklusa napajanja i jednom kad je instalacijski program završio. Naša skripta uzela je prvo za drugo, odvojila ISO i pokrenula stari sustav, koji je zatim javio staru verziju i natjerao nas da tražimo kvar u instalacijskom programu kojeg nije bilo. Skripta sada prvo čeka svježe pokretanje.
• Povijest napretka je izgubljena. Analiza za roadmap pokazala je da je commit za prekretnicu S6 zamijenio docs/PROGRESS.md (1 763 retka, prekretnice M0 do S5) vlastitim unosom od 26 redaka. Ostalo je neprimijećeno danima, iako README tu datoteku naziva "izvorom istine". Vraćena je iz povijesti.
• CI je pao nakon assemblyja, na dva mjesta. Tri smoke testa imala su u sebi upisanu veličinu boot slike ("10 MiB"), koja je s većim kernelom narasla na 11 MiB; više ne pretpostavljaju veličinu. Drugi pad bio je test vremena izvođenja opisan gore: prvi put izgledao je kao šum na dijeljenom runneru, pa smo test natjerali da se ponavlja tri puta; pao je u sva tri pokušaja, i tako smo saznali da je to signal, a signal se pokazao kao naš vlastiti test (potpisivao je svaki put istu poruku). Tu jednu granicu podigli smo na nekoliko sati, to smo rekli otvoreno i spustili je ponovno kad je uzrok popravljen.
• Dokumentacija broji tri riječi za pokretanje, a kod ima četiri (diag-serve), a tablica prekretnica u README-ju radu prošlog tjedna još pokazuje kao planiran. Oboje je u roadmapu kao stavke za popravak.

Roadmap, s pitanjima

Po prvi put postoji roadmap: oko 40 stavki u tri faze (v0.4 učvršćivanje i rad; protokol i mreža; skaliranje, više cloudova i bare metal), svaka s razlogom preuzetim iz dokumenta, naporom, rizikom i načinom provjere, 16 pitanja na koja može odgovoriti samo vlasnik, i popis onoga što je izvan opsega. Nekoliko stvari kaže otvoreno: podržan je samo MQTT 3.1.1, QoS 2 publish zatvara vezu, nema IPv6 (pružatelj daje /64), nema WebSocketa ni odlazne veze iz brokera, i nema drivera za mrežne i spremišne uređaje velikih cloudova.

Što još nije dokazano

• Procesorski trošak po handshakeu s assemblyjem izmjeren je na jezgri Neoverse samo jednom (553 µs naspram 1,08 ms prije, pri nižem taktu, na dijeljenom domaćinu); 1,55 do 1,7 puta dolazi iz brzine punih handshakeova, a 3 do 5 puta s Appleove jezgre. Strana refaktoriranja za x86_64 (kod premješten u zasebnu datoteku) prošla je provjeru tipova i izgradnju, ali njezini jedinični testovi nisu pokrenuti niti je x86_64 kernel pokrenut nakon nje: x86_64 paketi testova nisu u CI-ju, pokreću se ručno na Contabo VPS-u, a to za ovu promjenu još nije učinjeno.
• Konstantno vrijeme izvođenja: za generiranje ključa P-256, ECDH i potpisivanje (ključ i nonce) statistički test nije našao ovisnost o rijetkoj tajni. Pokrenut je na Appleovoj jezgri i na CI runneru (virtualni stroj Neoverse N2), ne na jezgri Neoverse N1 kod netcupa, i nikad sa zastavicom DIT postavljenom na serverskoj jezgri (A255-W2, otvoreno: kernel je ne postavlja). Nije pokrenut za X25519 ni Ed25519. Test crne kutije ograničava samo ono što može razlučiti pri svojoj veličini uzorka.
• Jedan poslužitelj, jedan pružatelj, jedna instalacija. Nekoliko rezultata (instalacija, prekid napajanja) je jedno pokretanje. Osim handshakeova, retci o performansama nemaju "prije", a stroj s dva vCPU-a daje brokeru jednu podatkovnu jezgru.
• Generator slučajnih brojeva na ovom poslužitelju inicijaliziran je iz jittera i iz firmwarea, kako je gore opisano.
• Ključ za potpis je i dalje probni, slike izdanja su razvojne izvedbe, a prijevode ovog teksta napisao je AI i nisu ih provjerili izvorni govornici.
• Nema neovisne revizije, nema bare metala, nema IOMMU-a.

Što slijedi

1. X25519 u assemblyju za ARM64 (to je 176 µs preostalog handshakea), i ponavljanje mjerenja po handshakeu na jezgri Neoverse više od jednog puta.
2. Odluka o zadanom ponašanju generatora slučajnih brojeva: odbiti pokretanje bez sklopovskog izvora osim ako operator kaže drukčije, ili zadržati pričuvu s jitterom i to glasno reći.
3. Stari popis: odluka o D1, fuzzing PCI i virtio parsera, dijalog za ključ na stranici graditelja.
4. Iz roadmapa, za sljedeće izdanje: pravi ključ za potpis i produkcijski PKI, MQTT 5.0 i QoS 2.

Kod je na github.com/zeljan-alduk/urMQTT; docs/PROGRESS.md je i dalje izvor istine o tome što radi, docs/PERFORMANCE.md o tome što je izmjereno (odjeljak 10 sadrži brojke za assembly), docs/AUDIT.md o tome što nije dokazano. Pred-alfa, kao i prije; prijave grešaka i sigurnosne prijave po uputama u SECURITY.md dobrodošli su.

Dopuna, 4. studenoga, kasnije istog dana. Četiri stvari iz sati nakon što smo objavili ovaj tekst.

1. Brojka koja je nedostajala. Dijagnostički unos ponovno je pokrenut na poslužitelju kod netcupa s assemblyjem i dao broj koji nedostaje u prvoj tablici: 553 µs procesora poslužitelja po uzajamnom TLS handshakeu naspram 1,08 ms prije (pojedinosti ispod te tablice).
2. Signal potpisivanja bio je naš test. Uzrok vremenskog signala opisanog gore pronađen je i popravljen u testnom okviru (potpisivao je svaki put istu poruku); granica je opet 7. Otvoreno ostaje to da zastavica DIT nigdje nije postavljena (A255-W2).

3. Problem s ekranom je riješen, i nalazi se na grani main. Napisali smo driver za virtio grafičku karticu (samo 2D, ADR-256), koji se uključuje konfiguracijskim ključem upečenim u sliku (console.virtio_gpu, off je zadano, auto i on traže format konfiguracije 5). S on kartica "Screen" konzole pružatelja uživo prikazuje nadzornu ploču Dijagnostike na poslužitelju kod netcupa, istu sliku kao gore, uključujući posljednji ekran s "press any key". Njegov fuzz target našao je pravu grešku u prvoj verziji: odgovor s informacijama o zaslonu kraći za četiri bajta od specifikacije prihvaćen je kao valjan (A256-W1); pravi uređaj uvijek šalje cijeli odgovor, pa poslužitelj nije bio pogođen, a parser sada odbija kratki. Što nismo provjerili: da je tamni zaslon doista došao od firmwarea koji resetira karticu kad predaje upravljanje kernelu (vjerojatno, nije potvrđeno), međudjelovanje sa Secure Bootom i x86_64 na pravom stroju (radio je samo pod emulacijom). Poznato ograničenje (A256-W2): postavka auto ne može razlikovati živi emulirani framebuffer pokraj virtio kartice od mrtvog, pa u toj jednoj konfiguraciji uzima virtio karticu. Driver u kernel dodaje parser odgovora hipervizora, zato je isključen osim ako ga konfiguracija ne traži.

4. Izdanje. Sve ovo nalazi se u v0.4.0, objavljenom iste večeri kao predizdanje (izdanje na GitHubu). Stranica graditelja na ovom web-mjestu nudi ga prvo; traži format konfiguracije 6, a stariji predlošci (v0.2.0 do v0.3.0) odbijaju nove ključeve porukom koja kaže da treba koristiti novije izdanje. Ograničenja izdanja v0.3.0 ostaju: ključ za potpis i dalje je probni, a slike su razvojne izvedbe s testnim certifikatima. CI na commitu izdanja bio je zelen tek nakon što je jedan posao ponovno pokrenut (klijentski test unutar smoke scenarija jednom je istekao, a drugi put je prošao). Što smo provjerili na objavljenim datotekama: minisign potpis, kontrolne zbrojeve, atestacije izgradnje kernela i SBOM-a te predložak s novim ključevima (v0.4.0 ih prihvaća, v0.3.0 ih odbija). Driver za nove virtio uređaje (konzola, balloon, input, vsock) nalazi se u izdanju, ali je zadano isključen i nije pokrenut na pravom poslužitelju.