L'avvertenza iniziale resta la stessa: il progetto è pre-alfa, la prima pubblicazione è solo per VPS con KVM, e i numeri misurano codice, test ed esperimenti precisi, non la maturità in produzione.

Come si presenta nel tempo

Dall'articolo precedente (31.10. alle 23:00) a oggi (1.11. alle 20:41) il repository ha 59 nuovi commit, in tutto 178. Sono nati tutti in un solo giorno di calendario, quindi vale la stessa avvertenza di prima: il progetto è costruito con Claude Code (i commit portano Co-Authored-By: Claude), piano, codice, test e ADR nascono in cicli brevi e chiusi, e i numeri qui sotto parlano della quantità di codice e di verifiche, non di quanto lavoro umano ci sia dietro.

I numeri sono calcolati con lo stesso metodo dell'articolo precedente: tutti i file .rs fuori da vendor/ e fuzz/, le funzioni #[test], i titoli ## ADR- in docs/DECISIONS.md.

Si è lavorato in parallelo su più branch, quindi l'ordine dei commit non è rigorosamente l'ordine del lavoro. Gli ADR sono numerati fino a 232, ma la numerazione ha dei vuoti (una parte è stata rinominata durante l'unione dei branch); contiamo i titoli, non il numero più alto. Le release: v0.2.0 (1.11., 18:45 UTC) e v0.2.1 (1.11., 20:22 UTC), entrambe contrassegnate come pre-release.

H6: SQLite in modalità utente

Che cosa avevamo pianificato. SQLite è fatto di 254 268 righe di C che analizzano il database, il WAL e il journal dal disco, e il disco può essere stato fabbricato o modificato. Finora girava nel kernel, con i privilegi del kernel. Che cosa abbiamo costruito (da ADR-210 a ADR-212): SQLite, le sue parti di libc e il suo heap sono stati spostati in un programma separato, dbworker, che gira in EL0 (aarch64) ovvero ring 3 (x86_64), in uno spazio di indirizzi proprio. Il kernel non linka più SQLite. Il worker parla con il kernel attraverso una finestra di memoria condivisa e dodici chiamate di sistema, e ogni lunghezza e ogni offset restituiti vengono controllati prima dell'uso. Un errore nel worker (accesso non consentito, istruzione non definita, budget di tempo di 30 s superato) termina la chiamata, il worker viene riavviato e il database viene riaperto dal WAL come all'avvio; dopo 5 riavvii in un minuto lo storage viene dichiarato guasto, invece di riavviarsi all'infinito.

Il costo, misurato su aarch64 con HVF, stessa VM, kernel con SQLite incorporato contro kernel con worker, sei avvii alternati per ciascuno:

Le scritture su disco (1 572) e i flush (319) sono identici, come deve essere. Ciò che non è isolato è questo: il kernel continua a fidarsi di ciò che il worker restituisce, dopo il controllo della forma. Un worker compromesso può mentire (per esempio restituire una lista vuota di certificati revocati, e quindi "annullarne" la revoca), ma non può leggere la memoria del kernel, le chiavi TLS né le chiavi dei ticket. Non c'è KPTI, quindi le fughe di tipo Spectre/Meltdown non sono impedite e non affermiamo nulla al riguardo; la chiave PAC è condivisa tra EL0 ed EL1. Su x86_64 il costo del passaggio non lo abbiamo misurato su KVM (sotto TCG il numero sarebbe privo di senso), e il fuzzing del worker e del protocollo stesso non è concluso. La suite di test per lo storage (79 scenari, ognuno fa girare SQLite nel worker) passa su aarch64 HVF e su x86_64 TCG, su aarch64 TCG ne passano 76 (uno viene saltato perché TCG non ha MSI-X).

H7 è chiuso, ma non come avevamo annunciato. Il limite inferiore del tempo (ADR-050) e l'SNTP con consenso (T1) coprono il perimetro di H7; NTS (RFC 8915) resta fuori dal perimetro ed è annotato come rischio residuo, non come qualcosa che funziona. Non riteniamo che la sicurezza del tempo sia "risolta", ma che sia finita la sua parte dimostrabile.

Una nuova opzione di rete. Contabo non dà DHCP a un ISO personalizzato, quindi finora il VPS richiedeva un'immagine diversa da quella della VM di laboratorio. Ora network.mode = "auto" (ADR-214) interroga prima il DHCP e, se il lease non arriva nel tempo previsto (dhcp_timeout_s, predefinito 15 s) o lo perde, applica l'indirizzo statico indicato. Provato a mano su QEMU (con il DHCP usa il lease, senza rete dopo 5 s torna all'indirizzo statico); per questo non esiste ancora uno scenario smoke.

X11: confronto con Mosquitto sullo stesso VPS

Lo stesso tipo di macchina dell'articolo precedente (Contabo, 4 vCPU AMD EPYC, 8 GiB), carico da un host Linux a 15 ms di distanza, TLS 1.3 reciproco con gli stessi certificati da entrambe le parti, Mosquitto 2.0.21 su Debian 13 senza persistenza. Metodo e decisioni sono in ADR-213, i dati grezzi in docs/perf-results/. Mediana di tre esecuzioni.

Che cosa significa, e che cosa no. Gli handshake sono limiti inferiori per entrambi i server: il generatore di carico è una VM condivisa con il 60-70% di tempo di CPU rubato e con 128 thread era vicino al proprio limite, mentre i core di lavoro di urMQTT erano occupati solo per il 12-13%. Il rapporto con 128 client (circa 2,2 volte) è il più significativo; con 32 e 64 misura per lo più l'attesa dei client. I numeri di memoria non contano la stessa cosa (heap del kernel contro RSS del processo), quindi "circa 50 volte meno" è un ordine di grandezza, non un rapporto preciso. La latenza di 14 ms è un giro di rete (circa 15 ms), cioè "nessun tempo misurabile del broker"; le code (p99 circa 100-200 ms) sono dominate in entrambi i broker dagli host condivisi. Le differenze sotto circa il 20% non le affermiamo.

Che cosa non è andato a nostro favore ed è rimasto nelle tabelle: un singolo flusso TCP attraverso urMQTT portava da 2 a 8 volte meno che attraverso Mosquitto, con variazioni da zero a 7,7 mila messaggi al secondo tra un'esecuzione e l'altra, e il watchdog da 20 ms del gestore interrompeva connessioni vive quando l'hypervisor fermava una vCPU (nella configurazione di produzione action = "drop", da 6 a 8 connessioni per esecuzione con il flood QoS 0). Entrambe le cose sono descritte nella sezione seguente perché avevano cause nel nostro codice.

Perché il flusso singolo era lento: cause, non scuse

La cosa più facile sarebbe stata dire "VPS condiviso". Non l'abbiamo fatto: con lo stesso VPS e lo stesso metodo abbiamo cercato le cause. Ne sono state trovate cinque, quattro nel percorso dei dati e una nel watchdog (da ADR-221 a ADR-224):

Le interruzioni sono reali: su questo VPS i core da 0 a 2 hanno avuto una mediana da 36 a 80 tick in ritardo ogni 5 secondi, e l'interruzione peggiore nella finestra aveva una mediana di circa 70 ms e fino a 0,9 s (core 3, database e journal: fino a 1,55 s), mentre l'host non riporta tempo rubato (host steal 0 us). Per questo il watchdog aveva bisogno di un secondo orologio, non di un budget più grande.

Watchdog: 148 connessioni interrotte in 30 esecuzioni sotto carico prima, 0 in 24 esecuzioni dopo; su un apparecchio locale che ritarda e perde frame, con una perdita dello 0,1% un flusso singolo da 64 B con 14,3k messaggi/s (kernel X11) ora arriva a 41,0k, e con lo 0,5% da 5,0k a 17,7k.

Che cosa questo non dice. urMQTT non è ancora più veloce di Mosquitto su un singolo flusso: a 64 B pubblica circa l'80% della sua velocità e consegna circa il 40%, perché scarta il QoS 0 quando il flusso del sottoscrittore è più lento di quello di chi pubblica (Mosquitto, senza limite, mette in coda). A 1 KiB nel flood a 16 coppie Mosquitto è avanti di circa il 15%, il che rientra nel rumore. Il generatore era di nuovo una VM condivisa con il 58-77% di tempo rubato. Il secondo giro (blocco dell'heap fuori dal percorso dei dati, SACK lato invio e altro) è sul branch non integrato perf-single-flow-wip; i suoi numeri non sono ancora affermazioni e qui non li riportiamo.

Una promessa che non avevamo fatto, ma che abbiamo mantenuto: la configurazione è un dato

Finora ogni configurazione era una nuova compilazione: chiavi e limiti erano incorporati nell'immagine. C1 lo rovescia (da ADR-215 a ADR-219): il kernel si compila una volta sola e la configurazione è un dato.

• Blob urmqtt-cfg (C1a): una registrazione versionata e canonica (campi per tag crescente, impronta SHA-256, firma Ed25519 separata facoltativa), 70 campi con valori predefiniti e limiti, un decodificatore che rifiuta tutto ciò che non è valido.
• Il kernel lo legge come modulo Limine (C1b), prima di qualsiasi altra cosa, su aarch64 e x86_64. Esiste un solo kernel pubblicato per ogni ENV tranne dev (gli ELF aarch64 per release, prod e bench hanno lo stesso SHA-256; verificato solo su aarch64). Il kernel pubblicato rifiuta la configurazione di sviluppo e, senza configurazione, scrive "refusing to serve" e non serve nulla.
• Il disco installato porta la configurazione e l'aggiornamento la conserva (C1c).
• urmqtt-config e il modello ISO (C1d): pack, show, verify, e pack --iso sostituisce entrambe le copie dello slot di configurazione e i 24 digest dei moduli in un ISO già pronto. Il risultato è identico byte per byte all'ISO che mkiso.sh --config costruisce. Il modello della release v0.2.0 è di 63 111 168 byte.
• Dichiarazione di fiducia (ADR-219): l'immagine configurata, all'avvio, stampa l'impronta della configurazione (config: fingerprint ...), mentre la firma è facoltativa e disattivata per impostazione predefinita. Un ISO modificato non ha il digest ufficiale; l'impronta è il modo per vedere che cosa contiene.

Il builder su aldo.tech

Ciò che fa urmqtt-config pack --iso lo fa anche la pagina web, con lo stesso codice: la libreria dello strumento compilata in WebAssembly (1,06 MB, senza import e senza blocchi unsafe). La pagina è su aldo.tech/it/prodotti/urmqtt-builder/ ed esiste in tutte le 15 lingue del sito (per esempio hr).

• Nulla lascia il browser. Certificati, chiavi private e l'ISO finito restano sul computer; la pagina scarica soltanto i file della release da questo sito, senza tracciamento e senza script di terze parti. Nel test dal vivo nessuna richiesta portava materiale di chiavi.
• Mirror delle release (ADR-227): ogni ora (timer systemd, a bassa priorità) copia le release da GitHub, ognuna viene verificata prima della pubblicazione, e la pagina nel browser verifica la firma di SHA256SUMS con la chiave incorporata nella pagina, e solo dopo scrive la configurazione nel modello. Una verifica fallita blocca il download.
• Semplice per impostazione predefinita, avanzato quando serve (ADR-232): la prima schermata ha tre passaggi (dove gira, i vostri certificati, il nome dell'immagine). Un solo campo di trascinamento ordina certificato, chiave e CA in base al contenuto. La vista avanzata apre ciascuno dei 70 campi, la ricerca, l'importazione e l'esportazione di TOML; le due viste modificano lo stesso stato. Il modello (63 MB) viene scaricato mentre l'utente compila il modulo. In una prova dal vivo, con mirror di prova e chiave di prova, la creazione dell'ISO nel browser è durata da 5 a 18 s.

L'emulatore, facoltativo. Accanto a "Scarica ISO" c'è "Prova nell'emulatore": QEMU compilato in WebAssembly avvia l'immagine appena creata in una scheda del browser. Nulla di esso viene scaricato prima del clic (circa 3 MB la prima volta). L'emulatore è solo BIOS, senza rete (perché il traffico dell'utente non passi attraverso un intermediario e non violi il "nulla lascia il browser"), richiede circa 1,5 GB di memoria e un browser per computer (testato Chrome; Firefox e Safari no). Al suo interno urMQTT arriva a URMQTT READY in circa 8 s (saltando il conto alla rovescia) e stampa la stessa impronta di configurazione della pagina, il che prova che è stata avviata proprio quella configurazione. L'avvio è circa 2 volte più lento del QEMU nativo sullo stesso Mac (0,82 s contro 1,9 s), e la crittografia circa 58 volte più lenta perché le istruzioni hardware sono emulate. Per questo dall'emulatore non ricaviamo alcuna affermazione sulla velocità, e la pagina lo dice prima dell'avvio. Durante la compilazione è stato necessario correggere quattro byte nel .wasm a causa di un errore nella traduzione dell'istruzione POPCNT nell'emulatore originale (non l'abbiamo ancora segnalato); l'emulatore stesso è sotto GPL, con offerta del codice sorgente.

MQTT in chiaro, solo per reti di cui ci si fida

L'MQTT in chiaro (TCP 1883, senza TLS) è molto diffuso nell'IoT: è l'impostazione predefinita di Mosquitto, nella maggior parte dei firmware per Arduino ed ESP, in Tasmota, Zigbee2MQTT e Home Assistant, e viene usato anche all'interno di reti industriali segmentate, dietro una VPN e su LAN private, e anche su dispositivi senza orologio (i certificati richiedono una data), senza abbastanza flash o processore per il TLS. Su una rete non affidabile non è accettabile: chi è sul percorso legge e modifica il traffico. Per questo P1 (da ADR-229 a ADR-231) è una scelta esplicita e limitata, disattivata per impostazione predefinita, e la porta TLS resta; il TLS non viene disattivato da questa opzione, la porta in chiaro si aggiunge.

• L'elenco delle reti consentite è obbligatorio (allow_from, CIDR) e viene controllato al SYN: fuori dall'elenco non c'è SYN-ACK né stato. L'intera internet (0.0.0.0/0) richiede un'opzione esplicita a parte.
• Tre modalità di accesso: password (predefinita quando è attivo; PBKDF2-HMAC-SHA-256, salt, 10 000 iterazioni, confronto a tempo costante, blocco per indirizzo), anonimo (una identità configurata con un proprio ACL) e per indirizzo (ip). Il builder calcola l'hash della password nel browser e in memoria tiene solo il digest.
• Meno diritti che con mTLS: un client in chiaro non ha mai diritti di servizio, di operatore né di gestione, non ha $SYS né console, ha proprie sessioni ($plain/<identità>/<id client>, solo pulite), propri limiti e il registro dei consentiti continua a vincolarlo.
• Che cosa si perde, lo dice SECURITY.md: riservatezza, integrità, autenticità del broker e la riproduzione di un accesso registrato. Questo non si può correggere con la configurazione; è così quando non c'è il TLS.

Misurato su un laptop (Apple silicon, HVF, rete utente QEMU), 16 coppie, 64 B, tre esecuzioni da 10 s: a 8 000 messaggi al secondo il percorso TLS e quello in chiaro consegnano tutti i messaggi con la stessa latenza (p50 0,17 ms contro da 0,13 a 0,18 ms), nuove connessioni al secondo: TLS circa 2 600-2 750, anonimo in chiaro circa 4 900-7 800, e l'accesso con password è la parte costosa: un PBKDF2 costa circa 2,5 ms, quindi il numero di nuovi accessi è limitato a circa 200 per core dati al secondo (misurati da 308 a 342 su due core). Il flood su quella macchina non è uno strumento stabile (da 20k a 440k consegnati al secondo tra un'esecuzione e l'altra) e non ne ricaviamo conclusioni. Il confronto del percorso in chiaro con Mosquitto su VPS non è ancora stato fatto. Test: gruppo smoke plaintext 7 su 7 su aarch64 HVF e su x86_64 TCG, nuovo target fuzz plain_input (2,3 milioni di esecuzioni senza risultati).

Gli errori trovati dall'uso dal vivo

Due cose non le hanno trovate i test, ma la prima messa in funzione sul sito vero:

• La pagina cercava i file della release una directory troppo in alto, quindi ogni verifica della firma rispondeva 404 (correzione 13af301). Il test usava un mirror di prova su un altro percorso.
• La tastiera dell'emulatore non è mai arrivata al guest: la causa non era una cattiva traduzione dei tasti, ma il fatto che la finestra di dialogo non ascoltava affatto i tasti (correzione in ADR-232, con una voce di avvio che non richiede tasti).

Lezioni

• Cercate la causa, non incolpate l'ambiente. La maggior parte delle debolezze del flusso singolo e tutte le connessioni interrotte erano nostre; l'hypervisor è reale, ma andava misurato, non presupposto.
• Il confronto con un altro prodotto deve includere anche le perdite. Una tabella con solo le nostre vittorie non sarebbe un confronto.
• Lo strumento di misura ha dei limiti. Un generatore condiviso con il 60-70% di tempo rubato cambia il significato dei numeri; per questo scriviamo "limite inferiore" e non affermiamo differenze sotto il 20%.
• L'isolamento non è una dimostrazione. SQLite in EL0 riduce ciò che un errore al suo interno può fare, non ciò su cui può mentire.
• Un'installazione reale trova ciò che i test non cercano: un percorso composto male e tasti che nessuno ascolta.

Che cosa non è ancora dimostrato

• La chiave di firma della release per ora è una chiave di prova; v0.2.0 e v0.2.1 sono pre-release, e le immagini che le accompagnano sono di sviluppo con certificati di prova (tranne il modello, che è senza configurazione).
• 13 traduzioni della pagina del builder (e di questo articolo) sono state scritte da un'AI e verificate con test e campioni, non da madrelingua.
• Il confronto con Mosquitto è una sola sessione, un solo percorso e un solo generatore condiviso, su un VPS condiviso; le differenze sotto il 20% non sono affermazioni.
• Il percorso in chiaro non è stato misurato su VPS né contro Mosquitto.
• Lighthouse sulla nuova vista semplice non è confermato (vista precedente: accessibilità 95 o più).
• Bare metal, costo del worker x86_64 su KVM, Firefox e Safari per l'emulatore: non misurato.

Che cosa viene dopo

• D1: broker demo pubblico. L'emulatore del browser non possiamo renderlo pubblico: vive nella scheda di un solo visitatore, è da 20 a 100 volte più lento di KVM, non ha rete in ingresso e sparisce con la chiusura della scheda; far passare internet nel browser di qualcun altro sarebbe anche un abuso. Un vero broker demo è possibile: urMQTT su un VPS dietro un nome su aldo.tech, con una CA di prova pubblicata, un ACL severo e piccoli limiti. Per ora è solo un'idea, non un lavoro in corso, e richiede un consenso esplicito per l'esposizione pubblica.
• Secondo giro per il flusso singolo (branch perf-single-flow-wip): solo quando sarà misurato su VPS e unito.
• Percorso in chiaro contro Mosquitto su VPS, registrazione e revoca dell'account per l'MQTT in chiaro attraverso il canale di gestione firmato.
• Dopo la pubblicazione: bare metal (da X12 a X16), IOMMU e Secure Boot, cifratura del disco.

Il codice è su github.com/zeljan-alduk/urMQTT, e docs/PROGRESS.md resta l'unica fonte di verità su ciò che funziona davvero, docs/PERFORMANCE.md su ciò che è stato misurato. Pre-alfa, come prima; segnalazioni di errori e di sicurezza secondo le istruzioni in SECURITY.md sono benvenute.

Una premessa: il progetto è ancora pre-alfa. I numeri nel testo misurano codice e test, non la maturità in produzione, e la prima pubblicazione è volutamente limitata ai VPS con KVM. Il bare metal resta per dopo.

Come si presenta nel tempo

Il primo commit risale al 28 ottobre 2026 alle 23:48 (M0). Al 31 ottobre alle 23:00 il repository conta 119 commit, distribuiti come 3, 39, 38 e 39 per giorno di calendario. Diciamo subito anche come sia possibile: il progetto è costruito con Claude Code, e i commit portano trailer Co-Authored-By: Claude. Quattro giorni di calendario di storia non significano che una persona abbia scritto 90 000 righe in quattro giorni; significano che piano, implementazione, test e ADR vengono scritti in cicli brevi e chiusi, e che ogni passo termina con lo stesso rituale di verifica di prima. I numeri qui sotto parlano della quantità di codice e di test, non di quanto lavoro reale ci sia dietro tutto questo.

Il grafico mostra tre curve che crescono quasi insieme, ed è proprio l'intenzione: test e decisioni scritte seguono il codice, non restano indietro. La pendenza è massima il 29 ottobre, quando nasce l'intero percorso dal kernel al broker. In seguito le righe si aggiungono più lentamente, ma i test crescono più in fretta del codice (27 test su 1,6 migliaia di righe all'inizio, 739 su 89,8 migliaia oggi).

Le righe sono tutti i file .rs al di fuori di vendor/ e fuzz/, i test sono funzioni #[test]. Che cosa ha aggiunto ciascuna fase, in base alla data nella storia di git:

Promessa 1: un solo ISO per più piattaforme

Che cosa avevamo pianificato. Un unico file che si avvia su UEFI aarch64, UEFI x86_64 e BIOS x86_64. Che cosa abbiamo costruito. Il port su x86_64 (da X0 a X10) e un ISO universale con il bootloader Limine, un unico ISO ibrido da cui si avviano tutte queste combinazioni; gli smoke test lo avviano su quattro macchine virtuali. Il menu ha tre voci: urMQTT (modalità live, gira dalla RAM, non scrive nulla sul disco), installazione sul disco della macchina su cui è avviato (l'installazione scrive GPT e dati, poi spegne la macchina) e Diagnostica (rilevamento dell'hardware e misure).

Il primo bersaglio reale è stato un VPS, non un computer fisico: la decisione è che la prima versione supporti solo VPS (KVM), mentre il bare metal arriva dopo. Abbiamo provato su un VPS Contabo con processore AMD EPYC (famiglia 23, Zen 1), 4 vCPU e 8 GiB di RAM, con rete virtio-net e disco virtio-scsi. Il primo tentativo ci ha sorpreso: l'ISO collegato come CD virtuale avviava la voce predefinita, l'immagine di produzione si è rifiutata di servire da un supporto di sola lettura e si è riavviata, così abbiamo ottenuto un ciclo infinito di menu, kernel, reset senza nulla di leggibile. Oggi un errore fatale nell'immagine di produzione lascia un messaggio sulla console per 60 secondi prima del riavvio e, da un supporto ottico, segnala che l'avvio è avvenuto da un supporto di sola lettura e si ferma. La modalità live in RAM (O3) ha poi aggirato il problema per il caso comune.

La voce Diagnostica è nata da questa esperienza: una macchina che non vediamo dobbiamo poterla interrogare su ciò che ha. Stampa CPU, RAM, rete, dischi e dispositivi PCI, misura la banda della memoria, il disco e la crittografia, e le stesse misure le emette come JSON sulla porta seriale. La scrittura su disco è consentita solo nello spazio non allocato e solo dopo aver digitato WIPE; nell'immagine qui sotto è stata saltata.

Che cosa è ancora aperto. L'hardware reale. Dopo la prima versione arriva il bare metal (avvio da USB, NVMe e AHCI, scheda di rete di un computer vero), insieme a IOMMU e Secure Boot, perché senza IOMMU un dispositivo malevolo o difettoso può scrivere su tutta la memoria. In questa versione non affermiamo nulla al riguardo.

L'handshake: da 1,2 ms a 0,24 ms

La prima misura della diagnostica sul VPS ha dato un numero scomodo: l'handshake mTLS, solo la crittografia lato server, richiedeva 1,2 ms. Su aarch64 usavamo già le istruzioni hardware AES e SHA, ma x86_64 non aveva nulla di simile per la chiave pubblica: RustCrypto è portabile e constant-time, e quindi anche lento. Tre modifiche lo hanno ridotto.

• Per P-256 abbiamo adottato l'assembly nistz256 di OpenSSL e ring (ADR-130), con tabelle a base fissa per la firma e per la verifica delle firme della CA (ADR-110, ADR-111).
• X25519 è stato riscritto su quattro arti a 64 bit con le istruzioni MULX/ADX (ADR-131).
• Dopodiché abbiamo profilato anche il resto (ADR-132, ADR-200).

I numeri variano di circa il 10% da un'esecuzione all'altra, quindi abbiamo annotato un intervallo anziché un singolo valore. Nel complesso è circa un quinto del tempo di CPU per un handshake.

Che cosa abbiamo imparato su memcpy. Quando la crittografia è scesa, il profilo ha mostrato qualcosa che non ci aspettavamo: le funzioni mem* (memcpy, memmove, memset) consumavano il 7% dell'handshake, dal 13 al 39% del percorso dei record TLS (39% per 64 B, 13% per 4 KiB) e dal 17 al 34% della distribuzione dei PUBLISH. Le abbiamo sostituite con assembly SSE2 per x86_64 (ADR-200), con test differenziali rispetto all'implementazione di riferimento per tutte le dimensioni, gli allineamenti e le sovrapposizioni. Per chiamata sono da 55 a 75 cicli contro da 7 a 12 per 1–64 byte.

Come leggere il grafico: più piccolo è il record, maggiore è la parte di tempo dedicata alla copia, e quindi maggiore è il guadagno. Per i messaggi piccoli, che sono la maggior parte del traffico MQTT, è questo che conta.

Che cosa questo non significa. Su x86_64 nativo abbiamo misurato OpenSSL 3.5.5 solo come riferimento per l'assembly (ADR-130), non come confronto fra prodotti. Il confronto Linux più Mosquitto sullo stesso VPS (attività X11) non l'abbiamo ancora fatto. Per questo non affermiamo che urMQTT sia più veloce di Linux: non è stato misurato. I numeri qui sopra confrontano urMQTT con se stesso.

Il sovraccarico è stato il secondo risultato. Sul VPS, da un singolo Mac (RTT 35 ms), 128 client hanno prodotto 618 handshake al secondo, 256 client 393 e 512 client 67, con migliaia di connessioni rifiutate. Non era un plateau, ma un crollo. Le cause le abbiamo trovate nel codice (due sono confermate in QEMU/HVF, sul VPS non si sono potute riprodurre), più di una insieme: una connessione rifiutata riportava il client oltre il segmento successivo che portava un SYN cookie valido, il rifiuto con RST diceva al client di riprovare subito, e la ricezione era O(coda). La correzione (da ADR-080 a ADR-082) scarta il SYN che non sarebbe stato accettato, ricorda i flussi rifiutati, mantiene la ricezione in O(1) e conta gli handshake per core. È possibile (ipotesi, non verificata) che parte della causa fosse anche sul client: lo strumento di carico chiudeva per primo, per cui un singolo Mac con 16 384 porte effimere e un TIME_WAIT di 30 secondi era limitato a circa 550 connessioni al secondo. Per questo il vero limite del server non l'abbiamo ancora misurato.

Promessa 2: disco raw, ma con cura

Che cosa avevamo pianificato. Mantenere il layout proprio senza file system e aggiungere tutto ciò che un file system di solito offre: allineamento, crescita, discard, copie di sicurezza e verifiche. Perché non un file system. Ne abbiamo discusso e la decisione è confermata: urMQTT scrive un solo database, un solo log di telemetria e metadati propri, non servono directory, permessi né nomi di file, e ogni strato in più sarebbe altro codice nella parte fidata e un altro modo in cui una scrittura può sparire in silenzio. Il disco è GPT con una partizione ESP e una partizione dati urMQTT, su cui sta il layout proprio.

Che cosa abbiamo costruito (da S2 a S6).

• Layout v2 (S2). Topologia del disco, allineamento a 1 MiB o alla dimensione I/O ottimale, blocchi fisici interi, coppia A/B di superblocchi con generazione (ADR-140). Il layout v1 il kernel lo rifiuta con un messaggio chiaro, e lo migra lo strumento offline urmqtt-disk migrate (ADR-141): per impostazione predefinita è una prova a secco, si copia e solo dopo si passa alla nuova versione, con ripristino e iniezione di errori a ogni scrittura.
• Crescita (S3). All'avvio il disco può crescere (mai ridursi), e su virtio-blk anche durante il funzionamento, tramite l'interrupt di cambio di configurazione (ADR-142, ADR-143).
• Discard e write-zeroes (S4). I dischi thin provisioned restituiscono lo spazio all'host. In un test il file qcow2 sull'host è sceso da 62 a 16 MiB dopo la scadenza dei segmenti di telemetria, e il ripristino non si fida mai del contenuto che è stato scartato.
• Copia di sicurezza del database su disco (S5). Copia A/B con l'API di backup online di SQLite a passi di 16 pagine: il passo più lungo 4,6 ms contro 445 ms quando si copia in una sola chiamata. I commit durante la copia hanno avuto un massimo di 2,4 ms contro 2,2 ms senza copia. Se quick_check all'avvio fallisce, il database viene ripristinato dalla copia.
• Scrubbing e avvio limitato (S6). Lo scrubber legge il disco con un budget I/O limitato e segnala i record danneggiati, mentre l'avvio legge solo il segmento più recente di ogni partizione, così il tempo di avvio non cresce con la dimensione della regione di telemetria. Con questo abbiamo chiuso un problema che avevamo calcolato in anticipo: su un disco grande il ripristino completo richiederebbe da minuti a decine di minuti.

L'intero gruppo di smoke test per l'archiviazione passa su entrambe le architetture: 79 riusciti, 0 falliti, su aarch64 sotto HVF e su x86_64 sotto TCG. Abbiamo misurato anche che S4 non ha rallentato il database: 53,3 mila inserimenti al secondo in batch prima e dopo, senza differenza misurabile.

Che cosa ci ha sorpreso. Quanto di un layout "semplice" sia fatto di casi limite: virtio-scsi e virtio-blk riportano la topologia in modi diversi, e una scrittura incompleta a metà migrazione deve sempre lasciare almeno una versione valida. Per questo ogni scrittura sul percorso di migrazione e di crescita è passata dall'iniezione di errori.

Che cosa è ancora aperto. Le pagine di SQLite non hanno checksum, quindi un bit modificato all'interno di un valore in una riga il database non lo rileva; i record di telemetria e il contenuto delle copie hanno un CRC e vengono individuati. La cifratura del disco (S7) non è finita.

Promessa 3: sicurezza dimostrabile, per quanto ci riesca

Rinforzo (H4). L'allocatore azzera la memoria liberata e la verifica al riutilizzo, rileva il double free, collega i puntatori della free list con XOR e azzera le chiavi alla liberazione (ADR-170). Protezione dello stack (-Zstack-protector=strong, 1315 funzioni, mentre SQLite con -fstack-protector-strong, ADR-171). I report di errore in produzione non contengono registri né indirizzi (ADR-172). KASLR su entrambe le architetture: il kernel è PIE e Limine lo sposta di circa 19 bit, mentre heap, stack e finestra MMIO sono posizionati in modo casuale (ADR-173). Su aarch64 MTE marca l'heap (ADR-174), ma solo sotto TCG: HVF e x86 non ce l'hanno. kCFI lo abbiamo valutato e non l'abbiamo adottato perché il compilatore sul nightly fissato va in crash con un errore interno; IOMMU è rinviato insieme al bare metal (ADR-175, ADR-176).

Il costo è misurato, non presunto. Sul percorso dell'handshake (dp-bench, aarch64 HVF, handshake completi TLS 1.3 + mTLS + CONNECT):

Nel complesso, quindi, il costo sul percorso dell'handshake è circa il 5% per le parti misurate in modo pulito, e con PIE e marcatura risulta circa il 7% su un core e circa l'11% su quattro, ma questa misura è rumorosa. La riteniamo accettabile, ma non l'abbiamo ripetuta sul VPS x86_64.

Vale la pena confrontarlo con il numero del primo articolo (862 handshake al secondo su un solo core). Lo stesso strumento oggi, con il motore di cifratura hardware su aarch64 (X0b) e una serie di ottimizzazioni arrivate da allora, dà 1941 prima del rinforzo. Non abbiamo isolato il contributo di ogni modifica, quindi sulla causa non affermiamo nulla.

Come è stato verificato, e che cosa no. H5 ha aggiunto Miri su un sottoinsieme di crate host, dimostrazioni con Kani, sanitizer, un model-fuzzer per le ACL e report di copertura. Kani ha dimostrato record_len in TLS, parse in TCP e due aritmetiche della timer wheel. Non è dimostrato (tempo scaduto): entrambi i decoder MQTT, entrambi i parsing della configurazione e il comportamento della timer wheel; il job CI per Kani quindi non è ancora bloccante. Miri non può eseguire assembly. Supply chain (H9): SBOM CycloneDX con 215 componenti, cargo-vet passa con 39 revisioni complete e 140 eccezioni, e cargo-deny è configurato per trattare gli avvisi di vulnerabilità come fallimento della CI (questi job CI finora sono stati provati solo in locale, non su GitHub, e il test negativo non è stato eseguito), insieme a VULNERABILITY-HANDLING.md. Lo stato onesto: delle 67 versioni di crate di terzi collegate al kernel, 53 sono eccezioni, non revisioni. Vet dimostra che l'insieme delle dipendenze non può cambiare senza una differenza visibile, non che il TCB sia stato revisionato. Una nostra revisione di un crate non l'abbiamo scritta.

SNTP (T1) è in questo senso una piccola storia di sicurezza: è opzionale, solo verso server IPv4 privati, con salto massimo e con la condizione che le fonti concordino (mediana, maggioranza entro un secondo). Un orologio che chiunque sul percorso può spostare non è un orologio di cui ci si possa fidare per la validità dei certificati.

Sul Mac: aarch64 nativo e x86_64 in emulazione

Sviluppiamo su un Mac, e questo ha due modi di eseguire lo stesso codice, molto diversi tra loro.

La regola è semplice: i numeri sotto TCG sono emulazione e non li citiamo come prestazioni. Le prestazioni x86 le misuriamo solo su un VPS vero. Per questo i numeri crittografici qui sopra vengono dal VPS Contabo, non dal Mac.

Lezioni

• Misurate su una macchina reale prima di ottimizzare. Il primo approccio è stato ottimizzare ciò che pensavamo fosse lento; solo la diagnostica sul VPS ha mostrato 1,2 ms e dove va a finire esattamente il tempo.
• Il sovraccarico è una funzionalità a sé. Un sistema veloce sotto carico può crollare oltre di esso; rifiutare deve costare meno che accettare.
• Il profilo sorprende. Il maggior guadagno singolo per i messaggi piccoli non era nella crittografia, ma nella copia della memoria.
• Un disco senza file system richiede più lavoro, non meno. Ciò che un file system di solito offre (allineamento, crescita, discard, copie, verifiche) dobbiamo scriverlo e verificarlo da soli, ogni passo con iniezione di errori.
• Onestà nei numeri. Le misure di memoria su un VPS condiviso variano fino a 10 volte tra le esecuzioni e non dicono nulla sul codice, quindi non le riportiamo. I numeri crittografici sono stabili entro circa il 10%.
• La velocità di sviluppo non è maturità. Test e ADR crescono insieme al codice, ma quattro giorni non sono un vero esercizio.

Che cosa viene dopo

• H6: SQLite isolato a livello EL0, così che un errore nel database non apra il kernel.
• H7: il resto della sicurezza del tempo (NTS e gestione dei salti); SNTP è solo il primo passo.
• X11: confronto con Linux e Mosquitto sullo stesso VPS, solo allora ha senso parlare di velocità relativa.
• Rilascio: la prima pubblicazione per VPS (KVM), con artefatti firmati e istruzioni.
• Dopo il rilascio: bare metal (da X12 a X16), IOMMU e Secure Boot, e cifratura del disco.

Il codice è su github.com/zeljan-alduk/urMQTT, e docs/PROGRESS.md resta l'unica fonte di verità su ciò che funziona davvero. Pre-alfa, come prima; segnalazioni di errori e di sicurezza secondo le indicazioni in SECURITY.md sono benvenute.

Così è nato urMQTT: un unikernel che è un broker MQTT. Kernel, TCP/IP, TLS 1.3, MQTT e un database integrato in un unico programma binario Rust che si avvia da un solo ISO. Nessun processo, nessuna chiamata di sistema, nessuna shell. La prima piattaforma su cui viene costruito e collaudato è aarch64, e lo stesso codice è in cammino verso x86_64, tramite UEFI e BIOS classico, e verso l'hardware reale: l'obiettivo è un solo ISO che si avvii su tutti. Il progetto è open source con licenza MIT o Apache 2.0, e in questo articolo vogliamo mettere per iscritto a che punto siamo, com'è fatto al suo interno e che cosa abbiamo imparato lungo la strada.

Che cosa significa esattamente "unikernel"

Un broker tradizionale è un programma che gira su un sistema operativo. urMQTT non ha alcun sistema operativo sotto di sé: si avvia da solo attraverso il firmware UEFI e il bootloader Limine, imposta le proprie tabelle delle pagine, programma il controller degli interrupt e il timer, individua i dispositivi virtio tramite PCIe, ottiene un indirizzo via DHCP e ascolta su una sola porta. Tutto ciò che di solito fanno kernel, driver, stack di rete e applicazione, qui è un unico ELF eseguito a livello EL1.

Il confronto con un'installazione tipica parla da sé:

Le priorità sono, in quest'ordine: sicurezza, scalabilità, prestazioni multicore, ingombro ridotto e installazione immutabile. Quando due obiettivi entrano in conflitto, prevale quello che sta più in alto nell'elenco.

A che punto siamo

Il progetto è in fase pre-alfa, ma sono state chiuse diciassette milestone di sviluppo, da M0 a M17. Oggi urMQTT serve MQTT 3.1.1 su TLS 1.3 con certificati client obbligatori e conserva lo stato in SQLite su disco raw. In breve, ciò che già funziona:

• Kernel: vettori di eccezione propri con report decodificati, tabelle delle pagine proprie con W^X applicato, pagine di guardia, PAC e BTI dove il processore li supporta, GICv3 e GICv2, timer generico, SMP fino a 64 core.
• Rilevamento dell'hardware da DTB o ACPI in un'unica descrizione della piattaforma, con risultato identico da entrambe le fonti.
• Driver: PCIe ECAM, MSI-X, virtio-net, virtio-blk, virtio-scsi e virtio-rng, più un CSPRNG inizializzato con entropia hardware.
• Rete: DHCPv4, ARP, ICMP e IPv4 rigoroso, tutti propri, e poi un TCP proprio solo lato server: SYN cookie, timer wheel gerarchica, NewReno, coalescenza degli ACK, nessuno stato TIME_WAIT.
• TLS: solo TLS 1.3, mTLS obbligatorio, identità del dispositivo ricavata dal CN o dal SAN URI; l'handshake è gestito da rustls, dopodiché subentra un livello di record proprio con AES-128-GCM e ChaCha20-Poly1305. Ripresa della sessione con ticket PSK, lista di revoca, controllo di ammissione già in fase di handshake.
• MQTT: codec zero-copy, sottoposto a fuzzing e testato con veri client mosquitto; QoS 0 e 1, wildcard, messaggi retained, last will (LWT), sessioni persistenti, ACL limitate a devices/{id}/#, limiti di frequenza per dispositivo.
• Archiviazione: SQLite dentro il kernel tramite un VFS su disco raw, in modalità WAL, con verifica dell'integrità all'avvio; registro dei dispositivi, revoche, messaggi retained, sessioni persistenti con code di messaggi per i dispositivi offline; per ogni core un log di telemetria separato con CRC per record e ripristino dopo un crash.
• Esercizio e sorveglianza: timer watchdog per i gestori, health check, logging limitato, syslog e statsd su UDP, un'ammissione che resiste alle tempeste di riconnessioni.
• Distribuzione: build ripetute bit per bit e verificate in CI, ISO e immagine disco GPT raw, firme minisign, istruzioni per KVM, Proxmox e Hetzner.

Ogni passo è contrassegnato dalla milestone che lo ha portato, e il file docs/PROGRESS.md nel repository è l'unica fonte di verità su ciò che funziona davvero.

L'architettura in tre immagini

L'intera progettazione è descritta in docs/ARCHITECTURE.md, mentre le ragioni di ogni decisione importante sono registrate come ADR in docs/DECISIONS.md. Ecco una panoramica.

Gli strati

Dall'alto verso il basso: il broker (sessioni, albero dei topic, QoS, messaggi retained, will, ACL, limiti), il codec MQTT, TLS, TCP, lo strato di rete e infine i driver. Accanto a questo percorso principale si trova l'archiviazione (SQLite e log di telemetria), e sotto a tutto la gestione della memoria, il rilevamento della piattaforma e la configurazione, compilata in costanti al momento della build, insieme al certificato CA, al certificato del server e alla chiave incorporati. L'hypervisor con i dispositivi virtio è l'unica cosa che resta fuori dall'immagine.

Un thread per core, nessuno stato condiviso

Ogni core dati esegue un proprio ciclo con il proprio stack TCP, i propri stati TLS, una porzione del broker (sessioni e albero dei topic), la cache dell'heap e la partizione di telemetria. I core non condividono alcuno stato mutabile, ma soltanto anelli limitati e privi di lock, uno per ogni coppia ordinata di core. Il core con il numero più alto esegue SQLite e nient'altro.

La scheda di rete ha oggi una sola coppia di code, gestita dal core 0. Questo smista ogni flusso MQTT su uno dei core di lavoro in base all'hash Toeplitz della sua quadrupla e invia ciò che i core di lavoro restituiscono. Una sessione vive sul proprio core di appartenenza, determinato dall'hash dell'identificatore del client, così che take-over, will e persistenza non attraversino mai i core. Una connessione che atterra su un altro core vi mantiene il proprio TCP e TLS, ma inoltra l'MQTT in chiaro al core di appartenenza con un controllo di flusso basato su crediti. Ogni messaggio instradato viene inoltre distribuito alle altre porzioni del broker, ciascuna delle quali tiene una replica dei messaggi retained.

Tre regole tengono insieme questo modello. Elaborazione completa sullo stesso core: un pacchetto ricevuto viene elaborato per intero su un solo core, dal TCP alla decifratura TLS sul posto, dal parsing MQTT all'instradamento fino alla risposta cifrata, senza code di task e senza copie nei buffer applicativi. Polling adattivo: sotto carico le code di ricezione vengono interrogate attivamente, mentre a riposo il core torna agli interrupt e a WFI; i gestori degli interrupt si limitano a confermare l'interrupt e a segnalare il lavoro. Watchdog: un tick da 10 ms per core intercetta i gestori che superano il proprio budget.

La vita di un PUBLISH

Il dispositivo invia un record TLS. La scheda di rete lo consegna al ciclo del core tramite un descrittore, senza copie. Il ciclo verifica il TCP, decifra il TLS sul posto e analizza l'MQTT da un buffer preso in prestito, poi controlla in memoria l'ACL, il limite di frequenza e il percorso nell'albero dei topic. Se un altro core è interessato a quel topic, riceve un messaggio di instradamento con il riferimento al payload e l'identificatore del topic; il database riceve un record di telemetria o l'aggiornamento di un messaggio retained, in batch. La risposta PUBACK viene cifrata direttamente nel buffer in uscita e unita al TCP ACK, così al dispositivo parte un solo segmento. Per l'altro core il messaggio costa una cifratura per sottoscrittore al momento dell'invio.

Quanto costa una connessione

L'obiettivo è al massimo 512 byte per connessione TLS inattiva, con la tensione verso i 256. Finché la connessione è a riposo, per essa non viene trattenuto alcun buffer: i dati ricevuti vengono elaborati direttamente dal frame di rete, e i buffer per invio, record e MQTT esistono solo finché qualcosa è incompleto o non confermato. Il kernel misura da sé anche questo: contatori esatti dell'heap, in byte richiesti e in blocchi occupati, registrati ogni dieci secondi come heap oltre il livello di base per connessione aperta.

Misurato sotto HVF con quattro core virtuali, di cui tre di lavoro, con ogni dispositivo che mantiene una connessione mTLS e una sottoscrizione QoS 1, compreso l'arrotondamento dell'allocatore:

Il pool dei frame di rete è fisso, di circa 2 MiB, ovvero circa 200 B per connessione con diecimila connessioni e circa 2 B con un milione. Oltre questo non siamo riusciti a misurare: il networking utente di QEMU su macOS ha smesso di accettare connessioni a 10 197, più o meno al limite di 10 240 descrittori del processo QEMU. La cifra scende man mano che le parti fisse si ripartiscono su più connessioni, quindi non cresce con il loro numero.

Il modello di sicurezza

La sicurezza è la prima priorità e vince tutti i conflitti con gli altri obiettivi. Il modello è composto da più strati:

• Una sola porta. TCP 8883, solo TLS 1.3, certificati client obbligatori firmati dalla CA incorporata nell'immagine. L'identificatore del client MQTT deve coincidere con l'identificatore del dispositivo presente nel certificato.
• Nessun punto d'ingresso. Nessuna shell, nessun input da console, nessun SSH, nessuna API di amministrazione, nessun codice dinamico, nessun SQL raggiungibile dalla rete e nessun file system.
• Sicurezza della memoria. Rust, con forbid(unsafe_code) nei crate di protocollo; ogni blocco unsafe ha un commento // SAFETY: verificato da un lint, e sull'input esterno non ci sono panic: clippy nei crate del percorso dati vieta unwrap, expect, l'indicizzazione e panic!.
• Mitigazione dello sfruttamento. W^X è applicato tramite la codifica dei descrittori e il bit SCTLR_EL1.WXN, e viene riverificato a ogni avvio. Dopo l'avvio le tabelle delle pagine sono di sola lettura, senza alias scrivibili. La metà inferiore dello spazio di indirizzamento è esclusa. Ogni stack ha pagine di guardia e le eccezioni girano su uno stack separato. PAC e BTI si attivano quando il processore li supporta, e lo verificano gli smoke test.
• Resistenza agli abusi. SYN cookie; l'ammissione rifiuta le nuove connessioni, prima di qualsiasi crittografia, quando l'heap è basso, quando il database è in ritardo, quando ci sono troppi handshake in corso per core o per indirizzo di origine, oppure quando la frequenza degli handshake è troppo alta. Limiti di frequenza per dispositivo, code limitate, finestra TCP legata alla contropressione del broker, logging limitato, watchdog e health check.
• Immutabilità. Configurazione, CA e chiave del server sono incorporate nell'immagine. Cambiare qualsiasi cosa significa una nuova immagine.

Il modello delle minacce è descritto in docs/SECURITY.md.

Archiviazione senza file system

I dati risiedono su un disco separato, virtio-blk o virtio-scsi, privo di file system. Il layout è minimale e proprio:

LBA 0      [ superblocco: magic · versione del layout · uuid · tabella delle regioni · CRC-32C ]
LBA 8, 16  [ tabella delle dimensioni dei file, slot A/B (vince il più recente valido) ]
LBA 64     [ database principale SQLite ½ ][ WAL SQLite ⅛ ][ journal 1 MiB ][ log di telemetria: 8 partizioni … ]
ultimi 4 KiB [ area per l'autoverifica del dispositivo a blocchi all'avvio ]

SQLite (3.54.1 incluso nel repository, con verifica dell'hash in fase di build) è compilato nel kernel con clang, senza libreria standard, e usa un heap memsys5 di dimensione fissa. Il suo VFS mappa tre file fissi su regioni del disco. Funziona in modalità WAL con locking_mode=EXCLUSIVE, quindi non gli serve un indice in memoria condivisa, e con synchronous=FULL; se quick_check rileva un errore all'avvio, il sistema si ferma in modo sicuro. Nel database si trovano il registro dei dispositivi, le revoche, i messaggi retained e le sessioni persistenti con le code di messaggi QoS 1 per i dispositivi non connessi.

Il core del database, quello con il numero più alto, esegue SQLite e nient'altro. Il piano dati gli invia le variazioni di stato tramite un anello SPSC privo di lock; lui le raggruppa in un'unica transazione ogni 5 ms o ogni 512 operazioni e restituisce le conferme con un secondo anello. Un disco vuoto viene formattato al primo avvio; in ogni altro caso non si formatta mai sopra ciò che esiste.

La telemetria segue un altro percorso. Ogni PUBLISH accettato sui topic indicati in storage.telemetry_topics finisce nella partizione del log di telemetria del proprio core: un anello di segmenti con CRC per record, salato con la sequenza del segmento, in modo che i vecchi giri dell'anello non ricompaiano mai. I core passano i record al database con un anello proprio, senza copie, e questo li scrive ogni 5 ms o ogni 256 KiB. All'avvio il ripristino conserva ogni record scritto, tronca la coda incompleta e riprende in un nuovo segmento. La conservazione avviene per dimensione, attraverso l'anello, e per età, attraverso retention_days. Lo abbiamo verificato con un milione di record e con kill -9 nel bel mezzo della scrittura.

I numeri

Lo strumento di carico in tools/loadgen fa tre cose: una tempesta di handshake TLS 1.3 con mTLS e CONNECT, connessioni di lunga durata con PINGREQ che pubblicano telemetria ogni secondo, e tempeste di riconnessioni. make bench su un Apple M4 Pro sotto HVF dà:

Il dato nel guest, dove client e server si trovano nella stessa macchina virtuale e ogni core di lavoro opera per conto proprio, mostra che il piano dati scala in modo lineare. Il dato di rete è limitato dal networking utente a thread singolo di QEMU, non dal guest; anche questo è registrato come ADR-032.

Le tempeste di riconnessioni le proviamo facendo connettere tutti i dispositivi contemporaneamente, ripetendo con attesa i tentativi rifiutati e facendoli poi cadere tutti senza DISCONNECT. Il parametro heap_limit_mb= in modalità di sviluppo induce l'ammissione a ritenere l'heap più piccolo di quanto sia, così una tempesta più grande dell'heap si può provare con pochi socket. In uno di questi round con 3 000 dispositivi, 1 368 si sono connessi in 36 secondi e 5 619 tentativi sono stati rifiutati in modo ordinato, con un limite di 8 MiB; dopo la tempesta la memoria è tornata al livello iniziale.

Come lavoriamo

Il progetto è guidato da una specifica scritta, PROMPT.md, con il piano delle milestone, e ogni milestone si chiude con lo stesso rituale: make check e make smoke verdi, un commit con l'etichetta M<n>, una voce in docs/PROGRESS.md e un ADR per ogni decisione non ovvia. Le regole sono brevi e non negoziabili: nessun panic sull'input esterno, unsafe solo nei crate hardware e FFI e sempre con un commento, nessuna allocazione sul percorso caldo, un commento per ogni ordinamento delle operazioni atomiche, ogni limite proviene dalla configurazione, e le parti provvisorie intenzionali falliscono in modo rumoroso.

La CI fa più di quanto riusciremmo a fare a mano: fmt, clippy per l'host e per aarch64-unknown-none, typos, actionlint e shellcheck; test su Linux e macOS su arm64; build del kernel per la configurazione di sviluppo e di produzione con la dimensione dell'ELF nel riepilogo; avvio sotto QEMU con tutti gli scenari degli smoke test e salvataggio dei log seriali; cargo-deny per advisory, licenze e sorgenti; un minuto di fuzzing per ciascuno degli undici target, e di notte dieci minuti per target con corpus in cache. A ciò si aggiungono CodeQL, OpenSSF Scorecard, Dependabot e un rilascio con provenienza SLSA. Ogni action di terze parti è bloccata sull'SHA completo del commit.

La riproducibilità la prendiamo alla lettera: make repro compila HEAD due volte in alberi di lavoro puliti e confronta ELF, ISO e immagine raw byte per byte. I rilasci sono firmati con minisign e gli artefatti si possono verificare con gh attestation verify. L'immagine di produzione contiene la chiave privata del server, quindi l'ISO stesso è un segreto; le immagini allegate ai rilasci su GitHub sono di sviluppo, con chiavi temporanee, e servono solo per fare prove.

Che cosa abbiamo imparato

Alcune lezioni che hanno cambiato il piano:

• Un TCP proprio alla fine è valso la pena. Il prototipo girava su smoltcp e ci è stato utile fino a M13. Ma un server che mantiene centinaia di migliaia di connessioni non ha bisogno di un TCP lato client: servono SYN cookie, una timer wheel e uno stato di 96 byte. In M14 abbiamo sostituito smoltcp con uno stack proprio solo lato server, con test di perdita simulata e fuzzing dei segmenti.
• La memoria va misurata dall'interno. Le stime per connessione erano inutili finché il kernel non ha iniziato a contare da sé l'heap in blocchi dell'allocatore anziché in byte richiesti. Solo allora abbiamo visto dove vanno davvero a finire i 512 byte e siamo scesi a 494.
• Lo strumento di test fa parte del prodotto. Il limite maggiore non era il kernel, ma il networking utente di QEMU e il numero di porte effimere sul computer di sviluppo. Per centomila connessioni e oltre servono vmnet-shared su macOS oppure Linux con KVM, interfaccia tap e più indirizzi client.
• SQLite senza sistema operativo è possibile, ma solo a condizioni rigorose: heap fisso, lock esclusivo senza memoria condivisa, un VFS che non conosce i file, e un'ammissione che non lascia accumulare ritardo al database.
• Le tempeste di riconnessioni sono la normalità, non l'eccezione. Quando la rete mobile cade e poi torna, migliaia di dispositivi bussano nello stesso istante. Per questo l'ammissione rifiuta la connessione prima di qualsiasi crittografia, e ogni connessione rifiutata costa quasi nulla.

Che cosa viene dopo

Il lavoro successivo a M17 è pianificato in tre direzioni, e l'ordine tra di esse è registrato in docs/PLAN.md. Nulla di quanto segue è ancora stato realizzato.

• Un solo ISO per più piattaforme. Lo stesso file urmqtt-<env>-<versione>.iso e un'unica immagine GPT raw che si avviano su UEFI aarch64, UEFI x86_64 e BIOS x86_64, in macchine virtuali e su hardware reale, a partire da un PC Intel. Sempre un appliance con tutto al proprio interno, riproducibile e firmato.
• Disco raw, senza file system. Una specifica del formato a livello di byte, lo strumento host urmqtt-disk che condivide i parser con il kernel, allineamento delle regioni a 1 MiB, crescita del disco con i dati, discard per i dischi thin provisioned, snapshot A/B del database, verifica dei bit e, a scelta, cifratura AES-256-XTS con AES hardware.
• Sicurezza dimostrabile. Revoca e lista dei dispositivi consentiti a runtime tramite un canale di controllo firmato, senza una nuova immagine; test differenziali e di conformità del TLS e del TCP propri; KASLR, protezione dello stack, kCFI, MTE e un allocatore rinforzato; SQLite isolato a livello EL0; Secure Boot; SBOM e cargo-vet; e infine un pacchetto per la revisione esterna.

Le piattaforme che offrono soltanto dispositivi non virtio, come AWS ENA o Azure MANA, per ora non sono supportate. Raspberry Pi 4 e 5 come host KVM, Hetzner CAX e Oracle Ampere A1 sono documentati e supportati nel codice, ma non sono ancora stati provati su un servizio reale.

Provatelo

Il repository si trova su github.com/zeljan-alduk/urMQTT. Con Rust e la toolchain nightly fissata, QEMU, make certs, make run e un client mosquitto bastano per il primo PUBLISH su mTLS sul proprio computer. L'avvertenza iniziale vale anche alla fine: questo è pre-alfa, e tutto ciò che funziona è scritto in docs/PROGRESS.md. Segnalazioni di errori, domande sulla progettazione e segnalazioni di sicurezza secondo le indicazioni in SECURITY.md sono benvenute. Vi aggiorneremo qui a ogni prossima milestone.

Su questo blog annotiamo ciò che abbiamo imparato lungo la strada. Non testi di marketing, ma appunti concreti: cosa è andato storto, come l'abbiamo risolto e cosa faremmo diversamente oggi.

Di cosa scriveremo

• Bigliettazione nel trasporto pubblico. Carte contactless, moduli SAM, funzionamento offline e tutto ciò che un terminale deve sopportare in un veicolo che vibra dodici ore al giorno.
• App mobili sul campo. Android e Flutter su dispositivi che non sono telefoni comuni: con lettori di carte, stampanti e batterie che devono reggere un intero turno.
• Backend e monitoraggio della flotta. Come sapere che un dispositivo a bordo ha un problema prima che lo segnali l'autista.
• Hardware. Dal prototipo sul banco alla scheda che va in produzione di serie, e tutti gli errori nel mezzo.
• Modelli di IA in locale. Dove i modelli sul proprio hardware hanno senso, e dove il cloud e un'API sono semplicemente la scelta migliore.

Come scriveremo

In modo breve e concreto, con codice e numeri dove li abbiamo. Pubblicheremo quando avremo qualcosa da dire, non secondo un calendario. Gli articoli sono scritti in croato e tradotti in tutte le lingue di questo sito; potete seguirci anche via RSS.

Se vi interessa un argomento o state lavorando a un problema simile, scriveteci a info@aldo.tech.