EMB_72

EMBEDDED 72 • MAGGIO • 2019 40 SOFTWARE | FUNCTIONAL SAFETY deve garantire che la separazione sia conforme agli standard di sicurezza. Chiaramente questo tipo di SoC elimina alcuni dei colli di bottiglia nella comunicazione e nello scam- bio dei dati, per lo meno se si riesce a utilizzare in modo sicuro la memoria condivisa interna del SoC o percorsi simili. Ma rimane ancora da risolvere il problema della scalabilità degli algoritmi tra do- minio di sicurezza e dominio operativo, poiché il $À - to alla piccola MCU incorporata in un grande SoC. Ciò che serve è un modo per eseguire sia gli algo- ritmi di sicurezza che gli algoritmi operativi sugli stessi core in qualsiasi circuito inetegrao SoC. In altre parole, occorre un software di alto livello in grado di creare isolamento e separazione. Un’idea comune è pensare che l’unico modo di separare il software sia la virtualizzazione tramite hypervi- sor, ma è il caso di considerare anche l’architettu- ra dei kernel a separazione. Kernel a separazione software Un buon kernel a separazione fornisce un isola- mento equivalente a un isolamento di tipo hard- ware 9 À À - mente l’architettura generale del sistema creando un dominio operativo e un dominio di sicurezza nello stesso sistema operativo RTOS. L’RTOS IN- TEGRITY di Green Hills Software è un esempio di architettura RTOS con kernel a separazione. Su questo tipo di sistema è suf- À % % sicurezza (SIL) a un solo sottoinsieme appli- cativo, mentre il resto può rimanere al livel- lo di codice di qualità standard. Ciò favori- sce la realizzazione di algoritmi di sicurezza scalabili, in quanto è possibile eseguire tali algoritmi operativi all’interno del dominio di sicurezza, ma non è necessario eseguirli tutti lì. Poiché il codice di ciascuna applicazione è isolato in fase di progetto dal codice delle al- tre applicazioni, non serve più collaudare e À # - zione di questo approccio torna utile alle varie parti . *!) Q?Q?Q N À - ne risulta di conseguenza notevolmente più sem- plice. Il dominio di sicurezza e il dominio operativo possono quindi trovarsi sullo stesso SoC, purché il kernel a separazione supporti gli effettivi core del SoC. Un esempio di questa soluzione è illustrato À% H Quando si considerano le prestazioni di questi sistemi occorre tener presente che, anche se si ha accesso al codice del sistema operativo, a livello hardware ci sono cache e pipeline e altre ot- timizzazioni che non è proprio possibile vedere, se non dal fatto che le prestazioni sono variabili. L’ap- # À ottimizzata nel contesto in cui verrà eseguita, per cui solo allora le prestazioni reali potranno essere misurate. Un altro vantaggio offerto dai kernel a separazione è che consentono di consolidare il soft- ware dedicato a più funzioni sullo stesso dispositivo ! % L À - tanto che la piattaforma è in grado di offrire pre- stazioni adeguate, è ragionevole integrare sempre più funzioni indipendenti sulla piattaforma senza dover riprogettare l’hardware. Separazione tramite virtualizzazione L’altro metodo per ottenere la separazione soft- ware è generalmente chiamato virtualizzazione hardware. Virtualizzazione hardware % À vengono scelti percorsi di esecuzione speciali per consentire a più sistemi operativi di condividere la CPU e la memoria del circuito integrato SoC. L’in- frastruttura che consente di ottenere ciò si chiama hypervisor, o monitor di macchine virtuali, che crea Fig. 4 – Architettura con kernel a separazione, con dominio di sicurezza e dominio operativo Fig. 5 – Tipica architettura a separazione con hypervisor di tipo 1