Il Journal di NoWayOS

Entra React, esce Rust

2026-11-13T00:00:00Z

Le interfacce moderne si progettano in React. Così moltissimi dispositivi dedicati, dai pannelli di controllo alle biglietterie automatiche, si portano dietro un intero motore di browser, uno dei programmi più grandi e più attaccati che esistano, per disegnare qualche pulsante e le parole “Touch Start to begin”.

Volevamo il flusso di design moderno senza il browser. Così abbiamo costruito il Screen Compiler.

Scriva la schermata in React

I Suoi designer e sviluppatori front-end tengono i loro strumenti: componenti, props, design token, il loro editor. Scrivono la schermata in TSX (questa è abbreviata da una delle schermate di test del Screen Compiler):

<Column gap={SPACE_SM} padding={SPACE_LG}>
  <Text id="title">Welcome</Text>
  <Text>Touch Start to begin.</Text>
  <Spacer />
  <Button id="start" onPress={onStart}>Start</Button>
</Column>

Consegni semplice Rust

In fase di build, sulla Sua macchina o in CI, il Screen Compiler lo trasforma in Rust per il runtime dell'interfaccia utente di NoWayOS:

let n1 = b.text("Welcome")?; // welcome.tsx:17:9 <Text>
let n2 = b.text("Touch Start to begin.")?; // welcome.tsx:18:9 <Text>
let n4 = b.spacer(None)?; // welcome.tsx:20:9 <Spacer>
let n5 = b.button("Start", actions::START)?; // welcome.tsx:21:9 <Button>

Ogni riga rimanda al TSX da cui proviene. Il dispositivo riceve quel codice e nient'altro: nessun motore JavaScript, nessun browser, nessuna pagina web da attaccare. Il Screen Compiler stesso non viene mai consegnato.

Esatto, o niente

Un convertitore che tira a indovinare è un convertitore di cui non ci si può fidare. Il Screen Compiler converte con esattezza il suo sottoinsieme dichiarato di TSX e rifiuta tutto il resto indicando file, riga e colonna. Non approssima mai. Il Rust che scrive non ha unsafe, né unwrap, né panic.

Poi ogni schermata convertita viene disegnata dal renderer di NoWayOS e confrontata, pixel per pixel, con la sua immagine approvata. Se si sposta un solo pixel, la build lo dice.

A che punto è

Il Screen Compiler è in sviluppo: il suo primo sottoinsieme è costruito e il successivo è in corso. È open source con licenza MIT, su GitHub accanto a NoWayOS. Se il Suo team progetta in React e costruisce dispositivi che contano, ci farebbe piacere sentirLa.

Il backup che non era una copia

2026-11-13T00:00:00Z

Tutti sanno che bisogna avere un backup. Meno persone fanno la scomoda domanda successiva: un backup di che cosa, esattamente?

Cinque allarmi

Il 20 luglio 1969 il modulo lunare di Apollo 11 era a pochi minuti dalla superficie della Luna quando il suo computer di guida lanciò un allarme su cui l'equipaggio dovette chiedere al controllo missione. Poi un altro. Cinque in tutto, nell'ultimo tratto della discesa.

Il computer era sovraccarico. Ciò che fece subito dopo è uno dei grandi capolavori di ingegneria di questa storia: ogni volta si riavviò, lasciò cadere il lavoro che poteva aspettare e riprese subito quello che non poteva. L'allunaggio proseguì.

Questa è la parte che raccontano tutti. La parte che vale la pena raccontare dopo accadde il giorno seguente.

Il secondo sistema

Il modulo lunare portava un secondo sistema di guida, e non era una copia di riserva del primo. Lo costruì un'altra azienda, su un altro principio. Il sistema principale manteneva l'orientamento con una piattaforma che ruotava liberamente su sospensioni cardaniche. Il secondo non aveva alcuna sospensione cardanica: i suoi sensori erano imbullonati direttamente al veicolo, e stabiliva dove fosse l'alto con l'aritmetica.

Era lì per riportare l'equipaggio in orbita se il sistema principale si fosse mai fermato. Durante l'allunaggio non fu chiamato in causa.

Poi, durante la risalita per agganciarsi al modulo di comando, una serie di manovre portò la piattaforma del sistema principale nell'unica posizione che una piattaforma cardanica non sa gestire, e questo perse il suo riferimento di assetto. L'equipaggio passò al secondo sistema per tenere stabile il veicolo, e si agganciò.

Il secondo sistema non avrebbe potuto guastarsi allo stesso modo. Non aveva quel pezzo.

Due uguali

Ora l'altra storia. Nel 1996 il primo Ariane 5 decollò con due unità di riferimento inerziale a dirgli da che parte stava puntando: una in funzione, una di riserva. Erano identiche, fino al software.

Dopo trentasette secondi, un numero dentro quel software divenne troppo grande per lo spazio che gli era riservato. L'unità di riserva si fermò. L'unità in funzione, che eseguiva lo stesso codice sullo stesso volo, si fermò anch'essa. Il rapporto della commissione d'inchiesta è pubblico, ed è netto: non c'era nulla a cui passare, perché il backup aveva già fatto la stessa fine.

Due copie. Un guasto. Niente più.

Come lo chiamano gli ingegneri

Un guasto che mette fuori uso insieme un sistema e la sua riserva è un guasto di causa comune. La difesa è la ridondanza diversificata: un secondo sistema costruito in modo abbastanza diverso che ciò che ferma il primo non si trovi nel secondo.

Lo Space Shuttle volava così. Quattro dei suoi computer di volo eseguivano il software di un'azienda; il quinto eseguiva software scritto separatamente da un'altra. Quattro copie proteggono da un computer che si rompe. Non proteggono da un programma sbagliato, perché lo stanno eseguendo tutti e quattro.

Non è gratis. Il primo lancio dello Shuttle fu annullato quando il quinto computer e gli altri quattro non riuscirono a mettersi d'accordo sull'ora. Due progetti costano più lavoro di uno, e bisogna farli incontrare.

Dove entra in gioco NoWayOS

La maggior parte dei dispositivi dedicati esegue oggi uno fra pochissimi sistemi operativi generici. E così i loro backup. Quando salta fuori un difetto in un motore di browser, in un desktop o in un kernel da decine di milioni di righe, o quando esce un aggiornamento difettoso, salta fuori ovunque giri quel software, lo stesso giorno.

Un dispositivo NoWayOS è diverso al suo interno. Il suo kernel è seL4, circa 10.000 righe. Tutto ciò che è nostro al di sopra è scritto in Rust. Non ha motore di browser, né desktop, né shell, quindi un difetto in uno di questi non c'è.

Questo significa che NoWayOS non deve sostituire ciò che Lei già usa per essere utile. Può stargli accanto: un secondo modo di svolgere un compito essenziale, costruito su un altro principio.

Che cosa non fa

La diversità ha dei limiti, e preferiamo che li senta da noi.

Dà a un dispositivo NoWayOS guasti diversi, non nessun guasto. Non fa nulla per ciò che due sistemi condividono: l'alimentazione, la rete, i servizi alle loro spalle, o un errore su ciò che il compito doveva essere. E alcune delle parti open source di NoWayOS sono usate anche in altro software, ed è per questo che ogni immagine elenca ogni componente che contiene, così che Lei possa leggere che cosa ha in comune con il sistema accanto.

NoWayOS è in sviluppo, quindi questo è un ruolo per cui è progettato, non uno che abbia già ricoperto. La pagina Sicurezza dice su che cosa poggia.

Gli ingegneri di Apollo non portarono un secondo sistema perché si aspettavano che il primo si guastasse. Lo portarono perché non potevano dimostrare che non si sarebbe guastato, e fecero in modo che ciò che avesse fermato il primo non trovasse nulla di familiare nel secondo.

Attacchiamo la nostra build a ogni modifica

2026-11-13T00:00:00Z

Ecco una domanda scomoda per qualsiasi test di sicurezza: è mai fallito? Un test che non è mai fallito potrebbe passare perché il sistema è solido, oppure perché il test non vede proprio nulla. Da fuori, le due cose sono identiche.

Perciò NoWayOS non si limita a testare la propria sicurezza. La attacca, a ogni modifica, e verifica che gli attacchi vengano fermati.

Allungare la mano su ciò che non è proprio

Ogni parte di un sistema NoWayOS gira nel proprio compartimento su seL4, con soltanto ciò che le è stato concesso. I test di isolamento mandano apposta delle sonde oltre quei confini. Una legge un indirizzo che non le è mai stato dato. Una scrive su una pagina che può soltanto leggere. Una, che ha esattamente ciò che ha l'interfaccia utente, prova a scrivere sulla pagina di controllo del display, che l'interfaccia può soltanto leggere. Un'altra, che ha esattamente ciò che ha il client di rete, prova a scrivere nella memoria del driver di rete.

seL4 deve fermarle tutte, e una parte estranea deve continuare a girare, intatta.

Un test costruito per fallire

Poi arriva il colpo di scena. Accanto al test di isolamento dell'interfaccia utente c'è una variante con una concessione allargata apposta: alla controfigura dell'interfaccia viene data la pagina privata del display. Il test di quella variante deve fallire. Se mai passasse, il test di isolamento sarebbe cieco, e la build lo direbbe.

La stessa idea attraversa il resto dei controlli. Ogni decoder dei messaggi tra le parti ha dimostrazioni limitate, dal model checker Kani, che non va mai in panic, in overflow né legge fuori dai limiti. I controlli a mutazione poi rompono deliberatamente i decoder, per mostrare che le dimostrazioni se ne accorgono. Ogni parser di input esterno è sottoposto a fuzzing con dati ostili.

Tutto questo fa parte di make ci, il controllo che ogni modifica deve superare. I test di isolamento girano ogni volta; una dimostrazione o una sessione di fuzzing viene ripetuta ogni volta che cambia il codice che copre.

Controlli fuori portata

Un controllo è forte solo quanto la mano che può modificarlo. Perciò i controlli che ogni contributo a NoWayOS deve superare sono definiti in Defence Agent, un repository pubblico a sé. Una pull request che tocca un controllo viene segnalata al maintainer.

Defence Agent mette alla prova se stesso allo stesso modo: venti pull request truccate, ciascuna con dentro qualcosa che a un revisore potrebbe sfuggire. C'è testo nascosto da destra a sinistra in un commento, una lettera scambiata con la sua sosia cirillica, una dipendenza prelevata direttamente da un repository git, un workflow che eseguirebbe codice non attendibile. Ognuna deve essere scoperta, mentre tre vere modifiche del passato devono passare.

Prove, non aggettivi

Niente di tutto questo rende un dispositivo “inattaccabile”. Niente lo fa, e non lo diremo mai. Ciò che Le dà sono prove: una traccia di ciò che è stato tentato, di ciò che è stato fermato, e il comando che lo mostra. Legga le prove di un'immagine reale, oppure i controlli stessi.

Cosa può promettere una dimostrazione

2026-11-13T00:00:00Z

Di solito ci si fida del software perché è stato testato. Qualcuno ha pensato ai modi in cui poteva andare storto, li ha provati e lo ha visto cavarsela. Funziona bene, fino al caso a cui nessuno aveva pensato.

Una dimostrazione parte dall'altro capo. Non prova dei casi. Mostra, con la matematica, che un'affermazione vale per tutti.

Tutti i casi, non solo quelli provati

Prendiamo una piccola promessa: questo codice non legge mai oltre la fine del suo buffer. Un test può dargli mille input, o un miliardo, e riferire che nessuno lo ha fatto sbagliare. Una dimostrazione dice una cosa di tipo diverso: non c'è input che lo faccia sbagliare. Non ne è stato trovato nessuno, e non ne esiste nessuno.

Il prezzo è il rigore. Una dimostrazione richiede un enunciato esatto di ciò che il codice deve fare, la sua specifica, e un argomento che colleghi a essa ogni riga del codice. Per il software reale quell'argomento è troppo lungo perché una persona lo controlli a occhio. Così lo controlla un computer.

Verificata a macchina

Ecco cosa significa “verificata a macchina”. La dimostrazione viene scritta per intero, in un linguaggio che un programma chiamato assistente di dimostrazione sa leggere, e il programma controlla ogni passaggio con le regole della logica. Non si stanca a pagina novecento, e non si fida della parola di nessuno.

Le dimostrazioni di seL4 sono verificate così, in un assistente di dimostrazione chiamato Isabelle/HOL. Sono pubbliche, e chiunque può rieseguirle.

Cosa dicono le dimostrazioni di seL4

seL4 è il kernel su cui gira ogni sistema NoWayOS: circa 10.000 righe di codice, e l'unico codice con il controllo totale del dispositivo. La dimensione è il punto. Un argomento su diecimila righe si può portare a termine. Uno su decine di milioni, non ancora.

La seL4 Foundation espone le dimostrazioni a strati:

Il codice fa ciò che dice la specifica, e nulla di più. Ne segue un elenco di cose che il kernel non può fare: uscire da un buffer, seguire un puntatore nullo, perdere memoria, dividere per zero.
Il programma che gira corrisponde al codice che è stato dimostrato. In mezzo c'è un compilatore, perciò un'ulteriore dimostrazione ne controlla l'output.
Il kernel può tenere separate le parti di un sistema. Una parte non può modificare i dati di un'altra, né leggerli, né toglierle le risorse di cui ha bisogno, a meno che non le sia stato concesso il diritto di farlo.
Un sistema può avviarsi nello stato per cui è stato progettato, con esattamente le concessioni che la sua descrizione elenca.

Non tutti gli strati sono completi per ogni processore e ogni configurazione. È importante, e ci torneremo.

Cosa dà per scontato una dimostrazione

Una dimostrazione è ampia esattamente quanto il suo enunciato, e poggia sulle sue assunzioni. seL4 mette le proprie per iscritto: che l'hardware si comporti come dice il suo modello, che poche centinaia di righe del codice di più basso livello siano corrette, che il codice eseguito prima dell'avvio del kernel abbia fatto il suo lavoro. La dimostrazione di riservatezza non copre i tempi di esecuzione.

Non dice nulla sul fatto che la specifica chieda la cosa giusta, e nulla sul software sopra il kernel. Un kernel dimostrato isolerà fedelmente un programma che contiene un bug. Il bug è ancora lì. Semplicemente non può raggiungere nient'altro.

Non è una debolezza delle dimostrazioni. È ciò che le rende preziose: dicono con precisione cosa coprono, e così Lei sa con precisione cosa resta.

Dove si trova NoWayOS

Ecco la posizione, senza giri di parole. NoWayOS gira su seL4, ma oggi nessuna immagine NoWayOS rientra nelle dimostrazioni completate di seL4. NoWayOS usa la configurazione a criticità mista di seL4, le cui dimostrazioni per i nostri processori sono in corso. E le dimostrazioni di seL4 non hanno mai coperto il codice proprio di NoWayOS. Perciò non diciamo che NoWayOS è “verificato formalmente”, e non lo diremo.

Ogni immagine dice a che punto è. Un file accanto a essa elenca la configurazione del suo kernel, opzione per opzione, a fronte di quella che seL4 ha dimostrato. Sicurezza ne mostra uno vero.

Dimostrazioni più piccole, le nostre

Il codice di NoWayOS ottiene la sua garanzia per un'altra via: Rust, isolamento, revisione, test e dimostrazioni di un tipo più modesto.

Ogni decoder dei messaggi che passano tra le parti di un sistema ha dimostrazioni limitate, realizzate con un model checker chiamato Kani. Una dimostrazione limitata copre ogni input fino a una dimensione dichiarata, qui il record più lungo che un decoder accetta. Entro quel limite è una dimostrazione vera: nessun input manda il decoder in panic, in overflow o a leggere fuori dai limiti. Oltre il limite non dice nulla, ed è per questo che il limite è l'input più lungo che esista.

Poi rompiamo i decoder di proposito, per assicurarci che le dimostrazioni se ne accorgano. Una dimostrazione che non può fallire non vale più di un test che non può fallire.

La sua misura onesta

Una dimostrazione non rende nulla “inattaccabile”. Rende vera un'affermazione, in tutti i casi, sotto assunzioni che Lei può leggere. Conosca l'affermazione e le assunzioni, e saprà che cosa ha in mano.

Ecco perché NoWayOS è costruito sul kernel che le ha, e perché Le dice, immagine per immagine, fin dove arrivano.

Perché un dispositivo NoWayOS non ha una shell

2026-11-13T00:00:00Z

La maggior parte degli attacchi a un dispositivo dedicato non punta al compito che svolge. Punta al resto del computer su cui gira: la shell lasciata lì per la manutenzione, il servizio di accesso remoto che nessuno ha spento, il browser dietro l'applicazione, il desktop a un crash di distanza.

Quel “resto del computer” è ovunque. Il gateway che porta fuori le letture di un impianto idrico, il terminale nella sala di controllo di una rete elettrica, i dispositivi su cui conta un ospedale, il pannello sul fianco di una macchina, lo schermo nell'atrio di una stazione: molti eseguono un sistema operativo generico con un compito sopra, e tutto il resto ancora lì sotto, disattivato da impostazioni. La modalità kiosk è la versione più semplice. Ogni compromissione è qualcuno che trova l'unica impostazione sfuggita.

Lasciarlo fuori, invece

NoWayOS parte dall'altro capo. Un'immagine NoWayOS contiene l'applicazione del dispositivo, i driver che quell'applicazione usa e il microkernel seL4. L'elenco è tutto qui.

Non c'è una shell in cui finire, perché nessuna shell è mai stata inclusa. Nessun login remoto di cui indovinare la password. Nessun desktop verso cui evadere. Nessun motore di browser in attesa di una pagina malevola. Non si può sbagliare l'impostazione di un software che non c'è.

Tutto questo riguarda il sistema operativo. L'applicazione che ci gira sopra è un'altra cosa: può far accedere i propri utenti, e accedere ad altri sistemi, ogni volta che il suo compito lo richiede. Semplicemente, sotto non ha un sistema operativo a cui qualcuno possa accedere.

Lo chiamiamo Single Purpose OS: un computer che non ha altro da fare.

E ciò che c'è è sigillato

Lasciare fuori è metà del lavoro. Ogni parte che resta (la rete, lo schermo, l'input, l'applicazione) gira in un compartimento tutto suo, un dominio di protezione nei termini di seL4, e raggiunge solo ciò che le è stato concesso. Il driver di rete sposta pacchetti. Il driver del display disegna. L'applicazione parla con ciascuno tramite messaggi di dimensione fissa.

Ogni concessione è messa per iscritto in un file, un fatto per riga, e la build fallisce se il sistema e il file non concordano. È costruito perché un guasto in una parte resti in quella parte.

“Ma come lo si ripara senza una shell?”

È la prima domanda degli ingegneri, ed è giusta. Al sistema operativo di un dispositivo NoWayOS non si accede: non ha account, quindi non c'è nessuno con cui accedere. Si costruisce una nuova immagine e si sostituisce la vecchia. Oggi questo significa costruirla e caricarla sulla scheda; gli aggiornamenti firmati, verificati dal dispositivo e capaci di tornare indietro in sicurezza, sono progettati e in arrivo.

In cambio si ottiene un dispositivo che si avvia direttamente nel suo unico compito, con molto meno da correggere e molto meno da attaccare. Per i sistemi su cui si regge un paese, quello scambio è esattamente il punto.

Lo veda di persona

Le prove di un'immagine NoWayOS reale, il suo file delle concessioni, la sua distinta dei materiali e il suo registro di configurazione seL4, sono nella nostra pagina Sicurezza. Nessuna registrazione, nessuno script. Solo i file.