EMB_63

EMBEDDED

63 • FEBBRAIO • 2017

CONNECTED CAR |

SOFTWARE

SK - Separation Kernel

I principi prima delineati non rappresentano cer-

to una novità. L’introduzione della virtualizza-

zione assistita dall’hardware (Intel VT, ARMv7

& v8, estensioni della virtualizzazione NXP, vir-

tualizzazione MIPS e così via) ha permesso di eli-

minare gli oneri aggiuntivi legati alla loro imple-

mentazione pratica, trasferendo questo processo

dal software all’hardware.

Il Separation Kernel abbina i principi del minimo

privilegio e degli SK con questa tecnologia di vir-

tualizzazione dell’hardware in modo consentire

l’implementazione di ogni “soggetto” teorico sotto

forma di VM. Quindi, contro i 19,5 milioni di linee

di codice sorgente (SLOC – Source Line of Code)

richieste dal KVM dell’hypervisor di tipo 1, un ap-

proccio come quello appena descritto dà luogo a un

SK che richiede circa 25.000 SLOC, che rappresen-

ta una risorsa condivisa senza dubbio più semplice.

I principi del minimo privilegio sono soddisfatti

assicurando che l’SK non includa nulla che pos-

sa essere gestito logicamente nello spazio uten-

te (User Space) compresi driver dei dispositivi,

VMM (VM monitor) e stack di I/O critici.

Per quanto riguarda le funzionalità dell’hypervi-

sor non vi è spazio per i compromessi, in quanto

ciascuna VM è dotato di una “Virtual Motherbo-

ard” che fornisce le risorse previste dall’architet-

seguenza, ciascun sistema operativo supportato

dall’hardware sottostante può essere ospitato

dall’SKH (Separation Kernel Hypervisor).

Microkernel

A questo punto val la pena segnalare che il prin-

cipio del minimo privilegio non riguarda solo l’SK.

La tecnologia microkernel, che sfrutta tale princi-

pio di essenzialità,

’era prece-

dente a quella della virtualizzazione dell’hardwa-

re e ha rappresentato una soluzione senza dubbio

valida considerando l’hardware allora disponibile.

A quei tempi gli architetti che si occupavano della

realizzazione del microkernel potevano prendere

in considerazione due livelli di privilegi (livello su-

pervisore e livello privilegi dell’utente) e molti di

essi hanno sfruttato in modo egregio tali privilegi

facendo girare il codice potenzialmente vulnerabi-

le (come ad esempio i driver dei dispositivi) nello

spazio utente (User Space) piuttosto che nello spa-

zio supervisore (Supervisor Space).

L’avvento della virtualizzazione dell’hardware è

stato accompagnato da un livello di privilegio per il

VMM (Virtual Machine Monitor) che ha comporta-

to l’insorgere di un dilemma per quel che riguarda

l’architettura del microkernel. Nel caso venga igno-

rato il livello di privilegio più elevato, si viene a cre-

non è tenuto assolutamente conto. Per contro, nel

caso i privilegi del codice relativo al precedente spa-

zio supervisore siano trasferiti a questo nuovo livel-

lo di privilegio, vi sarebbe una notevole quantità di

codice che gira a un livello più alto rispetto a quello

necessario per lo svolgimento della sua funzione.

Nella fattispecie, il progetto del microkernel ha su-

bito un’evoluzione per gestire la virtualizzazione

dell’hardware e i livelli di privi-

legio associati e alcuni microker-

nel possono persino utilizzare la

virtualizzazione dell’hardware.

È comunque inevitabile che uno

sviluppo di questo tipo abbiamo

portato all’adozione di un com-

promesso in virtù del quale par-

te del codice girerà a un livello

di privilegio più elevato rispetto

a quanto previsto dal principio

del minimo privilegio. Nei casi in

cui la sicurezza rivesta un’impor-

tanza critica, un compromesso di

questo tipo non è accettabile.

Una soluzione di separazione per

applicazioni “security critical” ca-

pace di minimizzare in modo ot-

Fig. 3 – La sovrapposizione dei principi del minimo privilegio (Least

Provilege) sui blocchi dell’SK garantisce una granularità molto fine

per quanto riguarda il controllo a livello di risorse e soggetto