Erik Inkinen

Che cos'è un sistema operativo basato su capacità

Thu, 16 Apr 2026 00:00:00 +0000

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.

Questo articolo introduce i sistemi basati su capacità, spiega in cosa differiscono dai modelli tradizionali e descrive perché sono centrali per il design di EriX.

Il problema: l’autorità ambientale

Nei sistemi tradizionali, i processi hanno spesso accesso alle risorse tramite l’autorità ambientale.

Autorità ambientale significa che un programma può accedere a una risorsa semplicemente perché essa esiste in uno spazio dei nomi condiviso e il sistema determina che il programma ha il permesso di usarla.

Per esempio:

Un processo può aprire /etc/passwd se ha permessi sufficienti.
Un programma può collegarsi a un socket di rete se il sistema operativo lo consente.
Un servizio può accedere ai file in base all’identità dell’utente o all’appartenenza a un gruppo.

In tutti questi casi, l’autorità per accedere alla risorsa è implicita.

Il processo non possiede un riferimento diretto ed esplicito alla risorsa. Invece, si basa su:

nomi globali (percorsi di file, porte, identificatori di dispositivo)
controlli di accesso (ID utente, permessi, ACL)

Questo modello crea diversi problemi:

1. Problema del delegato confuso

Un programma può usare accidentalmente la propria autorità in modo improprio per conto di un altro programma.

Per esempio, un servizio privilegiato potrebbe leggere un file richiesto da un client non affidabile, anche se quel client non dovrebbe avere accesso al file.

2. Autorità eccessivamente ampia

I programmi spesso vengono eseguiti con più permessi di quanti ne abbiano realmente bisogno. Questo aumenta l’impatto di bug o compromissioni.

3. Difficile da analizzare

È difficile determinare cosa un processo sia autorizzato a fare senza analizzare lo stato globale, le identità utente e le policy di controllo degli accessi.

L’idea centrale: le capacità

Una capacità è un token non falsificabile che concede accesso a uno specifico oggetto con specifici diritti.

Invece di chiedere:

“Questo processo ha il permesso di accedere a questa risorsa?”

un sistema basato su capacità chiede:

“Questo processo possiede una capacità che autorizza questa operazione?”

Se la risposta è no, l’operazione non può procedere.

Proprietà delle capacità

Le capacità hanno diverse proprietà definitorie:

1. Non falsificabilità

Un processo non può creare una capacità valida dal nulla.

Le capacità vengono create e gestite dal kernel, il che garantisce che non possano essere falsificate né indovinate.

2. Autorità esplicita

Tutta l’autorità è rappresentata esplicitamente tramite capacità.

Se un processo può eseguire un’operazione, deve possedere una capacità che la consenta. Non esiste accesso implicito tramite spazi dei nomi globali.

3. Diritti granulari

Le capacità possono codificare permessi specifici, come:

accesso in sola lettura
accesso in scrittura
permessi di esecuzione
sottoinsiemi limitati di operazioni

Questo consente un controllo preciso su ciò che ogni processo può fare.

4. Trasferibilità

Le capacità possono essere trasferite tra processi, tipicamente tramite comunicazione inter-processo (IPC).

Questo consente una delega controllata dell’autorità.

Oggetti e capacità

In un sistema basato su capacità, tutto viene modellato come un oggetto:

regioni di memoria
file
dispositivi
endpoint IPC
processi

Una capacità è un riferimento a un oggetto combinato con un insieme di diritti.

Un processo interagisce con il sistema invocando operazioni sugli oggetti attraverso le proprie capacità.

Non c’è bisogno di nomi globali come percorsi di file o identificatori di dispositivo all’interno del kernel. Ogni accesso è mediato da capacità.

Come funzionano i sistemi basati su capacità

A livello generale, un sistema basato su capacità funziona così:

Il kernel crea oggetti e capacità.
Ogni processo ha uno spazio di capacità (spesso chiamato CSpace), che memorizza le sue capacità.
Un processo può operare solo sugli oggetti per cui possiede capacità.
Le capacità possono essere trasferite tra processi tramite IPC.
Il kernel applica tutti i controlli di capacità.

Il risultato è un sistema in cui l’autorità è:

esplicita
localizzata
trasferibile
facile da analizzare

Esempio: aprire un file

Modello tradizionale

In un sistema tradizionale:

Un processo chiama open("/etc/config")
Il kernel controlla i permessi:
- ID utente
- appartenenza a un gruppo
- bit di modalità del file
Se consentito, viene restituito un descrittore di file

L’autorità proviene da stato globale e identità.

Modello basato su capacità

In un sistema basato su capacità:

Un processo deve già possedere una capacità di file
Usa questa capacità per eseguire operazioni di lettura o scrittura

Se il processo non possiede la capacità, non può accedere al file, a prescindere dal nome che usa.

Non esiste un passaggio di ricerca globale all’interno del kernel.

Delega e privilegio minimo

Uno degli aspetti più potenti dei sistemi basati su capacità è la delega.

Un processo può dare a un altro processo un sottoinsieme della propria autorità trasferendogli una capacità.

Per esempio:

Un file server concede a un client accesso in sola lettura a un file
Un gestore della memoria concede accesso a una regione di memoria specifica
Un processo concede accesso a un endpoint IPC

Questo abilita il principio del privilegio minimo:

Ogni componente riceve solo l’autorità di cui ha realmente bisogno.

Eliminare l’autorità ambientale

I sistemi basati su capacità eliminano completamente l’autorità ambientale.

Non ci sono:

spazi dei nomi globali all’interno del kernel
accesso implicito basato sull’identità
privilegi nascosti

Ogni autorità deve essere passata esplicitamente.

Questo rende molto più facile analizzare:

che cosa un processo può fare
come l’autorità fluisce attraverso il sistema
dove possono sorgere potenziali problemi di sicurezza

Revoca (un problema difficile)

Una delle sfide dei sistemi basati su capacità è la revoca.

Una volta che una capacità è stata data a un processo, come può essere tolta?

Sistemi diversi implementano la revoca in modi diversi:

livelli di indirezione
tracciamento dei riferimenti
alberi di capacità
meccanismi di versioning

La revoca è un’importante area di ricerca e sarà esplorata nelle fasi successive di EriX.

Sistemi basati su capacità nella pratica

Le idee basate su capacità non sono nuove. Diversi sistemi le hanno implementate:

KeyKOS / EROS
seL4 (un micro-nucleo verificato formalmente)
CHERI (capacità assistite dall’hardware)
Capsicum (estensioni di capacità per FreeBSD)

Questi sistemi dimostrano che i design basati su capacità sono sia pratici sia potenti.

Come EriX usa le capacità

EriX è progettato fin dall’inizio come un sistema basato su capacità.

In EriX:

tutta l’autorità è rappresentata tramite capacità
le capacità sono fortemente tipizzate
le capacità sono immutabili una volta create
le capacità sono trasferite tramite IPC
il kernel applica non falsificabilità e invarianti di sicurezza

Non ci sono spazi dei nomi globali all’interno del kernel. Ogni accesso alle risorse è mediato da capacità.

Questo si allinea con l’obiettivo più ampio di rendere l’autorità:

esplicita
minima
facile da analizzare

Perché questo conta

I sistemi basati su capacità forniscono una base per costruire:

sistemi più sicuri
architetture più modulari
sistemi più facili da analizzare e verificare

Eliminando l’autorità implicita e rendendo esplicito ogni accesso, eliminano intere classi di vulnerabilità comuni nei sistemi tradizionali.

Guardando avanti

Le capacità sono un concetto fondamentale in EriX. Nei prossimi articoli esploreremo come vengono implementate nella pratica, inclusi:

spazi di capacità (CSpace)
comunicazione inter-processo (IPC)
gestione della memoria usando capacità non tipizzate
delega e grafi di autorità

Comprendere le capacità è il primo passo per comprendere il resto del sistema.

Perché sto costruendo un micro-nucleo basato su capacità da zero

Wed, 11 Mar 2026 00:00:00 +0000

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.

Questo progetto esplora una direzione diversa: costruire un sistema operativo moderno a micro-nucleo, basato su capacità, da zero, con una forte attenzione all’autorità esplicita, a una base di calcolo fidata (TCB) minima e a una separazione rigorosa tra nucleo e spazio utente.

Questo sistema operativo si chiama EriX.

Perché costruire un altro sistema operativo?

A prima vista, costruire un nuovo sistema operativo può sembrare inutile. Sistemi maturi come Linux, Windows e BSD esistono già e alimentano miliardi di dispositivi.

Tuttavia, questi sistemi si sono evoluti sotto vincoli storici. Nel tempo hanno accumulato strati di astrazioni, meccanismi di compatibilità e interfacce legacy. Sebbene queste caratteristiche siano spesso necessarie nel software reale, rendono anche difficile sperimentare idee architetturali fondamentalmente diverse.

I sistemi operativi di ricerca hanno esplorato a lungo approcci alternativi alla progettazione dei sistemi operativi. I micro-nuclei, i sistemi a capacità e i nuclei formalmente verificati hanno dimostrato che è possibile costruire sistemi più piccoli, più sicuri e più facili da analizzare.

L’obiettivo di EriX non è sostituire i sistemi operativi esistenti. Piuttosto, è un’esplorazione di come potrebbe essere progettato un sistema operativo moderno se partissimo dai primi principi.

Micro-nucleo e base di calcolo fidata

Una delle idee centrali dietro EriX è l’architettura a micro-nucleo.

I nuclei monolitici tradizionali includono molti servizi direttamente all’interno del nucleo stesso. Questi spesso includono:

controllori di dispositivo
filesystem
stack di rete
sottosistemi di gestione dei processi

Sebbene questo approccio possa essere efficiente, aumenta anche la dimensione della base di calcolo fidata (TCB). La TCB include ogni parte di codice che deve comportarsi correttamente affinché il sistema resti sicuro e affidabile.

I micro-nuclei adottano un approccio diverso.

Un micro-nucleo mantiene nel nucleo solo i meccanismi più fondamentali, tipicamente:

schedulazione dei thread
gestione dello spazio di indirizzamento
comunicazione inter-processo (IPC)
gestione delle capacità
gestione di interrupt ed eccezioni

Tutto il resto gira in spazio utente, inclusi controllori, filesystem e servizi di livello superiore.

Questa progettazione riduce drasticamente la quantità di codice di cui ci si deve fidare. I guasti nei componenti in spazio utente hanno meno probabilità di compromettere l’intero sistema, e i singoli componenti possono essere riavviati o sostituiti senza mandare in crash il nucleo.

Sicurezza basata su capacità

Un altro principio centrale di progettazione di EriX è la sicurezza basata su capacità.

La maggior parte dei sistemi operativi si basa fortemente su autorità ambientale. In questi sistemi, i processi hanno spesso accesso implicito alle risorse in base a spazi dei nomi globali, identità utente o privilegi ereditati.

Per esempio, un processo può aprire un file semplicemente perché conosce il percorso del file e il sistema operativo decide che quel processo ha il permesso di accedervi.

I sistemi a capacità adottano un approccio diverso.

Una capacità è un token non falsificabile che concede accesso a uno specifico oggetto con specifici diritti. Un processo può accedere a un oggetto solo se possiede una capacità che autorizza quell’accesso.

Le capacità hanno diverse proprietà importanti:

Rappresentano l’autorità in modo esplicito.
Possono essere trasferite tra processi.
Possono limitare le operazioni a un insieme preciso di diritti.

In un sistema basato su capacità, l’autorità fluisce attraverso trasferimenti espliciti invece che tramite spazi dei nomi globali. Questo rende il sistema più facile da analizzare e aiuta a eliminare intere classi di vulnerabilità di sicurezza.

Perché Rust?

I sistemi operativi sono tradizionalmente scritti in C o assembly. Questi linguaggi offrono un controllo preciso su hardware e memoria, ma rendono anche facile introdurre bug sottili.

I bug di sicurezza della memoria, come uso dopo liberazione, overflow del buffer e corse di dati, sono stati storicamente una delle maggiori fonti di vulnerabilità nel software di sistema.

EriX è scritto principalmente in Rust.

Rust fornisce forti garanzie sulla sicurezza della memoria pur consentendo un controllo a basso livello dell’hardware. Il modello di proprietà del linguaggio aiuta a prevenire molte classi di bug in fase di compilazione, mentre i blocchi unsafe espliciti rendono visibili e verificabili le operazioni potenzialmente pericolose.

Usare Rust non elimina tutti i possibili errori, ma alza in modo significativo la soglia di sicurezza di base nella programmazione di sistema.

Un sistema operativo in camera bianca

Un aspetto insolito del progetto EriX è il suo approccio di sviluppo in camera bianca.

Tutti i componenti del sistema vengono implementati all’interno del progetto stesso. Nessun codice sorgente esterno viene copiato o incorporato, e non vengono usate librerie di terze parti.

Questo vincolo ha diversi scopi:

Garantisce che l’intero sistema possa essere compreso e verificato.
Evita dipendenze nascoste e comportamenti inattesi.
Costringe le decisioni architetturali a essere esplicite anziché ereditate.

Lo sviluppo in camera bianca trasforma inoltre il progetto in un esercizio educativo. Ogni sottosistema, dal caricatore di avvio al gestore di memoria, deve essere progettato e implementato deliberatamente.

Un obiettivo a lungo termine: auto-ospitazione

Uno degli obiettivi a lungo termine di EriX è l’auto-ospitazione.

Un sistema è considerato auto-ospitato quando può compilare il proprio codice sorgente usando strumenti che girano sul sistema stesso.

Per EriX, questo significa che alla fine:

il compilatore Rust gira su EriX
gli strumenti di compilazione girano su EriX
l’intero sistema operativo può essere compilato nativamente dentro EriX

Raggiungere questo traguardo richiede l’implementazione di molti strati infrastrutturali, inclusi filesystem, gestione dei processi e un ambiente utente compatibile con POSIX.

Perché documentare il percorso?

Costruire un sistema operativo è un processo lungo e complesso. Molte delle intuizioni più interessanti non appaiono nel sistema finale, ma nelle decisioni, nei compromessi e negli errori incontrati lungo il cammino.

Questo blog documenta lo sviluppo di EriX mentre evolve. I post futuri tratteranno temi come:

progettare un formato di immagine di avvio
implementare spazi di capacità
costruire un sistema IPC
gestire l’autorità della memoria
costruire server in spazio utente

L’obiettivo è rendere il processo di sviluppo trasparente e formativo.

Guardando avanti

EriX è ancora nelle fasi iniziali. Gran parte del sistema deve ancora essere costruita e molte decisioni di progettazione evolveranno sicuramente nel tempo.

Ma i principi guida sono già chiari:

nucleo minimo
autorità esplicita
sicurezza basata su capacità
modularità rigorosa
implementazione in camera bianca

Nel prossimo articolo esploreremo una delle idee centrali del sistema:

cosa sono i sistemi operativi basati su capacità e perché sono importanti.

Su di me

Mon, 01 Jan 0001 00:00:00 +0000

Studio tecnologia dell’informazione presso l’Università di Tampere. Nel tempo libero contribuisco a software libero e open source, distribuzioni software e progetti di sistemi basati sulle capacità, come EriX Project, AES, Cutie Shell Project e Droidian GNU/Linux.

Ho utilizzato numerosi linguaggi di programmazione. Per esempio, C, C++, Python, JavaScript e Rust mi sono familiari grazie al lavoro pratico. Ho anche esperienza con linguaggi di markup comuni, come HTML e QML. Inoltre, ho utilizzato framework software noti, incluso Qt Framework.

Inoltre, ho contribuito a librerie software e scritto documentazione di riferimento per esse. Il mio lavoro in questi progetti comprende sia il lavoro di squadra con altri contributori sia attività indipendenti di ricerca e implementazione.

Ho esperienza con la metodologia DevOps, che enfatizza l’integrazione e l’automazione di vari processi di sviluppo e distribuzione del software. Sia in Droidian sia in Cutie Shell Project, le patch vengono unite nel branch principale il prima possibile. Le aggiunte di funzionalità più grandi vengono inizialmente sviluppate in branch di funzionalità. Tuttavia, tutti i branch di funzionalità in corso vengono rebaseati spesso sul branch principale, in modo che possano essere uniti in qualsiasi momento. Sia il branch principale sia i branch di funzionalità vengono compilati e pacchettizzati dopo ogni commit. Oltre al repository di produzione, esistono il repository di staging e repository di funzionalità corrispondenti a ciascun branch di funzionalità. Questi repository di pacchetti vengono usati per automatizzare facilmente la creazione di un ambiente di test.

Mi interessano anche le lingue naturali e il loro apprendimento. Di conseguenza, parlo diverse lingue.

Progetti

EriX Project : 2/2026-

https://git.erikinkinen.fi/erix

“Un sistema operativo a microkernel, basato sulle capacità e sviluppato in camera bianca, scritto interamente in Rust.”

AES : 1/2026-
https://git.erikinkinen.fi/erikinkinen/AES

“AES (Authority Evolution Simulator) è un simulatore di ricerca per studiare come l’autorità evolve nel tempo nei sistemi basati sulle capacità.”

Droidian GNU/Linux : 3/2021-

https://droidian.org/ / https://github.com/droidian/

“Droidian è una distribuzione GNU/Linux basata su Debian per dispositivi mobili. L’obiettivo di Droidian è poter eseguire Debian sui telefoni Android. Ciò viene realizzato utilizzando tecnologie note come libhybris e Halium.”

Un video in cui presento Droidian al Volla Community Days 2021:

Cutie Shell : 8/2021-

https://cutie-shell.org/ / https://github.com/cutie-shell/

“Cutie Shell mira a essere un’interfaccia mobile bella e facile da usare per dispositivi Linux che eseguono Halium o Linux mainline. La nostra interfaccia è ispirata al Sailfish OS di Jolla, ma non puntiamo a crearne un clone. Una differenza importante rispetto a Sailfish OS è che il nostro codice sorgente è completamente aperto.”

Un video in cui presento Cutie Shell al Volla Community Days 2023:

Un altro video in cui presento i progressi di Cutie Shell al Volla Community Days 2024:

Istruzione

Università di Tampere : 9/2022-
Studi di laurea triennale in Tecnologia dell’Informazione

Attualmente sto studiando per la laurea triennale e il mio obiettivo è conseguire una laurea magistrale.

Helsingin matematiikkalukio : 8/2018-5/2022
Istruzione secondaria superiore generale finlandese

Competenze linguistiche

Finlandese	madrelingua
Inglese	avanzato
Spagnolo	avanzato
Catalano	intermedio
Svedese	intermedio
Francese	elementare