Google Fuchsia usa un microkernel. Qual è la differenza e perché è rilevante

Non accade tutti i giorni che un nuovo sistema operativo venga distribuito su migliaia o addirittura milioni di dispositivi di uso comune. Ciò è, però, quanto è avvenuto con Fuchsia, un sistema sviluppato da Google e ora impiegato sui dispositivi Nest. La particolarità di Fuchsia sta nel suo kernel, Zircon, che è un microkernel e per questo si differenzia dagli altri sistemi maggiormente diffusi. Ci sono vantaggi e svantaggi in questo approccio, che storicamente è stato motivo di divisione tra esponenti di spicco del mondo dell’informatica.

Cos’è un kernel e come funziona, in breve (o quasi)

Zircon è, come abbiamo detto, un microkernel (anche se Google non è chiara su questo punto e talvolta afferma che non lo sia). Per capire perché ciò sia importante dobbiamo, però, fare qualche passo indietro per capire cos’è un kernel, quali compiti svolge e come.

“Kernel” significa “nocciolo” o “seme” ed è dunque il cuore, l’elemento al centro del sistema operativo. Il kernel è, in termini molto semplicistici, il programma che si occupa di gestire il computer e le sue risorse. I sistemi operativi nascono dall’esigenza di dividere le risorse di un computer tra più programmi: in un’epoca in cui esistevano grandi computer dedicati a calcoli specialistici, la programmazione avveniva pensando di avere a disposizione tutte le risorse della macchina perché così effettivamente era, ma col tempo ci si rese conto che un computer poteva eseguire più operazioni in contemporanea in ambiti diversi (ad esempio, mentre il processore era impegnato a fare calcoli, si potevano caricare le schede perforate o stampare i risultati di un programma eseguito precedentemente). Questa idea si espanse all’uso del computer da parte di molteplici utenti contemporaneamente e, dunque, all’uso di più programmi.

Già, ma come è possibile permettere l’uso contemporaneo di un computer a più programmi, se c’è un solo processore? L’idea fu quindi quella di creare un programma che fungesse da supervisore (e da qui nacque successivamente l’idea di un ipervisore per la virtualizzazione dei sistemi operativi). Questo supervisore doveva creare l’illusione che il programma in esecuzione avesse il controllo della macchina e ne avesse a disposizione tutte le risorse; per farlo, si pensò di spezzettare l’esecuzione dei programmi, alternandoli e dividendo le risorse del computer in fasi (input, esecuzione, output…). Ci si rese altresì conto che era possibile mettere a disposizione delle funzionalità che permettevano di accedere alle risorse della macchina senza che i programmatori dovessero ogni volta riscrivere il codice per farlo. In altre parole, si arrivò alla creazione di un sistema operativo, che altro non è che un’astrazione dell’hardware e delle funzionalità a disposizione della macchina.

Il kernel è la componente fondamentale di un sistema operativo perché è il programma che si occupa di sovrintendere tutti gli altri: oggigiorno assegna tempo di processore a ciascun processo, decidendo per quanto tempo deve essere eseguito prima di dare il turno a un altro, e si occupa di gestire le operazioni riservate come l’assegnazione di spazio di memoria, la lettura e la scrittura dal disco e così via. Vecchi sistemi operativi come Mac OS usavano invece una modalità detta “cooperativa”, per cui era il programmatore dell’applicativo a dover esplicitamente “lasciare spazio” agli altri programmi.

Da diverso tempo i kernel sono eseguiti in una modalità diversa (kernel space) rispetto a quella dei programmi normali (user space). Ci si rese conto ben presto, infatti, che un programmatore malintenzionato avrebbe potuto compromettere il funzionamento del kernel se questo fosse stato eseguito con gli stessi permessi dei programmi comuni, e per lo stesso motivo non era possibile lasciare il controllo di operazioni chiave come l’allocazione della memoria o le operazioni sul disco ai programmi comuni: per capire perché ciò sia importante basta immaginare la possibilità di riscrivere una porzione di memoria di un altro programma con codice malevolo, ad esempio per far sì che il browser invii le credenziali della banca a un certo indirizzo. Giovenale chiedeva “quis custodiet ipsos custodes?”, ovvero “chi controlla i controllori?”, e il problema era proprio questo: creare un garante della correttezza del kernel, oppure isolare il kernel. Fu scelta la seconda opzione, più semplice e pratica.

Resta, però, un problema da risolvere: cosa succede se c’è un errore nel kernel? È qui che le strade si separano: l’approccio dei kernel monolitici, scelto ad esempio da UNIX, BSD e Linux (quest’ultimo non più realmente monolitico da tempo), è quello di contenere al proprio interno tutte le funzionalità in un unico blocco che prova a risolvere un eventuale problema internamente e, in caso di fallimento, semplicemente di arrendersi e di forzare il riavvio della macchina (ad esempio con un kernel panic); i microkernel, invece, spostano alcune delle funzionalità chiave in server esterni al kernel vero e proprio così che, se un server va in crash, è possibile riavviarlo senza compromettere la stabilità dell’intera macchina. Un server può, ad esempio, gestire elementi del sistema come i driver, l’accesso ai file system, la gestione della rete e così via. Il microkernel si occupa, dunque, solo della gestione della memoria, dei processi, dei thread e della comunicazione tra processi (IPC, inter-process communication). Tra i microkernel usati commercialmente ricordiamo: QNX, impiegato da BlackBerry; Exec, usato da AmigaOS; EKA2, usato da Symbian. A livello accademico sono di particolare rilevanza Minix, Mach e L4. Windows NT e XNU, il kernel alla base di macOS, sono entrambi ibridi che contengono molti elementi architetturali dei microkernel.

Il vantaggio principale dei kernel monolitici sta nella velocità: essendo tutto contenuto nello stesso programma, non c’è bisogno di effettuare i context switch, ovvero le operazioni necessarie al passaggio da un processo all’altro e che sono decisamente costose da un punto di vista temporale. Tali operazioni rappresentano, per di più, tempo “buttato”: non viene fatto nulla di utile o produttivo. Un microkernel, invece, deve fare continui context switch e affidarsi all’IPC per gestire componenti diverse del sistema e per questo ha prestazioni inferiori.

Per usare una metafora non del tutto realistica, possiamo immaginare un kernel monolitico come l’unico supervisore di un impianto produttivo: si occupa di gestire tutti i macchinari, di programmare la produzione, di effettuare la manutenzione e di garantire che tutto avvenga nel rispetto delle regole; è estremamente efficiente e riesce a svolgere tutti i suoi compiti molto bene, ma nel caso in cui si ammali l’impianto si ferma (il bus factor è pari a 1). Un microkernel, invece, è un supervisore che dà istruzioni a vari responsabili: la comunicazione con essi richiede più tempo rispetto all’esecuzione diretta del supervisore unico, ma dall’altro lato è possibile sostituirli senza fermare tutto.

Chi volesse approfondire la questione può fare riferimento all’ottimo testo Operating Systems: Three Easy Pieces di Remzi Arpaci-Dusseau e Andrea Arpaci-Dusseau, liberamente scaricabile dal sito ufficiale.

Zircon: un microkernel per tutti?

Zircon è rilevante perché è pensato per operare su molteplici dispositivi, da quelli IoT fino ai computer, e rappresenta per molti versi un rimpiazzo del kernel Linux. È stato introdotto per la prima volta su un prodotto commerciale il 25 maggio 2021, quando è stato reso disponibile per Google Nest Hub; è lecito prevedere che verrà usato su molteplici altri dispositivi in futuro.

Nello specifico, Fuchsia potrebbe rimpiazzare Android e Chrome OS per come li conosciamo ora. Come è stato fatto per il Nest Hub, così potrebbe accadere anche per altri dispositivi: l’interfaccia utente e le applicazioni rimarrebbero gli stessi, ma le componenti di sistema cambierebbero radicalmente. Ciò darebbe a Google un maggiore controllo sullo sviluppo dei sistemi, che attualmente dipendono da Linux. Si tratta, comunque, solo di ipotesi e al momento non ci sono sufficienti prove che questo sia il piano di Google, per quanto un articolo di Bloomberg del 2018 affermi che ci sia la volontà di portare Fuchsia su smartphone e portatili entro il 2023. Tale articolo aveva previsto che Google avrebbe lanciato Fuchsia sui dispositivi IoT “entro tre anni” e tale previsione si è rivelata azzeccata, dunque c’è motivo per credere che anche il resto possa essere corretto.

Un aspetto particolarmente interessante di un approccio a microkernel è che è teoricamente possibile creare dei driver in user space che non richiedono necessariamente un aggiornamento se cambia il sistema operativo. In questo modo sarebbe possibile avere smartphone che vengono aggiornati per diversi anni anche in assenza di supporto da parte dei produttori dell’hardware. In questo modo Google potrebbe teoricamente emulare il modello di Windows Phone, in cui è lei stessa a gestire gli aggiornamenti del sistema, superando l’attuale frammentazione estrema che caratterizza il panorama di Android.

Per chi fosse curioso, è già possibile provare Fuchsia e Zircon: dahliaOS è una distribuzione di Fuchsia che è possibile provare già ora sul proprio hardware. È disponibile sul sito ufficiale del progetto, dove è possibile scaricarne delle immagini installabili e consultare l’elenco dei dispositivi compatibili.

L’aspetto forse più interessante di tutta la vicenda è che Google sembra puntare a un cambiamento “sotto il cofano” che sia invisibile all’utente, grazie (anche) all’uso di programmi scritti in linguaggi portabili come Java e Flutter/Dart. Se Google riuscisse davvero a cambiare completamente il sistema sottostante per lasciare intatte le applicazioni, avrebbe raggiunto un risultato estremamente significativo a livello tecnico (e commerciale). Quanto ciò sarà possibile dipenderà anche dalla gestione dei rapporti di potere presenti tra le varie divisioni all’interno di Google.

Fonte: http://feeds.hwupgrade.it/