Cómo la zona de confianza de Arm garantiza la seguridad del hardware
Trustzone se remonta a hace más de diez años, cuando se anunció ARMv7, pero lamentablemente no ha tenido ninguna aplicación práctica. No fue hasta los últimos años que los fabricantes comenzaron a utilizar esta solución en chips a gran escala. Actualmente se ven cuatro áreas de aplicación principales:
La primera son los chips para drones, DJI ya está a la vanguardia y el segundo lugar ni siquiera ha visto una sombra. Varias aplicaciones importantes de drones, incluida la transmisión de imágenes, el procesamiento de imágenes, el reconocimiento, el control de vuelo y el almacenamiento, tienen requisitos de seguridad. Con Trustzone, cada paso de los datos que fluyen en el 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 los piratas informáticos violan el sistema de software, los datos y el control seguirán estando seguros. Finalmente, si el país o la industria emite una política que exige la implementación de una zona de exclusión aérea, entonces el propietario del dron puede verse obligado a asumir el control incluso si modifica la memoria flash y el software. Estas funciones deben tenerse en cuenta durante la etapa de diseño del chip. La visión de DJI a este respecto es, de hecho, a más largo plazo que otras.
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 taquilla de Hollywood en sus teléfonos móviles, el dispositivo de reproducción debe pasar una certificación, y esta certificación se puede lograr utilizando Trustzone. El país ya está promoviendo activamente este asunto y se estima que se concretará en un tiempo. Por supuesto, esto es un arma de doble filo. Debe haber usuarios que no estén dispuestos a comprar dispositivos compatibles con DRM y en su lugar ver versiones pirateadas. El uso de Trustzone en sí no restringe la piratería, sino que simplemente proporciona un canal adicional para ver éxitos de taquilla de Hollywood.
El tercero es el pago. No existe ninguna dificultad técnica para utilizar Trustzone para el pago y los requisitos de rendimiento del chip no son altos. La dificultad radica en equilibrar a las distintas 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 implementar todas las funciones en sus propias plataformas mediante la cooperación con fabricantes de chips y hardware para teléfonos móviles. La mayoría de los pagos actuales todavía se basan en software y verificación remota de claves. Si alguien descifra el teléfono, aún puede leer la contraseña de la capa de pago. Lo que hace Trustzone es prevenir este tipo de situaciones en términos de hardware.
El cuarto es el Internet de las Cosas. Existen varios enfoques para la seguridad del Internet de las cosas. La detección de seguridad se puede colocar en el lado del servidor o en el chip del terminal. El final suele ser una MCU más sensores y módulos de interconexión, que tiene un área más pequeña. Si se implementa con hardware Trustzone, funciones como cifrado, descifrado y administración de claves requerirán 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 lo que Trustzone puede hacer desde una perspectiva técnica:
1. Evitar que se filtren datos clave después de que se viola el sistema operativo. Los datos clave se almacenan en un área de memoria específica. y esa área que solo pueden leer los sistemas operativos seguros.
2. Evite que los datos de registro, caché, memoria o memoria 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 fusibles de chip. Cada paso posterior del inicio requiere el nivel de privilegio más alto y la verificación de la clave para establecer una cadena de confianza para evitar que el software sea reemplazado o reemplazado. comprometido. leer maliciosamente.
4. Evite ataques de banda lateral, como medir datos de adivinación de señales de partículas de memoria, fallas de fabricación para detener el funcionamiento del módulo de inspección, reemplazar dispositivos periféricos, ingresar datos específicos para determinar las características de la señal electromagnética, abrir el chip para medir directamente señales internas Línea, etc.
La última estructura interna típica de un SoC ARM. En esta estructura, Trustzone lo que hace es proteger la seguridad de los datos dentro del chip y no permite el acceso no autorizado, incluso si el acceso proviene de la CPU. Parece un poco complicado al principio, pero podemos desmenuzarlo y analizarlo lentamente. Es más claro comenzar desde el punto de vista del hardware que del software. Quizás algún día, cuando obtenga la certificación, deberá responder la pregunta 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 no seguro.
En la imagen de arriba, la parte negra en el medio es el bus, el dispositivo maestro está encima del bus y los dispositivos esclavos están debajo (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 un dispositivo esclavo no tiene un mapeo de espacio de bloques, como I2C o PWM, entonces solo necesito agregar un pin adicional (llamado PROT) al acceder a él en el bus para indicarle si este acceso proviene de Safe World. Si el dispositivo esclavo pertenece completamente al mundo seguro protegido y no acepta accesos no seguros, entonces puede simplemente rechazarlo y devolver un error o datos sin sentido. Del mismo modo, si el dispositivo esclavo se encuentra en el mundo no seguro, se pueden devolver datos correctos tanto para el acceso seguro como para el no seguro. Además, el mundo en el que se encuentra el dispositivo esclavo 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 dispositivos de bloques, incluidos flash, sram, memoria, etc., algunos de sus bloques de direcciones deben estar en el mundo seguro y otros en el mundo no seguro. Para lograr esto, se debe insertar un módulo de verificación frente a ellos (como el TZC400 a la izquierda en la figura, encima del DDR) para determinar si se puede acceder a una dirección. Cuando la dirección se envía a este módulo de verificación, el módulo buscará la tabla junto con el pin PROT para ver si este acceso está permitido y luego tomará las medidas correspondientes. La tabla en sí, al igual que la configuración dinámica anterior, debe configurarse en el mundo seguro.
En este punto, el análisis del dispositivo esclavo se ha completado, ¿no parece muy simple? Todavía quedan algunos detalles. Después de hablar sobre el dispositivo principal, le prestaremos atención desde la perspectiva del sistema.
Para los dispositivos maestros generales, cuando no se considera el caché incorporado, en realidad es similar al dispositivo esclavo. También se divide en seguro y no seguro, y se puede configurar dinámicamente en la caja fuerte. mundo. Una vez completada la configuración, estos dispositivos maestros controlarán el pin y la dirección PROT para acceder al dispositivo esclavo de acuerdo con el mundo en el que se encuentran y obtendrán los retornos correspondientes. Sin embargo, los dispositivos principales generales aquí no incluyen controladores de interrupciones, MMU del sistema, módulos de depuración y procesadores. A continuación, realizaremos un análisis detallado de estos módulos de excepción.
El primero es el procesador.
En la situación anterior, después de conectarse al 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 maestro al dispositivo maestro (por supuesto, es un puerto esclavo dentro del procesador), y no se enviará a la memoria a través del bus, ni pasará por el módulo de verificación TZC400. En este momento, existe una vulnerabilidad al manipular un módulo en un mundo no seguro, como el dispositivo maestro naranja en la imagen de arriba, pretende leer una dirección de memoria protegida por el mundo seguro. Esta dirección existía originalmente en la memoria y estaba protegida por el TZC400. Sin embargo, debido a la función de escucha del bus, la solicitud de lectura puede enviarse a la memoria caché del procesador, evitando así la protección.
Para evitar esta situación, el procesador ha realizado diseños especiales en todas las tablas de páginas y cachés, y ha agregado un bit de bandera para marcar si esta línea de caché pertenece al mundo seguro. Si otro dispositivo maestro mundial no seguro monitorea la línea de caché mundial seguro, debido a diferentes bits de seguridad, el procesador pensará que se trata de dos direcciones diferentes, incluso si sus direcciones son consistentes, y devolverá un error de caché. De esta forma no se filtrarán datos.
Algunas personas pueden preguntar, este bit de bandera proviene de la tabla de páginas. Si cambia este bit en la tabla de páginas, ¿puede acceder a él? No precisamente. Debido a que la tabla de páginas del mundo seguro está ubicada en un área de memoria o caché protegida, no se puede acceder a ella incluso si el sistema operativo está descifrado.
Algunas personas dirán que al cambiar el bit de seguridad en la tabla de páginas del mundo no seguro y falsificar la dirección del mundo seguro, ¿no permitiría a la CPU simular una transmisión para acceder al mundo seguro y enviarlo al autobús? Una vez que el TZC400 o el caché de pares vean que la dirección y el pin PROT cumplen con los requisitos, deberían devolver datos confidenciales, ¿verdad? La idea es buena, pero cuando la CPU está en un mundo no seguro, ignora los bits de seguridad en la tabla de páginas, por lo que es imposible emitir PROT como una transferencia segura. Así que podemos estar tranquilos al respecto.
Lo anterior trata sobre otros dispositivos maestros que acceden al procesador. Si el procesador en sí está en un mundo no seguro, ¿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. Generalmente, el dispositivo maestro no distinguirá entre cachés seguras y no seguras. No importa si está conectado a la interfaz ACE-Lite, los datos almacenados en caché no se pueden leer de todos modos por diseño.
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, la GPU también se puede monitorear en busca de caché. Para simplificar el diseño, el procesador gráfico está configurado para estar siempre en un mundo no seguro. A la CPU no le importa la lectura, pero utiliza otro mecanismo para proteger los datos, que se presentará más adelante.
Las personas familiarizadas con el almacenamiento en caché del procesador pueden pensar en utilizar variables no seguras en las líneas de caché para acceder a datos protegidos. Es inútil. Los diseñadores de procesadores han pensado en esto hace mucho tiempo. O será una excepción de acceso no alineado (incluido el acceso exclusivo) o no le proporcionará los datos específicos para cada procesador.
Todavía hay una laguna que no se ha solucionado, es decir, el mantenimiento de la caché, el TLB y las operaciones de predicción de sucursales. Los puertos ACE incluyen operaciones DVM para mantenerlos. ¿Cómo garantizar la seguridad? Asimismo, existen bits seguros y no seguros en la dirección. Pero dicho esto, las operaciones de DVM no son más que invalidar ciertos 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.
Es posible que te sientas un poco mareado en este punto. Hay muchas lagunas que es necesario solucionar. Podemos revisar que lo que hay que recordar es que varias operaciones de caché están protegidas por indicadores de seguridad para evitar vulnerabilidades. En comparación con lo que los diseñadores de procesadores deben considerar, no vale la pena mencionar esta vulnerabilidad.
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 dispositivos esclavos individuales y también puede acceder e influir en los recursos internos del procesador. La protección en el lado del dispositivo esclavo es muy sencilla. Simplemente trate el módulo de depuración como un dispositivo maestro normal. Los registros, la caché y otros recursos dentro del procesador requieren que se definan niveles de seguridad para todos los recursos desde el comienzo del diseño del procesador. Los recursos protegidos están protegidos del acceso no autorizado mediante módulos de depuración. Sólo a través de la cadena de arranque segura el software del mundo seguro puede abrir el registro SDER, lo que permite que los emuladores externos afecten los recursos del mundo seguro protegido y el estado de ejecución del procesador, y accedan a los recursos protegidos.
¿Cómo se dividen los recursos dentro del procesador? Tome ARMv8 como ejemplo, como se muestra a continuación:
Creo que muchas personas han visto esta imagen. Los procesadores ARMv8 se dividen en cuatro niveles de privilegios. Por lo general, EL0 ejecuta programas en modo de usuario, el kernel EL1 y la máquina virtual EL2. EL0-1 se divide en mundos seguros y no seguros. EL3 solo tiene mundos seguros y EL2 no distingue entre ellos. El cambio entre los dos mundos debe pasar por EL3. Muchos de los recursos internos del procesador del que hablamos, incluidos registros, cachés, excepciones y MMU, están agrupados. Los grupos no son visibles o el nivel inferior no puede acceder al nivel superior para garantizar la seguridad. Aquellos que no están agrupados, como los registros de propósito general, requieren software para mantenerlos y evitar que el mundo no seguro vea los datos en el mundo seguro.
Existen varias posibilidades para provocar una conmutación segura: interrupciones e instrucciones SMC. Las interrupciones se dividen en las siguientes situaciones:
En el mundo no seguro, en EL1 o EL0, cuando se produce una interrupción no segura, el sistema no necesita cambiar al estado seguro. procesado como una interrupción general cambiando 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 llega una interrupción de seguridad, no es necesario cambiar al mundo seguro, simplemente cambie a EL1 como un procesamiento de interrupción normal.
En el mundo seguro, en EL1 o EL0, cuando llega una interrupción que no es de seguridad, el sistema primero debe cambiar a EL3; de lo contrario, no podrá cambiar al mundo seguro.
Al saltar al programa Secure Monitor de EL3 para procesar el cambio de contexto, el bit de máscara de interrupción IRQ/FIQ no funciona. Incluso si está activado, no se activará hasta que Secure Monitor lo esté. procesa y salta al correspondiente. Cuando el mundo seguro llega a EL1, se restaurará la máscara de interrupción original, lo que desencadenará la interrupción.
En este momento, el programa de interrupción en el mundo seguro maneja la interrupción, 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 y no seguras? Esto se define en el controlador de interrupciones. En la definición inicial, solo FIQ se puede usar como una interrupción segura, que se puede configurar más adelante, y solo se puede acceder al registro de configuración del mundo seguro correspondiente en el mundo seguro del procesador.
El comando SMC es similar al disparador de interrupción, excepto que el software puede activarlo y cambiar a Secure Monitor. Aquí, el software no seguro puede realizar solicitudes de activación y completar parámetros en registros generales, pero no puede controlar lo que hace el controlador en el mundo seguro y aún no puede ver los datos de la memoria protegida. Por tanto, la tarea de prevenir la fuga 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 es factible. Tome DRM como ejemplo, como se muestra a continuación:
Cuando se reproducen vídeos autorizados, las transmisiones de vídeo provienen de la red o de la memoria flash. No es necesario que estén en un mundo seguro porque los datos en sí están cifrados. Luego se descifra y se coloca en la memoria protegida, a la espera de ser decodificado. En la imagen de arriba, la protección con contraseña y el descifrado se completan a través del módulo de hardware de seguridad Crypto. Analizaremos esto más adelante y primero procesaremos la transmisión de video después de completar el descifrado. Hay dos opciones en este momento:
En la primera, es muy natural que todos los procesos se puedan completar en el mundo seguro. Luego, el procesador de gráficos, el procesador de video y el módulo de visualización deben funcionar en el mundo seguro. mundo Tener acceso a los datos de un mundo seguro le permite hacer el trabajo. Pero esto trae consigo un problema, que es el conductor. Sabemos que el controlador del procesador de gráficos es muy complicado y solo existen controladores de gráficos para Linux y Windows en teléfonos móviles que funcionan con OpenGL ES/DirectX.
Los sistemas operativos del mundo seguro (TEE, Trusted Execution Environment) son sistemas de seguridad completamente incompatibles y algunos ni siquiera admiten SMP. No hay posibilidad de trasplantar el controlador de gráficos y no tiene importancia. . En este caso, el procesador de gráficos solo se puede eliminar del proceso, dejando solo los controladores del módulo de visualización y video, que son relativamente simples y no requieren ecología, funcionan en un mundo seguro y la salida de la GPU se envía a la pantalla. módulo, que es Mix.
Esta es una solución factible y algunas empresas lo hacen. Pero a largo plazo, los procesadores gráficos siempre estarán involucrados en este proceso, no hablemos de nada más. Después de que la realidad virtual y la realidad aumentada se vuelvan populares, si aparece una pantalla virtual, se reproducen videos en ella y luego se colocan en una pantalla virtual. habitación, Luego deben interactuar entre sí. En este momento, el módulo de visualización debe enviar la capa de video de regreso a la GPU para su cálculo. Si la GPU no está en el mundo seguro, se producirán fugas.
Para resolver los problemas anteriores, existe una segunda solución llamada TZMP1 (Trustzone Media Protection 1), que introduce el concepto de proteger el mundo.
Protege al mundo de trabajar en un mundo no seguro para que pueda ser compatible con los controladores de gráficos. ¿Qué pasa con la seguridad? Requiere agregar un NSAID de cuatro pines, que es similar a la señal PROT en el mundo seguro, pero está dividido más finamente, de modo que cuando el módulo GPU/vídeo/pantalla quiera acceder a la memoria protegida, los permisos están predefinidos. 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. Y el permiso del controlador de pantalla es de solo lectura.
De esta manera, nuestro antiguo problema, el espionaje malicioso de caché, ha vuelto. En el nuevo sistema de bus A73 y G71 plus CCI500/550, se puede admitir la coherencia de hardware bidireccional. Esto significa que también se puede controlar la GPU. Ahora todo el mundo se encuentra en un mundo no seguro. ¿Cómo solucionarlo? Esto requiere la cooperación del autobús.
El bus CCI500/550 de ARM tiene un modo de protección. Cuando está activado, no solo admite los pines NSAID anteriores, sino que también reemplaza la transmisión de monitoreo con el comando de invalidación de la línea de caché durante el monitoreo, deja que el objetivo se invalide directamente. la línea de caché correspondiente. De esta manera, aún es necesario leer los datos de la memoria para garantizar la seguridad. Y este proceso es transparente para el software y no requiere ningún cambio.
Sin embargo, en este momento, la consistencia del hardware que se diseñó minuciosamente no tiene ningún efecto de aceleración y el rendimiento se ve afectado. Afortunadamente, cuando se ejecuta OpenGL ES, la GPU no emitirá una transferencia compartida y la CPU no monitoreará 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 ejecuta OpenCL y DRM al mismo tiempo, OpenCL no puede usar la coherencia de hardware bidireccional y debe reiniciar el sistema y cambiar al modo desprotegido.
Además, en el uso real, el TZC400 existente como módulo de protección de memoria tiene varios defectos fatales.
Primero, su configuración solo se puede completar al inicio y no se puede cambiar dinámicamente. Es decir, una vez que se entrega una cierta cantidad de memoria al mundo seguro, el operador ya no puede usarla. sistema del mundo no seguro, incluso si está inactivo. Al reproducir vídeo 4K, es necesario asignar cientos de megabytes de memoria, más de un bloque.
Si está ocupado todo el tiempo, esto será una carga pesada para un teléfono móvil con 4 GB de memoria. ¿Cómo solucionarlo? Sólo se puede cambiar a configuración dinámica. En este momento, si la memoria no es suficiente, el sistema operativo que no es de seguridad realiza una solicitud al sistema de seguridad, pidiéndole que configure la memoria física no utilizada temporalmente en el área de memoria desprotegida y la recupere en un momento determinado. Sin embargo, esto complica el mecanismo de asignación de memoria y es posible que sea necesario modificar el núcleo, lo cual es muy peligroso.
Si ignoras esto y continúas bajando, te encontrarás con el segundo problema. TZC400 y su versión mejorada 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? Es muy simple si se configura en 4 KB, que es consistente con el tamaño de la página del sistema, entonces se requerirán 1 millón de entradas para administrar 4 GB de memoria física. Si se convierte en memoria en el chip, será más grande que el caché de segundo nivel, lo cual no es realista.
La asignación de memoria es la misma que la MMU. Después de pasar por la MMU de la CPU, el acceso a los datos debe pasar por la MMU nuevamente y el retraso es obviamente grande. Además, la MMU de esta capa no puede usar los cachés de primer y segundo nivel para almacenar tablas de páginas, lo cual es extremadamente ineficiente. Si continúa manteniendo la granularidad de 2 MB, al asignar memoria, pronto se quedará sin ella porque los bloques son demasiado grandes. Incluso si se utiliza el método de la sección anterior, el problema no se puede resolver bien. Este es TZMP2V1.
En este caso aparece la tercera solución basada en máquinas virtuales. Sin embargo, esta solución básicamente anuló la intención de diseño original de Trustzone. Miremos la siguiente imagen:
Aquí, el TZC400 como protección de memoria se elimina por completo y se agrega la MMU del sistema. ¿Cómo hacer protección de la memoria? Confíe en la reasignación de direcciones físicas. Veamos primero el procesador. En la cadena de inicio, al saltar de EL3 a EL2, se define la memoria protegida, y 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 coloca en la memoria protegida. memoria.
De esta manera, cuando el procesador ingresa a EL1, incluso alterando los bits 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. role. De manera similar, agregar una MMU del sistema al controlador en el mundo no seguro permite virtualizar el dispositivo y también controlar la seguridad. Este es TZMP2V2. Con la MMU del sistema, la tabla de páginas se puede convertir en un tamaño de 4 KB y no hay necesidad de preocuparse de que la CPU atraviese la MMU dos veces. En este momento, no hay necesidad de preocuparse por espionaje malicioso en el caché, porque se verifican los bits de seguridad en todos los accesos que pasan a través de la MMU secundaria.
Sin embargo, sin mirar nada más, simplemente añadiendo estas MMU del sistema al dispositivo aumentará mucho el área. Además, agregar una MMU por sí sola no es suficiente. Se debe agregar el caché de tercer nivel o incluso de cuarto nivel del 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 requiere que los diseñadores de sistemas estén equilibrados.
Para que la GPU admita la coherencia bidireccional, también debe 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 se utiliza TZMP2V2, la virtualización se convierte en un requisito real. Entonces descubrirá que las interrupciones de ARM y la virtualización de dispositivos aún están lejos de ser perfectas. A continuación, explicaré la virtualización desde la perspectiva del 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: es una traducción de direcciones de capa 2. La primera capa, de dirección virtual a dirección real, la segunda capa, de dirección real a dirección física. Tenga en cuenta que sin la traducción de capa 2, las direcciones reales son equivalentes a las direcciones físicas. Este módulo se puede abrir en ambos niveles o solo en uno, según la situación.
La figura anterior muestra claramente el proceso de mapeo de un nivel. Entre ellos, la solicitud de dirección virtual emitida por el dispositivo pasará primero por el TLB, que almacena las entradas de la tabla de páginas a las que se accedió anteriormente. Si hay alguna, se devolverá directamente. De lo contrario, bajará al segundo paso de la tabla. caminar.
En el segundo paso, la MMU accederá a la tabla de páginas final nivel por nivel de acuerdo con 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 entradas TLB integradas en el dispositivo y no hay caché detrás de ellas, entonces todas las entradas TLB perdidas accederán a DDR y la eficiencia naturalmente disminuirá.
Por lo tanto, los dispositivos como CPU y GPU que acceden con frecuencia a la memoria tienen su propia MMU y caché de primera capa. Para dispositivos que no tienen una MMU interna y no cambian las tablas de páginas con mucha frecuencia, como los controladores DMA, puede colgar la primera capa de MMU a continuación. En este momento, el controlador es simple y la aplicación ve la dirección virtual. se entrega directamente al registro DMA. Eso es todo. La MMU encontrará la tabla de páginas correspondiente de acuerdo con la dirección base, la traducirá y enviará la dirección real al bus. De lo contrario, el conductor tiene que encontrar la dirección real y escribirla en la caja registradora.
Como decíamos antes, en TZMP1 y TZMP2v1 la protección de la memoria la completa el TZC400. Con TZMP2v2, se canceló TZC400 y se confió en la asignación de direcciones virtualizadas de Capa 2.
El proceso de mapeo de la segunda capa es básicamente el mismo que el del mapeo de la primera capa y no se describirá en detalle, pero el problema de rendimiento se amplificará. Supongamos que en la primera capa, la página final se encuentra a través de la dirección base del cuarto nivel, y en la segunda capa, la búsqueda de la dirección base en cada nivel introducirá un nuevo acceso a la dirección base del cuarto nivel. Por lo tanto, se necesitan al menos 4x4+4=20 accesos a la memoria para determinar la dirección física. Sin la ayuda del almacenamiento en caché, la eficiencia será muy baja.
Otros métodos factibles son reducir el número de niveles de direcciones base. Por ejemplo, Linux solo usa tablas de páginas de tres niveles, pero aun así, se requieren 3x3+3=12 búsquedas. En las CPU ARM que incluyen caché, la eficiencia de las máquinas virtuales puede alcanzar más del 80%. Cuando la MMU de segunda capa se utiliza en dispositivos para implementar la virtualización de dispositivos, es necesario diseñarla cuidadosamente.
Con el sistema MMU, tenemos la base para la virtualización de chip completo. Después de equilibrar el rendimiento y el costo del sistema y adoptar un diseño de MMU del sistema apropiado, ¿se puede implementar la virtualización y lograr la seguridad a través de la virtualización? No es tan fácil, hay otras cuestiones a considerar.
La virtualización nació del emulador, que consiste en simular otra plataforma en una plataforma. Cuando el conjunto de instrucciones es el mismo, no es necesario traducir cada instrucción y la instrucción puede ejecutarse directamente mediante el hardware, de modo que se resuelva la eficiencia de la instrucción. Por supuesto, el hipervisor aún debe manejar algunas instrucciones especiales y el acceso a registros. Entonces la segunda pregunta es el acceso a la memoria.
Como explicamos antes, para la CPU, el acceso eficiente a la memoria virtualizada significa que las instrucciones se pueden traducir de manera eficiente a través de dos capas, en lugar de desencadenar una excepción de la máquina virtual EL2 cada vez que se accede a la memoria. al hipervisor y obtener la dirección física final. La virtualización de ARM ya ha logrado esto cuando no falta ninguna excepción de página, pero cuando falta una excepción de página, el hipervisor aún necesita manejarla. Luego está la virtualización del acceso a la memoria del dispositivo. Con la MMU del sistema, también se puede hacer de manera eficiente. 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.