Unidad de Protección de Memoria / MMU en el contexto de múltiples núcleos y problemas de seguridad

5

Hay un conjunto de chips con el que estoy trabajando que utiliza un ARM cortex-A7 como procesador de aplicaciones y un procesador de banda base ARM 9.

Tenía una gran preocupación ya que ARM cortex A7 está utilizando Android que MPU y / o MMU podrían subvertirse para ver toda la DRAM que incluye el lado ARM9 también. Aunque la arquitectura parece sugerir que están utilizando una MPU, mi preocupación es que, dado que el kernel de Android se puede subvertir, la MPU podría reconfigurarse en el tiempo de ejecución para eliminar las restricciones. La preocupación no es solo que el kernel de Android de este dispositivo incrustado pueda estar enraizado, sino que se pueda producir una escalada privilegiada para que un proceso del kernel en tiempo de ejecución pueda modificar los registros de la MPU (supongo). Aunque estos procesadores tienen una zona de confianza, sin embargo, no se ha creado nada fuera del conjunto de chips, lo que significa que no hay un concepto de NSbit para delinear entre mundo seguro y no seguro.

¿Qué tipo de vulnerabilidades podría tener en cuenta y si mis preocupaciones son legítimas? Por último, el dispositivo tiene un arranque seguro, pero el lado del procesador de Aplicaciones es el que me preocupa mucho y, por supuesto, en el tiempo de ejecución. Cualquier ayuda con posibles vulnerabilidades y / o soluciones sería apreciada.

    
pregunta Dave Powell 15.10.2013 - 21:25
fuente

1 respuesta

1

Todos los SoC que he visto con esta configuración han manejado esta situación al tener registros MPU que solo se pueden escribir desde el procesador de banda base "seguro" o desde TrustZone. Como escribiste, es prácticamente imposible evitar que el mundo de las aplicaciones sea hackeado / rooteado, pero mientras las MPU no puedan ser reconfiguradas desde el kernel de Linux, entonces todavía tienes una protección razonable. No estoy de acuerdo con la afirmación de que el micro kernel que no es de código abierto sería más seguro, hay muchas vulnerabilidades en el código de banda base ...

Editar: No he trabajado con el Qualcomm MSM8x10 / 8x12 (familia Snapdragon 200) específicamente, pero la arquitectura parece muy familiar a los chips Snapdragon 400/600/800 más potentes con xPUs (unidades de protección) en todo el lugar (protegiendo memorias y periféricos) .

También estaría muy sorprendido si el bit NS no se respeta (se trata en todos los demás SoCs de Snapdragon con los que he trabajado). Sin embargo, los detalles de la solución de seguridad son algo que Qualcomm tendrá que revelarle a usted a través de los canales de soporte normales.

En cuanto a los vectores de ataque, ha habido muchos enfoques diferentes, desde la utilización de interfaces JTAG que la gente olvidó desactivar hasta los ataques muy avanzados en el software de bajo nivel. Al final, todo depende de qué tan interesante sea el objetivo de su aplicación: los teléfonos celulares tradicionalmente han sido un objetivo de alto valor en el que las personas están tratando de obtener acceso a la banda base para cambiar el bloqueo de SIM y / o el número IMEI / MEID. La mayoría de los piratas informáticos en estos días están más preocupados por obtener acceso completo al lado de la aplicación (rooting), por lo que siempre y cuando no lo hagas demasiado difícil, te dejarán solo en banda base.

Si la seguridad se ha configurado correctamente, obtener acceso a la memoria del Entorno de Ejecución Confiable (ETE) de TrustZone en el lado de la aplicación y el acceso a la memoria de banda base debería ser muy difícil desde el mundo no seguro. No hay forma de que el conjunto de chips sea aprobado para los esquemas DRM más serios si este no fuera el caso.

    
respondido por el wj. 13.01.2014 - 02:58
fuente

Lea otras preguntas en las etiquetas