76 / 84
EMBEDDED
58 • novembre • 2015
software
|
SAFETY & SECURITY
76
ne, ha senso consegui-
re un obiettivo comune
che contempli anche il
concetto di sicurezza
utilizzando le migliori
procedure di protezione
per garantire la difesa
richiesta. Laddove ad
esempio è richiesta la
possibilità per un’appli-
cazione “safety-critical”
di accedere a Internet,
l’adozione di un kernel di
tipo LPSK (Least Privi-
lege Separation Kernel),
rappresenta l’approccio ideale per garantire che
questo accesso non possa compromettere la pro-
tezione e di conseguenza la sicurezza del sistema.
Un SK (Separation Kernel) tradizionale è pro-
gettato per poter ospitare applicazioni e rendere
disponibile un framework di sviluppo in modo da
consentire agli architetti di sistema di realizzare
sistemi di natura modulare adottando il classico
approccio “boxes and arrows”.
L’SK assicura che ciascuna applicazione giri
all’interno di una partizione protetta (box) con
risorse hardware isolate ed è disponibile un mec-
canismo per comunicare (arrow) tra le partizioni
e i dispositivi esterni in modo tale che i flussi di
informazione in un sistema siano esplicitamente
definiti e mediati. Grazie alla protezione dell’in-
tegrità della logica eseguibile e al controllo della
comunicazione del sistema, i progettisti sono in
grado di realizzare sistemi che possono garantire
la sicurezza e la protezione del software, in vir-
tù del fatto che alcune componenti critiche del
software non possono essere corrotte o spiate da
software dannoso o difettoso. Tutto ciò contribui-
sce a semplificare notevolmente sia lo sviluppo di
sistemi critici sia i processi di certificazione per
gli sviluppatori e per coloro preposti alla valuta-
zione del sistema.
Un kernel LPSK si differenzia da un SK tradizio-
nale per il fatto gli accessi tra i componenti del
kernel host e le interfacce delle partizioni delle
applicazioni esterne sono limitati a quelli stret-
tamente necessari.
Si faccia riferimento ad esempio alla figura 1.
L’obbiettivo in questo caso è garantire la prote-
zione delle applicazioni “safety critical” in modo
tale che queste possano girare in un RTOS oppu-
re sotto forma di applicazioni “bare metal” come
la “trusted app” riportata nella medesima figura.
Le applicazioni come il sistema operativo Linux
possono interagire liberamente con Internet per-
ché il partizionamento tra quest’ultimo e la “tru-
sted app” fa in modo che ogni attacco condotto
con successo contro Linux OS non abbia nessun
impatto sulla “trusted app”.
Una configurazione di questo tipo è efficace se le
due partizioni sono in grado di comunicare, ma
la natura stessa del kernel LPSK assicura che
una comunicazione di questo tipo è attentamen-
te regolata, con conseguente minimizzazione dei
rischi per la sicurezza.
Un’altra caratteristica di rilievo è l’adozione del-
la virtualizzazione completa all’interno di ogni
partizione piuttosto che nel kernel, in modo da
esludere un potenziale punto di accesso per even-
tuali minacce.
Questo tipo di approccio permette anche di mini-
mizzare le dimensioni dell’SK, mentre l’assoluta
indipendenza di qualsiasi driver dei dispositivi
dal kernel si riflette favorevolmente sulle dimen-
sioni – si può arrivare a soli 25k linee di codice.
Più ridotto è il footprint (ovvero la quantità mi-
nima di memoria richiesta dal sistema operativo
ed eventualmente dalle applicazioni) minore è la
quantità di codice condiviso e di spazio dei dati
tra le partizioni, con conseguente riduzione delle
opportunità per eventuali attacchi.
In uno scenario “reale” (Fig. 2) ciò significa che
l’SK regola in maniera accurata i percorsi di
Fig. 2 – L’utilizzo di un SK e di un hypervisor garantisce la sicurezza
funzionale di un sistema di controllo “safety critical” dotato di accesso
a Internet