¿Cómo garantiza Arm's Trustzone la seguridad del hardware?
La primera son los chips para drones, DJI siempre ha estado a la vanguardia y la segunda ni siquiera ha visto una sombra. Varias aplicaciones importantes de los drones, como la transmisión de imágenes, el procesamiento de imágenes, el reconocimiento, el control de vuelo y el almacenamiento, tienen requisitos de seguridad. Trustzone se puede utilizar para garantizar que cada paso del flujo de datos a través del chip esté bajo el control del sistema de seguridad. Incluso si roban el avión, costará mucho obtener los datos en la memoria flash y la memoria. Si utiliza Android u otros sistemas operativos en el futuro, incluso si el sistema de software es pirateado, los datos y el control seguirán estando seguros. Finalmente, si el país o la industria introduce políticas para implementar una zona de exclusión aérea, incluso si el propietario del dron ha modificado la memoria flash y el software, puede apoderarse del dron por la fuerza. Estas funciones deben considerarse durante la etapa de diseño del chip, y DJI tiene una visión más amplia que otros a este respecto.
El segundo es DRM, gestión de derechos digitales, que es la protección de contenidos. Si los usuarios domésticos quieren ver los últimos éxitos de Hollywood en sus teléfonos móviles, el equipo de reproducción debe estar certificado y Trustzone puede lograrlo. China ha estado promoviendo activamente este asunto y se espera que se haga realidad dentro de un tiempo. Por supuesto, esto es un arma de doble filo. Definitivamente habrá algunos usuarios que no estén dispuestos a comprar dispositivos habilitados para DRM para observar la piratería. El uso de Trustzone en sí no restringe la piratería, pero proporciona un canal adicional para ver éxitos de taquilla de Hollywood.
El tercero es el pago. No existe ninguna dificultad técnica al utilizar Trustzone para realizar pagos y los requisitos de rendimiento del chip no son elevados. La parte difícil es equilibrar a todas las partes interesadas. Los bancos y operadores quieren tomar el control de los pagos en sus propias manos, por lo que promoverán vigorosamente NFC y cooperarán con Apple. Los fabricantes de software de pagos móviles, como Alipay y WeChat, quieren realizar todas las funciones en sus propias plataformas cooperando con los fabricantes de chips y hardware de teléfonos móviles. Actualmente, la mayoría de los pagos todavía se basan en software y autenticación de clave remota. Si alguien piratea el teléfono, aún se puede leer la contraseña de la capa de pago. Trustzone lo que hace es prevenir esta situación en el hardware.
El cuarto es el Internet de las Cosas. Hay varias formas de implementar la seguridad de IoT. La detección de seguridad se puede colocar en el servidor o en el chip del terminal. El terminal suele ser una MCU más sensores y módulos de interconexión, y el área es muy pequeña. Si se implementa con una zona de confianza de hardware, el cifrado, descifrado, administración de claves y otras funciones requieren módulos internos adicionales, que pueden ser más grandes que la propia MCU y el costo es demasiado alto. Pero si se trata de un chip de alto valor añadido no habrá problema.
Definamos técnicamente lo que Trustzone puede hacer:
1. Prevenir la fuga de datos críticos después de una vulneración del sistema operativo. Los datos clave se almacenan en un área de memoria específica que solo puede ser leída por el sistema operativo seguro.
2. Evite que los datos de registro, caché, memoria o flash se lean a través de interfaces de depuración (como JTAG).
3. A partir de la fabricación del chip, la clave inicial se puede implementar mediante el fusible del chip. Cada paso posterior del inicio requiere el nivel de permiso más alto y la verificación de la clave, estableciendo así una cadena de confianza para evitar que se reemplace el software. o malicioso.
4. Evite ataques de banda lateral, como medir datos de adivinación de señales de partículas de memoria, fabricar módulos de detección de parada de fallas, reemplazar dispositivos periféricos, ingresar datos específicos para determinar las características de las señales electromagnéticas y abrir el chip directamente. medir líneas de señal internas.
En la última estructura interna típica de ARM SoC, Trustzone protege la seguridad de los datos internos del chip y no permite el acceso no autorizado, incluso si el acceso proviene de la CPU. Parece un poco complicado a primera vista, pero podemos desglosarlo y analizarlo lentamente. Desde una perspectiva de hardware, es más claro que el software. Quizás después de aprobar la certificación, aún deba responder y explicar el diseño de seguridad del sistema de principio a fin.
En primer lugar, según la división de Trustzone, un chip se divide en un mundo seguro y un mundo inseguro.
La parte negra en el medio de la imagen de arriba es el bus, la parte superior es el dispositivo maestro y la parte inferior es el dispositivo esclavo (el caché en el dispositivo maestro es una excepción, que se discutirá más adelante). Las solicitudes de lectura y escritura siempre se envían desde el dispositivo maestro al dispositivo esclavo.
Como dispositivo esclavo, es relativamente sencillo distinguir si pertenece al mundo seguro. Si el dispositivo esclavo no tiene un bloque asignado de espacio como I2C o PWM, cuando el bus accede a él, puedo saber si el acceso es desde el mundo seguro agregando un pin adicional (llamado PROT). Si el dispositivo esclavo pertenece al mundo de la seguridad protegida y no acepta accesos inseguros, simplemente rechácelo y devuelva datos incorrectos o sin sentido. De manera similar, si el dispositivo esclavo se encuentra en un entorno inseguro, se pueden devolver datos correctos para acceso tanto seguro como inseguro. Además, desde la perspectiva del mundo en el que se encuentra el dispositivo, se puede configurar dinámicamente, y la configuración dinámica en sí debe estar en un mundo seguro, lo cual se discutirá más adelante.
Para los dispositivos de bloques, incluidas la memoria flash, sram y la memoria, algunos de sus bloques de direcciones deben estar en el mundo seguro y otros deben estar en el mundo inseguro. Para lograr esto, se debe insertar un módulo de verificación (como el TZC400 en el DDR a la izquierda en la imagen) frente a ellos para determinar si se puede acceder a una dirección. Cuando la dirección se envía al módulo de verificación, el módulo buscará la tabla usando el pin PROT para ver si el acceso está permitido y luego tomará las medidas adecuadas. Al igual que con la configuración dinámica anterior, la propia tabla debe configurarse en un entorno seguro.
En este punto, se completa el análisis en el dispositivo. ¿No parece particularmente simple? Aún quedan algunos detalles una vez completado el equipo principal, le prestaremos atención desde la perspectiva del sistema.
Para el dispositivo maestro general, independientemente de su propio caché, en realidad es similar al dispositivo esclavo. También se divide en seguro y no seguro y se puede configurar dinámicamente en el mundo seguro. Una vez completada la configuración, estos dispositivos maestros accederán a los dispositivos esclavos de acuerdo con el pin y la dirección PROT de su propio controlador mundial y obtendrán los retornos correspondientes. Pero el dispositivo principal general aquí no incluye el controlador de interrupciones, la MMU del sistema, el módulo de depuración y el procesador, y luego analiza estos módulos anormales en detalle.
El primero es el procesador.
En la situación anterior, después de conectar el bus CCI, el procesador se conecta al puerto de coherencia de caché ACE (consulte el artículo anterior si no comprende que se puede acceder a su caché). otros, y este acceso es desde el dispositivo principal al dispositivo maestro (por supuesto el puerto esclavo dentro del procesador), no se enviará a la memoria a través del bus, ni pasará por el módulo de detección TZC400. Aquí es cuando hay un vacío legal. Al manipular un módulo en un mundo inseguro, como el dispositivo maestro naranja que se muestra arriba, pretende leer una dirección de memoria protegida por un mundo seguro. Esta dirección existe inicialmente en la memoria, protegida por el TZC400, pero debido a las capacidades de monitoreo del bus, se puede enviar una solicitud de lectura a la memoria caché del procesador, evitando así la protección.
Para evitar esta situación, el procesador diseñó especialmente todas las tablas de páginas y cachés, y agregó un bit de bandera para indicar si esta línea de caché pertenece al mundo seguro. Si otro host mundial no seguro escucha la línea de caché mundial seguro, dado que los bits de seguridad son diferentes, el procesador pensará que son dos direcciones diferentes, aunque sean la misma dirección, y devolverá un error de caché. De esta forma, no se filtrarán datos.
Alguien puede preguntar, este bit de bandera proviene de la tabla de páginas, por lo que se puede acceder cambiando este bit en la tabla de páginas. En realidad no, porque la tabla de páginas del mundo seguro está ubicada en un área de memoria o caché protegida, por lo que no se puede acceder a ella incluso si el sistema operativo está descifrado.
Algunos dirían que cambiar los bits de seguridad en la tabla de páginas del mundo no seguro y falsificar una dirección mundial segura no permite a la CPU simular una transferencia que accede al mundo seguro y la envía al bus y TZC400. TZC400 o el caché de pares verifica que la dirección y el pin PROT cumplan con los requisitos. Debería devolver datos confidenciales, ¿verdad? La idea es buena, pero cuando la CPU está en un mundo inseguro, ignora los bits seguros en la tabla de páginas y, por lo tanto, no puede emitir PROT como una transferencia segura. Así que podemos estar tranquilos al respecto.
Lo anterior es para que otros dispositivos maestros accedan al procesador, por lo que si el procesador en sí está en un mundo inseguro, ¿es posible acceder al caché seguro de otros dispositivos maestros? Por supuesto que sí. Por lo tanto, no conecte otros dispositivos maestros al puerto ACE para evitar ser monitoreados. Normalmente, los dispositivos maestros no diferencian entre cachés seguras y no seguras. No importa si se conecta a la interfaz ACE-Lite, los datos almacenados en caché no están diseñados para ser leídos de todos modos.
Además, hay una excepción, que es la GPU. En el último procesador de gráficos ARM G71, se admite la coherencia de hardware bidireccional. En otras palabras, las GPU también se pueden monitorear y almacenar en caché. Para simplificar el diseño, el procesador gráfico está programado para estar siempre en un mundo inseguro. Aunque la CPU lee, no le importa. Utiliza otro mecanismo para proteger los datos, que se describirá más adelante.
Quienes estén familiarizados con las cachés de los procesadores podrían pensar en utilizar variables no seguras en las líneas de la caché para acceder a datos protegidos. Es inútil. Los diseñadores de procesadores han pensado en esto hace mucho tiempo. Es una excepción de acceso fuera de lugar (incluido el acceso exclusivo) o no proporciona datos.
Todavía hay una vulnerabilidad sin resolver: el mantenimiento de caché, TLB y operaciones de predicción de sucursales. Los puertos ACE contienen operaciones DVM para mantenerlos. ¿Cómo garantizar la seguridad? Asimismo, existen bits seguros y bits no seguros en la dirección. Pero dicho esto, la operación DVM no es más que invalidar algunos cachés, predicciones de rama y entradas de TLB. No existe ninguna situación en la que se lean datos seguros o se altere TLB.
Puede que te sientas un poco mareado aquí, hay muchas lagunas que es necesario tapar. Podemos revisar que lo que hay que recordar son las diversas operaciones de caché, que están protegidas por banderas de seguridad para evitar vulnerabilidades. Esta vulnerabilidad no es nada comparada con lo que los diseñadores de procesadores deben considerar.
Tras eliminar las vulnerabilidades de la caché, existen otros peligros ocultos, como los emuladores. El módulo de depuración se puede utilizar para acceder a varios dispositivos esclavos y también puede acceder y afectar los recursos internos del procesador. La protección desde el lado del dispositivo es fácil, simplemente trate el módulo de depuración como un dispositivo maestro universal. Los registros, cachés y otros recursos dentro del procesador requieren que el procesador esté diseñado con niveles de seguridad definidos para todos los recursos desde el principio. Los recursos protegidos estarán protegidos del acceso no autorizado desde el módulo de depuración. Solo a través de la cadena de arranque segura el software en el mundo seguro puede abrir el registro SDER, lo que permite que los emuladores externos afecten los recursos protegidos del mundo seguro y el estado de ejecución del procesador, y accedan a los recursos protegidos.
¿Cómo se dividen los recursos del procesador? Tome ARMv8 como ejemplo, como se muestra a continuación:
Creo que muchas personas han visto esta imagen. El procesador ARMv8 se divide en cuatro niveles de permisos; generalmente EL0 ejecuta programas en modo de usuario, el kernel EL1 y la máquina virtual EL2. EL0-1 se divide en seguro e inseguro. EL3 solo tiene mundos seguros, EL2 no diferencia entre ellos. El cambio entre los dos mundos debe pasar por EL3. Los recursos internos del procesador del que estamos hablando, incluidos registros, cachés, excepciones y MMU, están todos agrupados. Los niveles inferiores entre grupos son invisibles o inaccesibles para los niveles superiores, lo que garantiza la seguridad. No existen grupos mantenidos por software, como registros de propósito general, que impidan que el mundo no seguro vea los datos del mundo seguro.
Existen varias posibilidades para una conmutación segura: interrupciones e instrucciones SMC. Las interrupciones se dividen en las siguientes situaciones:
En un mundo inseguro, en EL1 o EL0, cuando se produce una interrupción insegura, el sistema no necesita cambiar a un estado seguro. Como interrupción general, simplemente cambie a EL1.
En el mundo no seguro, en EL1 o EL0, cuando llega una interrupción de seguridad, el sistema primero debe cambiar a EL3; de lo contrario, no podrá cambiar al mundo seguro.
En el mundo seguro, en EL1 o EL0, cuando se produce una interrupción de seguridad, no hay necesidad de cambiar el mundo seguro. Como interrupción general, simplemente cambie a EL1.
En el mundo seguro, en EL1 o EL0, cuando se produce una interrupción insegura, el sistema debe cambiar primero a EL3; de lo contrario, no se puede realizar el cambio del mundo seguro.
Al saltar al programa de monitoreo de seguridad EL3 para manejar el cambio de contexto, el bit de máscara de interrupción IRQ/FIQ no funciona y no se activará incluso si está activado. Hasta que el monitor seguro complete el procesamiento y salte al mundo seguro EL1 correspondiente, se restaurará la máscara de interrupción original, lo que desencadenará la interrupción. Lo que maneja la interrupción en este momento es el programa de interrupción en el mundo seguro, que se encuentra en un área de memoria protegida para evitar la manipulación del programa en el mundo no seguro.
Entonces, ¿cómo activar interrupciones seguras e inseguras? Esto se define en el controlador de interrupciones. En la definición inicial, solo se podía utilizar FIQ como interrupción segura, que se podía configurar más adelante. Además, sólo se puede acceder a los registros de configuración del mundo seguro correspondientes dentro del mundo seguro del procesador.
El comando SMC es similar al disparador de interrupción, excepto que el software puede disparar y cambiar al monitor de seguridad. Aquí, el software no seguro puede emitir solicitudes de activación y completar parámetros en registros de propósito general, pero no tiene control sobre lo que hace el procesador en el mundo seguro y aún así no puede ver los datos de la memoria protegida. Por lo tanto, la tarea de prevenir las filtraciones de datos depende de un sistema operativo seguro.
En este punto, la protección básica del hardware después del arranque seguro se ha completado, pero si crees que esto es Trustzone, estás equivocado, la emoción vendrá más tarde.
Podemos poner Trustzone en aplicaciones prácticas para ver si funciona. Tome DRM como ejemplo, como se muestra a continuación:
Cuando se reproducen vídeos autorizados, la transmisión de vídeo proviene de la red o de la memoria flash y no necesita estar en un mundo seguro porque los datos en sí están cifrados. Luego se descifra y se coloca en la memoria protegida, en espera de ser decodificada. En la imagen de arriba, la protección y el descifrado con contraseña se completan mediante el módulo de hardware de seguridad Crypto. Analizaremos esto más adelante y primero nos ocuparemos de la transmisión de vídeo descifrada. En este punto, hay dos opciones:
Primero, naturalmente, todos los procesos se pueden completar en el mundo seguro, por lo que el procesador de gráficos, el procesador de video y el módulo de visualización deben funcionar en el mundo seguro, y el capacidad de acceder a datos en un mundo seguro antes de poder realizar su trabajo. Pero esto plantea un problema: la conducción. Sabemos que el controlador del procesador de gráficos es muy complicado. Los teléfonos móviles solo tienen controladores de gráficos para Linux y Windows, que funcionan con OpenGL ES/DirectX.
Los sistemas operativos del mundo seguro (TEE) son completamente incompatibles, y algunos ni siquiera soportan SMP, por lo que no hay posibilidad de portar el controlador gráfico y no tiene sentido. Esto solo puede sacar el procesador de gráficos del proceso, dejando solo los controladores del módulo de visualización y video relativamente simples y ecológicos, trabajando en un mundo seguro, con la salida de la GPU enviada al módulo de visualización, una mezcla.
Esta es una solución factible y algunas empresas lo hacen. Pero a la larga, el procesador gráfico siempre estará involucrado en el proceso. Si la realidad virtual y la realidad aumentada se vuelven populares, y si aparece una pantalla virtual y se reproducen videos en ella, definitivamente habrá interacción. En este punto, el módulo de visualización debe enviar la capa de video de regreso a la GPU para su funcionamiento. Si la GPU no está en el mundo seguro, se producirán fugas.
Para resolver los problemas anteriores, existe una segunda solución llamada TZMP 1 (Trusted Zone Media Protection 1), que introduce el concepto de proteger el mundo.
Protege el mundo y trabaja en un mundo inseguro, siendo así compatible con los controladores de tarjetas gráficas. ¿Qué pasa con la seguridad? Requiere agregar cuatro pines NSAID, que son similares a la señal PROT en el mundo de la seguridad, pero divididos más finamente, de modo que cuando el módulo GPU/vídeo/pantalla quiera acceder a la memoria protegida, los permisos se definen de antemano. La configuración de este permiso también se logra a través del TZC400 mencionado anteriormente y se completa en la cadena de inicio segura. El permiso de la CPU suele ser 0, que es el más bajo. Los permisos del controlador de pantalla son de solo lectura.
Así, nuestro viejo problema, el monitoreo de caché malicioso, ha vuelto. En el nuevo sistema de bus de A73 y G71 más CCI500/550, se puede admitir la coherencia de hardware bidireccional. Esto significa que también se pueden monitorear las GPU. Todos vivimos ahora en un mundo inseguro y el bit de seguridad en el caché no funciona. ¿Cómo solucionarlo? Esto requiere la cooperación de los autobuses.
El bus CCI500/550 de ARM dispone de un modo de protección. Cuando está activado, no solo admite el pin NSAID anterior, sino que también puede usar un comando de invalidación de línea de caché para reemplazar la transmisión de monitoreo durante el monitoreo, lo que permite que el objetivo invalide directamente la línea de caché correspondiente. De esta manera, los datos aún deben leerse de la memoria para garantizar la seguridad. Y este proceso es transparente para el software y no requiere ningún cambio.
Sin embargo, la consistencia del hardware que trabaja arduamente no se puede acelerar en este momento y el rendimiento se ve afectado. Afortunadamente, cuando se ejecuta OpenGL ES, la GPU no emite * * * para disfrutar de la transferencia y la CPU no monitorea inactivamente los datos de la GPU. La interfaz gráfica de próxima generación, Vulkan, comenzará a utilizar la coherencia bidireccional de GPU, lo que tendrá un impacto en ese momento. Otra desventaja es que si OpenCL y DRM se ejecutan simultáneamente, OpenCL no requiere coherencia de hardware bidireccional y el sistema debe reiniciarse para cambiar al modo desprotegido.
Además, en el uso real, el TZC400 existente tiene varios defectos fatales como módulo de protección de memoria.
En primer lugar, su configuración solo se puede completar al inicio y no se puede cambiar dinámicamente. En otras palabras, una vez que se entrega cierta memoria al mundo seguro, el sistema operativo del mundo no seguro ya no puede usarla, incluso si está inactiva. Al reproducir vídeo 4K, es necesario asignar cientos de megabytes de memoria, no sólo uno.
Si está siempre ocupado, será una pesada carga para un móvil con 4GB de memoria. ¿Cómo solucionarlo? Sólo se puede cambiar a configuración dinámica. En este momento, si no hay memoria suficiente, el sistema operativo inseguro solicita al sistema seguro que configure la memoria física no utilizada temporalmente en el área de memoria desprotegida y establezca un tiempo para restaurarla. Sin embargo, el mecanismo de asignación de memoria será más complicado y cambiar el kernel puede resultar peligroso.
Si ignoras esto y continúas bajando, te encontrarás con el segundo problema. TZC400 y sus versiones mejoradas solo admiten la gestión de bloques de memoria con una granularidad mínima de 2 MB como máximo. ¿Por qué no hacerlo más delgado? En pocas palabras, si se establece en 4 KB, de acuerdo con el tamaño de página del sistema, entonces 4 GB de memoria física requerirán 1 millón de entradas para administrarse. Si se utiliza la memoria en el chip, será mayor que la memoria caché de segundo nivel, lo cual no es realista.
El mapeo de memoria es como MMU. Después de la MMU de la CPU, el acceso a los datos debe pasar por la MMU y el retraso es obviamente mayor. Además, esta capa de MMU no puede usar el caché de segundo nivel para almacenar tablas de páginas, lo cual es extremadamente ineficiente. Si continúa manteniendo partículas de 2 MB, al asignar memoria, pronto se agotará porque el bloque es demasiado grande. Incluso si se adopta el método de la sección anterior, el problema no se puede resolver bien. Este es TZMP2V1.
En este caso surgió una tercera solución basada en máquinas virtuales. Pero esta solución básicamente subvierte la intención de diseño original de Trustzone. Echemos un vistazo a la siguiente imagen:
Aquí el TZC400 como protección de memoria se elimina por completo y se agrega la MMU del sistema. ¿Cómo proteger la memoria? Reubicación vía dirección física. Veamos primero el procesador. En la cadena de inicio, al saltar de EL3 a EL2, se define la memoria protegida EL2, es decir, la tabla de páginas de la máquina virtual se almacena en la memoria protegida y la página de seguridad de EL1 también se almacena en la memoria protegida.
De esta manera, cuando el procesador ingresa a EL1, incluso alterando el bit de seguridad de la tabla de páginas no seguras de EL1, eventualmente se asignará a una memoria segura a la que no puede acceder, desempeñando así un papel protector. . De manera similar, agregar MMU del sistema y dispositivos de virtualización al controlador en un mundo inseguro también puede controlar la seguridad. Este es TZMP2V2. Con la MMU del sistema, la tabla de páginas puede tener un tamaño de 4 KB y no hay necesidad de preocuparse de que la CPU pase por la MMU dos veces. En este momento, no hay necesidad de preocuparse por el monitoreo malicioso del caché, porque se verificarán todos los accesos a través de la MMU secundaria.
Pero al menos, simplemente agregar estas MMU del sistema al equipo aumentará una gran cantidad de área. Además, simplemente agregar una MMU no es suficiente. Se debe agregar caché de nivel tres o incluso nivel cuatro al sistema para que la MMU sea más eficiente; de lo contrario, el retraso será demasiado grande. Por supuesto, si el dispositivo no utiliza muchas tablas de páginas, la MMU se puede simplificar, como aumentar la granularidad mínima, reducir el rango de mapeo y usar directamente la memoria en el chip. Esto debe ser equilibrado por los diseñadores de sistemas.
Para que la GPU admita la coherencia bidireccional, es necesario considerar permitir que la transmisión de monitoreo pase a través de la MMU; de lo contrario, habrá problemas con la función.
Si utiliza TZMP2V2, la virtualización se convierte en un requisito real. Luego, encontraremos que las interrupciones y la virtualización de dispositivos de ARM están lejos de ser perfectas. A continuación, explicaré la virtualización desde una perspectiva de hardware.
Hablando de virtualización, primero debemos explicar el sistema MMU.
Como se muestra en la figura anterior, la MMU del sistema es en realidad muy simple: solo dos capas de traducción de direcciones. La primera capa va de la dirección virtual a la dirección real, y la segunda capa va de la dirección real a la dirección física. Tenga en cuenta que sin la traducción de capa 2, la dirección real es equivalente a la dirección física. El módulo se puede abrir en dos niveles o solo en uno, según disponibilidad.
La imagen de arriba muestra claramente el proceso de mapeo de una capa. Entre ellas, las solicitudes de direcciones virtuales enviadas por el dispositivo pasarán primero por el TLB, que almacena las entradas de la tabla de páginas a las que se accedió anteriormente. Si lo hay, regrese directamente; si no, vaya al segundo paso.
En el segundo paso, la MMU accederá a la tabla de páginas final en el primer nivel según el registro de dirección base multinivel preestablecido. Si la MMU está ubicada en la CPU, la dirección base y la entrada de la tabla a la que se accede cada vez durante el proceso de recorrido por la tabla se pueden almacenar en la caché, lo que mejora enormemente la eficiencia. Si solo hay una entrada TLB incorporada en el dispositivo y no hay caché detrás, aquellos que pierdan el TLB accederán a DDR y la eficiencia, naturalmente, disminuirá.
Por lo tanto, los dispositivos que acceden con frecuencia a la memoria, como la CPU y la GPU, tienen su propia MMU y caché de primera capa. Para dispositivos que no tienen una MMU interna y no cambian con frecuencia las tablas de páginas, como los controladores DMA, la primera capa de MMU se puede montar debajo. En este momento, el controlador es simple. Simplemente proporcione la dirección virtual que ve la aplicación directamente al registro DMA. La MMU buscará la tabla de páginas correspondiente según la dirección base, la traducirá y enviará la dirección real al bus. De lo contrario, el conductor debe encontrar la dirección real antes de escribir en la caja registradora.
Dijimos antes que en TZMP1 y TZMP2v1, la protección de la memoria la completa TZC400. En TZMP2v2, se canceló TZC400 y se basó en la asignación de direcciones virtualizadas de Capa 2.
El proceso de mapeo de dos capas es básicamente el mismo que el de una capa, por lo que no entraré en detalles, pero el problema de rendimiento se amplifica. Supongamos que en el primer nivel, la página final se encuentra a través de la dirección base de cuatro niveles, y en el segundo nivel, cada nivel de búsqueda de dirección base introducirá un nuevo acceso a la dirección base de cuatro niveles. Por lo tanto, para determinar la dirección física se requieren al menos 4x4 4=20 accesos. Sin la ayuda del almacenamiento en caché, la eficiencia será muy baja.
Otro enfoque posible es reducir el número de direcciones base. Por ejemplo, Linux solo usa tablas de páginas de tres niveles, pero aun así requiere búsquedas 3x3 3=12. En una CPU ARM con caché, la eficiencia de la máquina virtual puede alcanzar más del 80%. Cuando la MMU de segunda capa se utiliza para la virtualización de dispositivos, es necesario diseñarla cuidadosamente.
Con el sistema MMU, tenemos la base para la virtualización de chip completo. Entonces, después de equilibrar el rendimiento y el costo del sistema y adoptar un diseño de MMU adecuado, ¿se puede implementar la virtualización y lograr la seguridad mediante la virtualización? No es tan fácil. Hay otras cuestiones a considerar.
La virtualización nació del simulador, que consiste en simular otra plataforma en una plataforma. En el caso del mismo conjunto de instrucciones, no es necesario traducir cada instrucción y el hardware puede ejecutar las instrucciones directamente, resolviendo así el problema de eficiencia de las instrucciones. Por supuesto, para algunas instrucciones especiales y acceso a registros, todavía se necesita un hipervisor. Entonces la segunda pregunta es acceder a la memoria.
Explicamos anteriormente que para la CPU, el acceso eficiente a la memoria virtualizada significa que las instrucciones se traducen de manera eficiente a través de dos capas, en lugar de desencadenar una excepción en la máquina virtual EL2 cada vez, cambiar al hipervisor y obtener la versión final. dirección física. Esto se ha logrado cuando no hay ninguna excepción de página faltante, pero cuando hay una excepción de página faltante, el hipervisor aún necesita manejarla. Luego está la virtualización del acceso del dispositivo a la memoria, que también se puede realizar de manera eficiente a través de la MMU del sistema. Luego está la virtualización de interrupciones de procesadores y dispositivos.
Finalmente, es necesario administrar la virtualización del dispositivo y el dispositivo en sí debe admitir números de dispositivos virtuales y números de interrupción virtuales. Estén atentos para más.