La maggior parte dei sistemi operativi moderni è costruita su decenni di codice accumulato, librerie e dipendenze esterne. Sebbene questo ecosistema abiliti uno sviluppo rapido, introduce anche complessità, assunzioni nascoste e rischi di sicurezza potenzialmente non esaminati.

EriX adotta un approccio diverso.

Viene sviluppato come un sistema operativo in camera bianca, il che significa che ogni componente - dal bootloader ai servizi in spazio utente - è implementato all’interno del progetto stesso, senza incorporare codice sorgente esterno o librerie di terze parti.

Questo articolo esplora cosa significa in pratica lo sviluppo in camera bianca, perché è utile e quali compromessi introduce.

Che cosa significa “camera bianca”?⌗

Nel contesto di EriX, lo sviluppo in camera bianca significa:

  • Nessun codice sorgente esterno viene copiato o riutilizzato
  • Nessuna libreria o crate di terze parti viene inclusa
  • Tutti i componenti sono implementati all’interno del progetto
  • Possono essere consultate solo specifiche e documentazione pubbliche

Il risultato è un sistema in cui ogni riga di codice è:

  • compresa
  • auditabile
  • progettata intenzionalmente

Questa non è solo una decisione legale o di licenza: è una decisione architetturale.

Perché evitare codice esterno?⌗

Evitare dipendenze esterne può sembrare restrittivo. Lo sviluppo software moderno incoraggia normalmente il riuso, e i grandi ecosistemi esistono proprio per evitare di reinventare la ruota.

Tuttavia, i sistemi operativi non sono applicazioni tipiche.

1. Complessità nascosta⌗

Il codice esterno porta spesso assunzioni implicite:

  • sul layout della memoria
  • sui modelli di concorrenza
  • sulla gestione degli errori
  • sul comportamento della piattaforma

Queste assunzioni potrebbero non allinearsi con l’architettura di un nuovo sistema operativo, specialmente uno costruito intorno a capacità e isolamento rigoroso.

2. Base di calcolo fidata (TCB) ampliata⌗

Ogni dipendenza aumenta la dimensione della base di calcolo fidata.

Se una libreria di terze parti viene usata nel kernel o in componenti critici del sistema, la sua correttezza diventa parte delle garanzie di sicurezza del sistema.

Lo sviluppo in camera bianca mantiene la TCB:

  • piccola
  • controllata
  • definita esplicitamente

3. Auditabilità e verifica⌗

Un sistema costruito interamente internamente può essere auditato in modo sistematico.

  • Tutto il codice unsafe può essere esaminato
  • Tutti gli invarianti possono essere documentati
  • Tutte le interfacce possono essere ragionate

Questo è particolarmente importante per un sistema come EriX, che enfatizza:

  • autorità esplicita
  • sicurezza basata su capacità
  • progettazione minimale del kernel

4. Libertà architetturale⌗

Riutilizzare codice esistente spesso vincola le decisioni di progettazione.

Per esempio:

  • adottare una libreria può imporre una particolare forma di API
  • integrare codice esistente può richiedere livelli di compatibilità
  • astrazioni legacy possono filtrare nei nuovi componenti

Lo sviluppo in camera bianca consente al sistema di essere plasmato interamente dai propri principi, invece che da vincoli ereditati.

Camera bianca vs. reimplementazione⌗

È importante distinguere lo sviluppo in camera bianca dalla semplice reimplementazione.

Lo sviluppo in camera bianca non significa riscrivere alla cieca sistemi esistenti.

Al contrario, implica:

  • studiare specifiche pubbliche
  • comprendere i principi sottostanti
  • progettare nuove implementazioni a partire dai primi principi

Per esempio:

  • Un file system può seguire la semantica POSIX, ma essere implementato in modo indipendente
  • Un bootloader può seguire le specifiche UEFI, ma usare una struttura personalizzata
  • Una libreria standard C può esporre la stessa API, ma essere scritta interamente in Rust

L’obiettivo è la compatibilità dove necessaria, senza riuso di codice.

Camera bianca in pratica⌗

In EriX, i vincoli di camera bianca sono applicati a tutto il sistema.

Nessun crate esterno⌗

Anche in Rust, dove il riuso delle dipendenze è comune, EriX evita crate esterni.

Definisce invece componenti riutilizzabili interni, come:

  • utilità di memoria
  • primitive di sincronizzazione
  • astrazioni di capacità

Librerie interne⌗

Le funzionalità riutilizzabili sono organizzate in crate interni, per esempio:

  • lib-bootimg
  • lib-capabi
  • lib-ipc

Queste librerie sono:

  • versionate
  • controllate all’interno del progetto
  • progettate specificamente per le necessità del sistema

Struttura rigorosa del repository⌗

Ogni sottosistema è isolato:

  • bootloader
  • kernel
  • IPC
  • gestione della memoria
  • servizi in spazio utente

Questo impone modularità e impedisce accoppiamenti nascosti.

Build riproducibili⌗

La progettazione in camera bianca si estende anche al processo di build.

Il sistema punta a:

  • build deterministiche
  • assunzioni minime sulla toolchain
  • passaggi di build espliciti

Questo assicura che gli artefatti possano essere riprodotti e verificati.

Benefici di un OS in camera bianca⌗

1. Comprensione completa del sistema⌗

Ogni componente è noto e compreso.

Non ci sono dipendenze opache o comportamenti nascosti.

2. Modello di sicurezza più forte⌗

Con una TCB più piccola e controllata:

  • esistono meno superfici d’attacco
  • gli invarianti sono più facili da far rispettare
  • la sicurezza basata su capacità può essere implementata in modo pulito

3. Migliore piattaforma di ricerca⌗

EriX non è solo un sistema operativo: è anche una piattaforma di ricerca.

Lo sviluppo in camera bianca consente:

  • sperimentazione con nuove astrazioni
  • misurazione precisa dei compromessi di progettazione
  • ragionamento chiaro su autorità e isolamento

4. Manutenibilità a lungo termine⌗

Sebbene inizialmente richiedano più lavoro, i sistemi in camera bianca possono essere più facili da mantenere:

  • nessuna rottura delle dipendenze
  • nessun cambiamento upstream da seguire
  • nessun conflitto di versione

Il sistema evolve secondo i propri termini.

Compromessi e sfide⌗

Lo sviluppo in camera bianca non è privo di costi.

1. Sviluppo più lento⌗

Tutto deve essere costruito da zero:

  • librerie di base
  • supporto runtime
  • servizi di sistema

Questo aumenta significativamente lo sforzo iniziale.

2. Reinventare la ruota⌗

Molti problemi sono già stati risolti altrove.

Reimplementarli richiede tempo e progettazione attenta.

3. Meno scorciatoie⌗

Non c’è la possibilità di:

  • importare rapidamente una libreria
  • fare affidamento su ecosistemi esistenti
  • delegare complessità a codice esterno

Tutta la complessità deve essere gestita direttamente.

4. Maggiore responsabilità di progettazione⌗

Ogni astrazione deve essere progettata deliberatamente.

Gli errori non possono essere facilmente coperti sostituendo dipendenze.

Perché questo approccio si adatta a EriX⌗

EriX è costruito intorno ad alcuni principi fondamentali:

  • base di calcolo fidata minima
  • autorità esplicita tramite capacità
  • separazione rigorosa tra kernel e spazio utente
  • riproducibilità e determinismo

Lo sviluppo in camera bianca supporta tutti questi obiettivi.

Garantisce che:

  • l’autorità non sia mai nascosta dentro codice esterno
  • gli invarianti del sistema siano completamente controllati
  • l’architettura rimanga coerente in tutti i componenti

Una base per il self-hosting⌗

La progettazione in camera bianca supporta anche l’obiettivo a lungo termine del self-hosting.

Per costruire EriX dentro EriX, il sistema deve includere:

  • la propria toolchain
  • le proprie librerie runtime
  • le proprie interfacce di sistema

Un sistema che dipende fortemente da componenti esterni faticherebbe a raggiungere questo livello di indipendenza.

Guardando avanti⌗

Progettare un sistema operativo in camera bianca è uno sforzo a lungo termine. Richiede pianificazione attenta, implementazione disciplinata e disponibilità a costruire componenti fondamentali da zero.

Ma crea anche un sistema che è:

  • trasparente
  • controllato
  • compreso in profondità

Nei prossimi articoli passeremo dai principi all’implementazione, iniziando dal processo di boot iniziale e dal design del formato dell’immagine di boot del sistema.