Domande, risposte chiare.

Il Single Purpose OS: un sistema operativo per dispositivi dedicati, come i sistemi di controllo delle reti elettriche e idriche, i terminali delle sale di controllo e i diodi di dati unidirezionali, costruito per l'unico compito di ciascun dispositivo. L'applicazione del dispositivo si scrive in Rust, e NoWayOS la costruisce sul microkernel seL4, insieme ai soli driver che usa. L'immagine contiene questo e nient'altro: nessun motore di browser, sistema a finestre, shell, gestore di pacchetti o account utente.

Un computer che non ha altro da fare.

Un sistema operativo 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 fanno di un sistema operativo un Single Purpose OS:

• Costruito per un solo compito. La sua immagine contiene l'applicazione, i driver che quell'applicazione usa e il kernel, e nient'altro: nessun browser, desktop, shell, gestore di pacchetti o account utente.
• Sigillato all'interno. Ogni parte gira in un compartimento tutto suo e raggiunge solo ciò che le è stato concesso, e 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.

Un Single Purpose OS non è una modalità kiosk, che blocca un sistema generalista su un'unica app e lascia tutto il resto al suo posto, e non è un sistema operativo monoutente, che limita chi usa un computer anziché cosa contiene. NoWayOS è un Single Purpose OS: un computer che non ha altro da fare.

Perché non c'è modo di sfruttare ciò che non è mai stato incluso. Il nome parla di ciò che resta fuori da un dispositivo, non promette che non possa mai andare storto niente in ciò che resta dentro. Ciò che è incluso può comunque avere bug; le affermazioni sono che ce n'è molto meno, e che un bug resta nel suo compartimento.

Bloccare significa essere sicuri per configurazione: il browser, il desktop e la shell sono ancora lì dietro le impostazioni, vanno ancora aggiornati, e un solo bug può aggirare tutte le impostazioni in un colpo. NoWayOS è sicuro per costruzione: quelle parti non sono mai state incluse nel dispositivo, e ciò che resta gira in compartimenti sigillati, così tutto è progettato perché un guasto in una parte resti in quella parte.

No. NoWayOS è in sviluppo, e ogni API è provvisoria e cambierà. Oltre cinquanta sistemi si avviano e si verificano da soli in QEMU, e l'interfaccia utente, tastiera e mouse USB, i timer, il watchdog e il supervisore girano su un Raspberry Pi 5. Avvio sicuro, aggiornamenti firmati applicati sul dispositivo e hardware di produzione devono ancora arrivare.

Sì. NoWayOS, lo Showcase e Defence Agent sono sotto licenza MIT OR Apache-2.0, a Sua scelta, e lo Screen Compiler è MIT. Tutti e quattro sono pubblici nell'organizzazione NoWayOS su GitHub: può clonarli, compilarli e aprire una issue.

No, e stiamo attenti a non lasciarlo intendere. NoWayOS gira su seL4, che ha dimostrazioni di correttezza e sicurezza verificate a macchina per configurazioni specifiche sul suo hardware. NoWayOS usa la configurazione a criticità mista di seL4, le cui dimostrazioni per AArch64 sono in corso, quindi oggi nessuna immagine NoWayOS rientra nelle dimostrazioni completate di seL4. Il codice di NoWayOS non è affatto coperto dalle dimostrazioni di seL4; si affida a Rust, all'isolamento, ai test e a dimostrazioni limitate proprie. Ogni immagine registra la sua esatta configurazione seL4 (Sicurezza).

No. La sicurezza di NoWayOS viene dal suo progetto, non dalla segretezza: da ciò che è lasciato fuori e dai compartimenti attorno a ciò che resta dentro. Essere aperto permette a chiunque di verificare le affermazioni, eseguire le prove e segnalare ciò che trova.

Tutto è progettato perché resti nel compartimento in cui si trova, il che limita i danni mentre si prepara una correzione, e con molto meno codice ci sono molte meno correzioni da fare. Le correzioni sono destinate ad arrivare come aggiornamenti firmati che, in caso di problemi, tornano indietro in sicurezza: questo è progettato, non ancora costruito. Per segnalarne una, si prega di scrivere in privato, come descritto nel SECURITY.md di ogni repository, e non in una issue pubblica.

Non così com'è. NoWayOS esegue applicazioni scritte per lui, in Rust; non può eseguire programmi Linux o Windows, né una web app, perché nulla di ciò di cui hanno bisogno è incluso. Le schermate sono la parte facile: le schermate React scritte nel sottoinsieme supportato dallo Screen Compiler si convertono in Rust nativo al momento della build. La logica dell'applicazione va ricostruita come domini di protezione NoWayOS.

No. È proprio questo il punto. Su un dispositivo NoWayOS non ci sono motore di browser, WebView né JavaScript. Le schermate sono in Rust nativo, disegnate dalla piccola interfaccia utente di NoWayOS, e si possono comunque progettare in React e convertire al momento della build.

Sulla macchina AArch64 di QEMU, dove ogni sistema si avvia per primo, e sul Raspberry Pi 5, la scheda di riferimento economica. La famiglia i.MX8 di NXP è l'hardware di produzione previsto, con una radice di fiducia hardware; non è ancora supportata. Per compilare NoWayOS servono Podman (o Docker) e make: è sviluppato su Apple silicon, e gli host x86-64 non sono ancora stati testati.

Si clona il repository nowayos, si esegue una volta make container, poi make demo: la sessione scriptata della demo cliccabile gira sulla propria macchina, con ogni frame verificato e senza bisogno di hardware. Poi make qemu-test SYSTEM=hello avvia seL4 in QEMU. Per iniziare guida passo per passo.