EO_503

DIGITAL SECURITY di accesso a un determinato indirizzo mappato in memo- ria, sia per l’esecuzione del codice che per la lettura/scrit- tura dei dati. Ma dove viene eseguita effettivamente l’ap- plicazione? La corrispondenza tra lo stato di sicurezza corrente del processore e la politica di accesso per un determinato in- dirizzo, viene valutata da una “fase” di sicurezza dedicata situata all’interno del limite del core della CPU. Questa va- lutazione viene eseguita prima che l’indirizzo in questione venga propagato al sistema di bus interno (ne parleremo più avanti). Se la policy di accesso viene violata, allora vie- ne generata un’eccezione (ovvero una notifica di interru- zione), secondo la figura 1. Di conseguenza, l’applicazione può reagire a essa e, in base alle esigenze, eseguire azioni definite dall’utente (come il riavvio di un servizio specifico, la registrazione dell’even- to, la segnalazione di un guasto ad altre apparecchiature e così via). Osservando la figura 1, è facile vedere che il software ese- guito in modalità “sicura” ha accesso illimitato ai dati, ma può recuperare ed eseguire direttamente istruzioni solo da aree di programma definite come sicure. Il software non sicuro può invece accedere solo a dati non protetti ed ese- guire solo software non sicuro, ma non può accedere a nes- suna risorsa sicura. Meccanismi di comunicazione Ma allora, come comunicano tra loro i due mondi? Il caso che ogni ambiente sia completamente indipendente e autonomo dall’altro sembra poco significativo; ci si può aspettare che il software applicativo non protetto debba accedere a risorse e “servizi” che si trovano all’interno del dominio protetto. L’obiettivo finale sarà quello di disporre di unmodo controllato, definito dall’utente, per consentire all’applicazione sicura e a quella non sicura di interagire tra loro. Fortunatamente, esiste un meccanismo per farlo. Per ese- guire qualsiasi funzione di sicurezza, la CPU deve modi- ficare il suo stato (ovvero il suo attributo di sicurezza) da non sicuro a sicuro e, per farlo, può utilizzare un’istruzione speciale dedicata chiamata “gateway sicuro” (SG), la quale, se immediatamente seguita da un’istruzione di “branch” (cioè “salta”) all’indirizzo della funzione di sicurezza de- siderato, permette di saltare senza emettere un’eccezione. Quando la funzione di sicurezza ritorna, lo stato del pro- cessore torna automaticamente alla modalità non sicura. Un esempio di allocazione delle risorse tra ambiente pro- tetto e non protetto è fornito nella figura 2. Tutte le coppie di istruzioni “SG + indirizzo di salto” devo- no essere allocate in un’area speciale definita “ non-secure callable ”. Un’area “ non-secure callable ” è considerata sicura. In dettaglio, tutti i parametri di funzione, come i puntatori di memoria e i riferimenti ai buffer, passati dalle funzioni “ non-secure callable ”, possono essere testati per il loro at- tributo di sicurezza per assicurarsi che la funzione chia- mante abbia davvero i permessi di accesso appropriati (ad esempio, per verificare che un buffer di memoria si trova realmente in una memoria non sicura e non si sovrappone alla memoria sicura, quindi non vi è alcun rischio di per- dita di dati). Questo controllo può essere eseguito tramite un’istruzione specializzata “test target”. Infine, è anche possibile che una funzione non protet- ta debba essere richiamata mentre la CPU è in modalità protetta. Questo, potrebbe essere valido, ad esempio, per notificare alla funzione chiamante lo stato della richiesta, inviare alcune notifiche relative al RTOS e così via. Il com- pilatore può gestire questa situazione, generando un’ap- propriata istruzione di salto speciale, che cambia lo stato in non protetto prima della chiamata e invia l’indirizzo di ritorno allo stack sicuro. L’importanza degli interrupt I sistemi embedded sono fortemente guidati dagli inter- rupt e in un tale scenario dobbiamo considerare cosa suc- cede quando arriva un’interruzione mentre la CPU si trova in uno stato particolare. Nel caso in cui si verifichi un’in- Fig. 2 – Funzioni non sicure eseguibili ELETTRONICA OGGI 503 - GIUGNO/LUGLIO 2022 47

RkJQdWJsaXNoZXIy Mzg4NjYz