72 / 84
EMBEDDED
63 • FEBBRAIO • 2017
72
SOFTWARE
|
CONNECTED CAR
scopo e utilizzando un hyper-
visor al posto della separa-
zione hardware (Fig. 2).
La funzionalità dell’hypervi-
sor è importante in quanto
Á
-
re il comportamento della Te-
sla che prevede comunicazioni
molto limitate tra due appli-
cazioni molto differenti (mac-
chine virtuali o VM) – una per
gestire i controllori dei veicolo
e l’altra per gestire i sistemi di
infotainment. In un contesto
di questo tipo potrebbe ave-
re senso un’API strutturata e
complessa come quella sviluppata da Tesla.
Quando si ha a che fare con la sicurezza, è indi-
spensabile che anche nel caso in cui la macchi-
na virtuale che gestisce la parte di infotainment,
quindi connessa al mondo esterno, venga sottopo-
sta a un attacco informatico che ne compromette
la funzionalità, la macchina virtuale che gestisce i
controller del veicolo non risulti vulnerabile. Se le
macchine virtuali devono essere realmente sepa-
rate anziché congiunte mediante l’hypervisor, è di
À
sia la
più ridotta possibile: per conseguire un risultato di
questo tipo è necessario minimizzare le risorse con-
divise tra le macchine virtuali.
Hypervisor di tipo 1
Per illustrare questo punto si prenda in consi-
derazione una KVM (Kernel-based Virtual Ma-
chine), un’infrastruttura di virtualizzazione per
il kernel Linux che trasforma il kernel stesso in
un hypervisor (6) . Ciò serve semplicemente come
esempio di un problema comune con ogni hyper-
visor di tipo 1.
Nel caso la macchina KVM di Linux fosse l’hyper-
visor scelto per l’astrazione del sistema automoti-
ve preso in considerazione, la sicurezza della VM
relativa ai controllori del veicolo sarebbe basata
su un kernel monolitico con un minimo di 390
interfacce, centinaia di migliaia di opzioni per
quanto concerne i parametri e implementato per
mezzo di 19,5 milioni di linee di codice in continua
evoluzione. Senza dimenticare che lo stack di I/O
risiede nel kernel monolitico dell’hypervisor, ren-
dendo in tal modo disponibile un vettore di attac-
co di semplice accesso contro la VM in questione.
La macchina KVM di Linux si comporta esatta-
mente come l’hypervisor richiesto per supportare
la funzionalità del sistema. Se lo scopo principale
è la separazione tra macchine virtuali di differen-
ti criticità, un approccio di questo tipo non è si-
curamente quello ottimale. Un approccio miglio-
re prevede di realizzare un’architettura che dia
priorità alla separazione e alla minimizzazione
À
-
tempo la funzionalità di hypervisor.
I concetti di Least Privilege (privilegio minimo)
e di Separation Kernel (SK) sono utili per com-
prendere in che modo sia possibile conseguire
questo obiettivo.
Least Privilege e Separation Kernel
Il concetto di Separation Kernel (SK), introdotto
per la prima volta da John Rushby (7) nel 1981,
dovrebbe essere formato da “una combinazione di
hardware e software che permetta l’implementa-
zione di più funzioni sfruttando un insieme co-
À
-
renze mutue non desiderate”.
In modo del tutto analogo, 30 anni fa Saltzer and
Schroeder (8) suggerivano che “ogni programma e
ogni utente del sistema dovrebbe funzionare uti-
lizzando l’insieme minimo di privilegi necessari
per portare a termine il proprio compito “.
Un approccio architetturale basato sulla fusione
dei due concetti appena esposti garantisce che
ogni entità attiva, eseguibile (soggetto) disponga
À
propria funzione (Fig. 3) e null’altro.
Fig. 2 – Questo astrazione di un sistema automotive evidenzia l’impor-
tanza della separazione