Unità di protezione memoria / MMU nel contesto di più core e problemi di sicurezza

5

C'è un chipset con cui lavoro che utilizza una corteccia ARM -A7 come processore dell'applicazione e un processore ARM 9 Baseband.

Ho avuto una grande preoccupazione poiché la corteccia ARM A7 utilizza Android che la MPU e / o la MMU potrebbero essere sovvertite per vedere l'intera DRAM che include anche il lato ARM9. Sebbene l'architettura sembri suggerire che stanno utilizzando una MPU, la mia preoccupazione è che dato che il kernel di Android può essere sovvertito, è possibile riconfigurare la MPU in fase di runtime per rimuovere le restrizioni. La preoccupazione non è solo il fatto che il kernel di Android di questo dispositivo embedded possa essere rootato, ma che l'escalation con privilegi potrebbe verificarsi in modo che un processo del kernel in fase di runtime possa modificare i registri MPU (sto indovinando). Sebbene questi processori abbiano trustzone, tuttavia, non è stato creato nulla dal chipset, il che significa che non esiste un concetto di NSbit per delineare tra mondo sicuro e non sicuro.

Quali tipi di vulnerabilità potrei guardare e se le mie preoccupazioni sono legittime? infine, il dispositivo ha un avvio sicuro, ma è il lato del processore Applicazioni che ho serie preoccupazioni e ovviamente in runtime. Qualsiasi aiuto con potenziali vulnerabilità e / o soluzioni sarebbe apprezzato.

    
posta Dave Powell 15.10.2013 - 21:25
fonte

1 risposta

1

Tutti i SoC che ho visto con questa configurazione hanno gestito questa situazione avendo i registri MPU solo scrivibili dal processore "sicuro" in banda base o da TrustZone. Come hai scritto è praticamente impossibile mantenere il mondo delle applicazioni da hackerato / rootato, ma finché la MPU non può essere riconfigurata dal kernel di Linux, allora hai ancora una protezione ragionevole. Non sono d'accordo con l'affermazione che il micro-kernel non-opensource sarebbe comunque più sicuro - molte vulnerabilità nel codice in banda base ...

Modifica: Non ho lavorato in particolare con Qualcomm MSM8x10 / 8x12 (famiglia Snapdragon 200), ma l'architettura sembra molto familiare ai più potenti chip Snapdragon 400/600/800 con xPU (Protection Unit) ovunque (protezione di memorie e periferiche) .

Inoltre sarei molto sorpreso se il bit NS non viene rispettato (è trattato in tutti gli altri SoC Snapdragon con cui ho lavorato). I dettagli della soluzione di sicurezza sono qualcosa che Qualcomm dovrà rivelarti attraverso i normali canali di supporto.

Per quanto riguarda i vettori di attacco, ci sono stati molti approcci diversi, dall'uso delle interfacce JTAG che le persone hanno dimenticato di disabilitare agli attacchi molto avanzati sul software di basso livello. Alla fine tutto dipende da quanto sia interessante il target della tua applicazione: i cellulari sono stati tradizionalmente un target di alto valore in cui le persone cercano di accedere alla baseband per modificare il SIM-lock e / o il numero IMEI / MEID. Al giorno d'oggi la maggior parte degli hacker è più preoccupata di ottenere un accesso completo al lato dell'applicazione (root), quindi finché non si sta facendo troppo difficile, si spera che lasceranno la baseband da sola.

Se la sicurezza è stata impostata correttamente, ottenere l'accesso alla memoria del TrustZone Trusted Execution Environment (TEE) dal lato dell'applicazione e l'accesso alla memoria della banda base dovrebbe essere molto difficile dal mondo non sicuro. Non è possibile che il chipset venga approvato per gli schemi DRM più gravi, se così non fosse.

    
risposta data 13.01.2014 - 02:58
fonte

Leggi altre domande sui tag