Ogni sistema operativo comincia prima di essere davvero sé stesso. La CPU parte in un ambiente definito dalla piattaforma, il firmware inizializza abbastanza hardware da caricare il primo eseguibile, e quell’eseguibile prepara la macchina per il kernel. Solo dopo che questa catena ha fatto il proprio lavoro il sistema operativo può iniziare ad applicare le proprie regole. È facile trattare quel percorso iniziale come semplice impianto, ma il processo di boot fa parte del modello di sicurezza.

I sistemi operativi sono di solito associati al C. L’associazione è comprensibile. C è piccolo, prevedibile, vicino alla macchina e storicamente dominante nello sviluppo dei kernel. Dà al programmatore accesso diretto a memoria, registri, layout e convenzioni di chiamata. Sono esattamente le cose di cui un kernel ha bisogno. Sono anche esattamente le cose che rendono i kernel difficili da rendere sicuri. EriX è scritto principalmente in Rust perché il progetto ruota attorno a un’idea centrale:

Le discussioni sulla sicurezza spesso si concentrano su singoli bug: un buffer overflow un problema di confused deputy un parser non controllato un percorso di escalation dei privilegi Quei bug contano, ma sono sintomi di una domanda più profonda: Quanto codice deve essere corretto perché il sistema rimanga sicuro? Quel codice è la base di calcolo fidata, di solito abbreviata in TCB. La dimensione e la forma della TCB determinano quanto codice deve essere considerato fidato, auditato, testato e compreso.

Pochi dibattiti nella progettazione dei sistemi operativi sono durati quanto il dibattito tra microkernel e kernel monolitici. In superficie, la distinzione sembra semplice: i kernel monolitici tengono la maggior parte dei servizi del sistema operativo dentro il kernel i microkernel spostano la maggior parte dei servizi nello spazio utente In pratica, il compromesso è più sottile. La vera domanda non è se una struttura sia universalmente più veloce, più pulita o più sicura.

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.

I sistemi operativi moderni impongono confini di sicurezza tra processi, file, dispositivi e utenti. Tuttavia, il modo in cui questi confini vengono implementati varia in modo significativo tra diversi progetti di sistema. La maggior parte dei sistemi operativi tradizionali si basa sul controllo di accesso basato sull’identità e sugli spazi dei nomi globali. I sistemi operativi basati su capacità adottano un approccio fondamentalmente diverso: rappresentano l’autorità in modo esplicito e la rendono un concetto di primo livello.

I sistemi operativi sono tra i software più complessi mai costruiti. Gestiscono la memoria, pianificano il calcolo, controllano l’hardware e fanno rispettare i confini di sicurezza che proteggono ogni applicazione in esecuzione su una macchina. Eppure molti dei sistemi operativi su cui facciamo affidamento oggi sono costruiti su idee architetturali che risalgono a diversi decenni fa. Sebbene questi sistemi siano straordinariamente potenti e collaudati, portano con sé anche decenni di complessità accumulata.