Meno, per scelta
Single Purpose OS
Un computer che non ha altro da fare.
Nessun browser. Nessun desktop. Nessuna shell. Nessun login. Un solo compito, costruito con il solo codice che gli serve, sigillato in compartimenti sul microkernel seL4 e scritto in Rust.
Gira già oggi in QEMU e su Raspberry Pi 5 · Open source, su GitHub
01 / Il principio del compito unico
Come ci siamo arrivati
Tutto è cominciato dai luoghi che non possono permettersi una giornata storta.
Non volevamo scrivere un sistema operativo. Volevamo proteggere alcuni dispositivi molto importanti, e sotto ognuno trovavamo sempre lo stesso problema.
- L'incarico
- Proteggere i sistemi su cui si regge un paese: i controlli che tengono accesa la corrente e pulita l'acqua, le reti da cui dipende un ospedale, i gateway che ne portano fuori i dati, i terminali delle sale di controllo e ogni dispositivo intorno a loro, fino allo schermo a cui si avvicina uno sconosciuto in un luogo pubblico. Ognuno aveva un solo compito. Ognuno faceva girare un sistema operativo costruito per svolgerne migliaia.
- L'inghippo
- Un sistema generalista arriva con tutto ciò che potrebbe mai servirgli: un browser, un desktop, una shell, i login, i servizi in background. Lo si blocca su un'unica app e tutto questo resta lì sotto, in attesa che qualcuno trovi la strada per tornarci. Ogni riga in più è qualcosa da correggere, e qualcosa da attaccare.
- La svolta
- Allora ci siamo fatti la domanda opposta: e se il dispositivo contenesse soltanto il suo unico compito? Siamo partiti da seL4, abbiamo scritto in Rust tutto il nostro codice che gli sta sopra, abbiamo sigillato ogni parte in un compartimento tutto suo e lasciato fuori il resto. Poi abbiamo messo per iscritto le prove, perché nessuno debba crederci sulla parola.
- La sorpresa
- Poi ci siamo guardati intorno. Il gateway nella sottostazione, il terminale nella sala di controllo, il pannello sul fianco di una pompa, l'apparato tra due reti, il display sulla parete della stazione: quasi ogni dispositivo dedicato ha un solo compito. Quella che era nata come un'armatura per le infrastrutture critiche si è rivelata un modo migliore di costruirli tutti. La chiamiamo Single Purpose OS.
Meno da attaccare. Molto meno da correggere. Nient'altro da fare.
Cosa intendiamo
Lo scopo è incorporato. Tutto il resto resta fuori.
Un Single Purpose OS è costruito per l'unico compito di un dispositivo, invece di essere costruito per far girare qualsiasi cosa e poi bloccato su una sola. Tre caratteristiche lo definiscono.
Costruito per un solo compito
L'immagine del dispositivo contiene la sua applicazione, i driver che quell'applicazione usa e il kernel. Non c'è nulla che potrebbe servire a un altro compito: nessun browser, desktop, shell, gestore di pacchetti o account utente.
Sigillato all'interno
Ogni parte (lo schermo, l'input, la rete, l'applicazione) gira in un compartimento tutto suo e raggiunge solo ciò che le è stato concesso. Tutto è progettato perché un guasto in una parte resti lì.
Mette le carte in tavola
È accompagnato dalle prove di ciò che contiene e di ciò che ogni parte può fare: ogni concessione messa per iscritto, ogni componente elencato e controlli che chiunque può eseguire.
Non è una modalità kiosk, che blocca un sistema generalista su un'unica app e lascia tutto il resto al suo posto. Non è un sistema operativo monoutente, che limita chi usa un computer, non cosa contiene.
Cosa non c'è
Meno software. Di proposito.
Quasi tutti i dispositivi dedicati fanno girare un sistema generalista con un'applicazione sopra, e tutto il resto ancora sotto. NoWayOS parte dal compito, aggiunge solo ciò che serve e lascia fuori il resto. Ecco la differenza.
| Un tipico dispositivo bloccato | Un dispositivo NoWayOS | |
|---|---|---|
| Browser web e motore JavaScript | Incluso | Non incluso |
| Desktop e sistema a finestre | Incluso | Non incluso |
| Shell e riga di comando | Incluso | Non incluso |
| Gestore di pacchetti | Incluso | Non incluso |
| Account utente e login | Incluso | Non incluso |
| Servizi in background | Incluso | Non incluso |
| Impostazioni per bloccare tutto | Incluso | Non incluso |
| Kernel | Generalista: decine di milioni di righe | seL4: circa 10.000 righe |
| Driver | Per l'hardware che potrebbe incontrare | Solo per l'hardware che usa |
| L'applicazione | Incluso | Incluso |
Screen Compiler
Le piace React? Anche a noi.
Servono interfacce ricche e moderne, costruite con il flusso di lavoro di sempre? Le schermate si scrivono in React. Lo Screen Compiler le trasforma in componenti Rust nativi che girano direttamente su NoWayOS: nessun browser, nessun JavaScript, nessuna pagina web da attaccare.
- Gli strumenti restano quelli: componenti, props, design token e l'editor di sempre.
- Mattoni veri: layout, testo, pulsanti, campi di testo, caselle di controllo, gruppi di opzioni, card, avvisi, barre di avanzamento e icone.
- Esatto o niente. Converte il suo sottoinsieme in modo esatto e rifiuta tutto il resto, indicando file, riga e colonna. Non tira mai a indovinare.
- Controllato al pixel. Ogni schermata convertita viene disegnata da NoWayOS e confrontata con la sua immagine approvata.
<Column gap={SPACE_SM} padding={SPACE_LG}>
<Text id="title">Welcome</Text>
<Text>Touch Start to begin.</Text>
<Button id="start" onPress={onStart}>
Start
</Button>
</Column>let n1 = b.text("Welcome")?; // welcome.tsx:17:9
let n2 = b.text("Touch Start to begin.")?;
let n5 = b.button("Start", actions::START)?;
let n0 = b.column(
ui::Layout::new()
.gap(super::tokens::SPACE_SM)
.padding(super::tokens::SPACE_LG),
&[n1, n2, n5],
)?;Versione abbreviata di una delle schermate di prova dello Screen Compiler e del Rust che genera.
Perché conta
Un solo compito. E basta.
Se un computer si costruisce per una cosa sola, lo si può costruire in modo molto diverso. Ecco cosa si guadagna.
Più sicuro
Non c'è modo di sfruttare ciò che non è mai stato incluso.
- Nessun motore di browser, nessun sistema a finestre, nessuna shell, nessun gestore di pacchetti, nessun account utente. Ciò che non è nell'immagine non può essere usato contro di essa.
- Lo schermo, l'input, la rete e l'applicazione vivono ciascuno in un compartimento sigillato tutto suo e raggiungono solo ciò che è stato loro concesso. È costruito in modo che un guasto in una parte resti in quella parte.
- Al suo cuore c'è seL4, che la seL4 Foundation definisce “il kernel di sistema operativo con il più alto livello di garanzia e il più veloce al mondo”.
- Rust dappertutto. Il codice unsafe sta solo in una manciata di crate revisionati, e la build fa rispettare l'elenco.
Più efficiente
Niente che giri a vuoto. Niente tra i piedi.
- Nessun servizio in background e nessun programma di aggiornamento per software che non si usa mai. Si accende e va dritto al suo unico compito.
- Ogni byte è deciso al momento della build: ogni parte riceve una quantità fissa di memoria e non può mai prenderne di più. La maggior parte del codice del dispositivo non alloca nulla, e anche il client TLS ha un budget fisso: se mai lo esaurisce, si ferma in modo pulito invece di crescere.
- Un'interfaccia nativa e nitida che ridisegna solo ciò che è cambiato, a suo agio su hardware economico come il Raspberry Pi 5.
Più comodo da sviluppare
Un linguaggio. Un container. Prima l'emulatore.
- Rust dai driver all'interfaccia utente.
- Le schermate si progettano in React. Lo Screen Compiler le trasforma in Rust nativo al momento della build: un'interfaccia moderna senza motore di browser e senza JavaScript sul dispositivo. Oppure si scrivono direttamente in Rust.
- Le toolchain, l'SDK seL4 Microkit e QEMU arrivano in un unico container di sviluppo, con le versioni fissate. Sulla propria macchina servono solo Podman e make, più Python per pilotare un Raspberry Pi.
Più facile da dimostrare
Ogni concessione per iscritto. Ogni immagine inventariata.
- Ogni capability che un sistema concede è elencata in un file, e la build fallisce se i due non concordano.
- Ogni immagine è accompagnata da una distinta base del software e da un registro della sua configurazione seL4.
- Dimostrazioni limitate che nessun decoder di messaggi va mai in panic, in overflow o legge fuori dai limiti, più fuzzing e controlli su licenze e avvisi di sicurezza: ognuno è un comando che chiunque può eseguire.
Quando tutto dipende da lui, che abbia un solo compito.
Alcuni dispositivi svolgono un lavoro troppo importante per dividerlo con le distrazioni: i controlli di una rete elettrica, il gateway in uscita da un impianto idrico, il terminale di una sala di controllo, il confine tra due reti. NoWayOS è progettato attorno al ruolo che ogni dispositivo deve svolgere, con le prove che aiutano a capire cosa c'è dentro.
Prove, non aggettivi
Si fa gli affari suoi. E si può controllare.
Un'affermazione sulla sicurezza vale quanto le prove che la sostengono. NoWayOS mette le prove per iscritto, e ognuna nasce da un comando che si può eseguire.
Ogni concessione per iscritto
Il file delle concessioni di ogni sistema elenca ogni priorità, regione di memoria, dispositivo, interrupt e canale che il sistema concede. La build fallisce se il sistema e l'elenco non concordano.
Test di isolamento che sanno fallire
I test di isolamento cercano di raggiungere ciò che non è stato loro concesso, e seL4 deve fermarli. Una variante con una concessione allargata di proposito deve fallire, a dimostrazione che il test ne è capace.
Ogni immagine inventariata
Una distinta base del software CycloneDX per ogni immagine: il kernel, il loader, ogni dominio di protezione e i crate che contiene, ciascuno con il suo hash.
Controlli fuori portata
I controlli che ogni contributo deve superare vivono in Defence Agent, un repository pubblico a sé, e una pull request che tocca un controllo viene segnalata al maintainer.
Alla luce del sole
Quattro progetti. Un compito ciascuno.
Tutti e quattro sono open source, sviluppati apertamente nell'organizzazione NoWayOS su GitHub. Li cloni, li compili e ne verifichi ogni riga di persona.
NoWayOS
Il Single Purpose OS.
Pattern di domini di protezione su seL4 e Microkit, messaggi tipizzati, driver, rete e un'interfaccia utente nativa, con il container di sviluppo e i controlli con cui si costruisce ogni repository NoWayOS.
- Stato
- In sviluppo
- Licenza
- MIT OR Apache-2.0
Screen Compiler
Si progetta in React. Si consegna Rust nativo. Nessun browser sul dispositivo.
Converte le schermate React, scritte in TSX secondo un sottoinsieme dichiarato, in Rust per l'interfaccia utente di NoWayOS. Gira al momento della build, sulla propria macchina o in CI, e non finisce mai sul dispositivo.
- Stato
- In sviluppo: il sottoinsieme v0 e le prime parti della v1
- Licenza
- MIT
Showcase
Applicazioni sicure da far girare su un Raspberry Pi.
Un kit per schermi self-service sicuri, un'applicazione di riferimento su cui costruire e un launcher di esempi con marchi di fantasia, in cui si avvia il Raspberry Pi 5.
- Stato
- In fase iniziale, non utilizzabile sul campo
- Licenza
- MIT OR Apache-2.0
Defence Agent
I controlli che ogni contributo deve superare, fuori dalla portata della pull request.
Ogni controllo di sicurezza che una modifica ai progetti aperti di NoWayOS deve superare, messo per iscritto con la minaccia a cui risponde e con chi può modificarlo, e l'agente che li esegue. Una pull request non modifica né fornisce mai ciò che la giudica.
- Stato
- Pubblico: i controlli sono messi per iscritto; l'agente e i suoi strumenti vengono dopo
- Licenza
- MIT OR Apache-2.0
Partner commerciali
Prodotti commerciali, costruiti su NoWayOS.
Adappt.ai, lo sponsor di NoWayOS, è il suo primo partner commerciale. Sta costruendo su NoWayOS due prodotti commerciali, entrambi in sviluppo.
Le interessa diventare partner commerciale? Scrivere a partners@nowayos.com
- Remote Desktop
- Una vista temprata. Una postazione sicura per un desktop Windows remoto, progettata per sigillare la connessione in un compartimento tutto suo e tenere le credenziali fuori dalla sua portata.
- Data Diode
- Non si torna indietro. Un confine a senso unico per far uscire i dati da una rete protetta, progettato attorno a un collegamento che trasporta la luce in una sola direzione.
A che punto è
Gira già oggi. Non è ancora finito.
NoWayOS è in sviluppo, non è ancora pronto per l'uso in produzione e le sue API cambieranno. Ecco cosa gira oggi, e cosa viene dopo.
- In QEMU
- Oltre cinquanta sistemi si avviano e verificano il proprio output: dal primo dominio di protezione allo stack di rete che ottiene un lease DHCP, dallo stato fail-safe del supervisore a un'interfaccia utente cliccabile.
- Su Raspberry Pi 5
- Sulla scheda girano l'interfaccia utente su uno schermo HDMI, tastiera e mouse USB, i timer, il watchdog e il reset del supervisore. Altro hardware della scheda è in fase di attivazione.
- Ancora da fare
- Avvio sicuro, aggiornamenti firmati applicati sul dispositivo e hardware industriale (NXP i.MX8).
- Le dimostrazioni di seL4
- Ogni sistema gira su seL4, ma nessuna immagine NoWayOS usa ancora una configurazione coperta dalle dimostrazioni completate di seL4. Ogni immagine registra quella che usa.
Seguire i lavori
Un solo scopo. Tanto da esplorare.
Si può partire dal progetto, esaminare le prove o costruire il primo sistema con le guide per sviluppatori. Questo sito, tra l'altro, segue la stessa regola: niente script, niente cookie, nient'altro da fare.