EMB_88

EMBEDDED 88 • MAGGIO • 2023 58 SOFTWARE | UNIKERNEL alla sua immagine, è possibile ottimizzare le librerie e le configurazioni specifiche che l’applicazione utilizzerà. In questo modo si ottiene un incremento delle presta- zioni senza dover eseguire un intero sistema operativo. I container sono facili da eseguire sulle macchine di svi- luppo e anche il processo di distribuzione è molto più semplice, poiché è sufficiente caricare i container esi- stenti in un repository e i sistemi di produzione posso- no eseguire il pull della versione aggiornata. L’approc- cio basato sui container ha tuttavia i suoi lati negativi. È necessario adattare il software in modo che possa es- sere utilizzato nei container (containerizzato) e questo può essere complicato, soprattutto con le basi di codice legacy. I container includono molte più configurazioni per l’allocazione delle risorse e numerose funzionalità di interoperabilità, per cui è abbastanza facile configu- rarli in modo non corretto. Unikernel La fase logica successiva nel passaggio dalle macchine virtuali ai container sono gli unikernel, che estendono il concetto di container. Gli unikernel sono di fatto un insieme di librerie binarie predefinite. Sono immagini di macchine specializzate e a spazio di indirizzi singo- lo, create utilizzando sistemi operativi basati su librerie. Forniscono allo sviluppatore una scelta di componenti per creare il livello minimo di interfacciamento hardwa- re. In altre parole, offrono le funzioni necessarie per il funzionamento di un’applicazione e nulla di più. Gli unikernel hanno costi generali inferiori rispetto ai container e sono più semplici da utilizzare, il che con- sente di migliorare le prestazioni. Inoltre, eliminando l’uso di un kernel nello spazio utilizzato da più utenti e indirizzi, la sicurezza risulta drasticamente migliorata. Molti degli unikernel di pubblico dominio sono legati a un linguaggio di compilazione specifico, come runtime.js (javascript), Clive (Go), LING (Erlang) e Mirage (Ocaml). Uno di questi, OSv, è in grado di eseguire i runtime in numerosi linguaggi. Esiste tuttavia una serie di problemi associati agli unikernel che ne hanno limitato l’applicazione fino ad oggi . Si tratta degli aspetti seguenti: - La produzione di immagini unikernel è complicata e richiede una conoscenza approfondita dell’argo- mento. - Gli attuali framework applicativi devono adattarsi e produrre documentazione sul loro utilizzo all’inter- no degli unikernel. - Mancanza di certificazioni di sicurezza degli uniker- nel per le applicazioni mission-critical. Confronto tra un sistema operativo e un unikernel 1. Modalità utente e modalità kernel: a differenza dei sistemi operativi, gli unikernel vengono eseguiti in modalità utente. In generale, la modalità kernel è ri- servata alle funzioni di base e più affidabili del siste- ma operativo. In modalità kernel, gli arresti anomali hanno conseguenze devastanti, in quanto compor- tano l’interruzione dell’intero sistema. In modali- tà utente, il codice in esecuzione non è in grado di accedere direttamente all’hardware o alla memoria di riferimento. Un confronto più dettagliato e fat- to molto bene delle due modalità è disponibile qui. Questo è il motivo fondamentale per cui il settore sta nuovamente prendendo in considerazione l’utilizzo degli unikernel. Quasi ogni settimana viene segnala- to un attacco informatico a un’infrastruttura critica, a un’impresa o a un ente pubblico. Il sistema opera- tivo rappresenta un punto debole. 2. Allocazione delle risorse: a differenza di un sistema operativo, gli unikernel non gestiscono l’allocazio- ne delle risorse. L’interoperabilità diretta con l’har- dware viene gestita dall’hypervisor . Viene eseguito il pushing di tutte le chiamate di sistema specifiche di un’applicazione il più vicino possibile all’appli- cazione stessa. Anche questo processo è gestito dall’hypervisor. Per i sistemi sicuri, si dovrebbe uti- lizzare un hypervisor di tipo 1 (in cui non è presen- te un sistema operativo “helper” sottostante), che viene eseguito direttamente sull’hardware e carica le macchine virtuali. Gli hypervisor che si basano su un “sistema operativo host” sottostante rappre- Differenza tra i vari approcci: macchine virtuali, container e unikernel