La arquitectura de los sistemas de firmware basados ​​en ARMv8

Desde su lanzamiento en 2011, la arquitectura del procesador ARMv8 se ha generalizado bastante en el mercado de dispositivos móviles. Según las previsiones del CEO de ARM Limited, los procesadores de esta generación adquirirán una cuota de mercado mundial de hasta el 25% para 2020. Es bastante natural que el soporte de software se haya establecido y se haya desarrollado aún más heredando las características y características generales. principios de la infraestructura formada históricamente.

Se observa una situación fundamentalmente diferente en el segmento de mercado de servidores. Los servidores basados ​​en X86 han estado dominando esta área durante mucho tiempo, mientras que ARMv8 está encontrando su camino (y solo en segmentos comerciales específicos). La novedad de este mercado para ARM y el hecho de que la mayoría de los estándares y especificaciones aceptados (principalmente ACPI y UEFI) no se han adaptado para sistemas ARM hasta hace poco ha dejado su huella en el desarrollo de la infraestructura de software.

Este artículo se centra en una descripción general del sistema de servidor basado en ARM y las características del procesador y no pretende ser una descripción exhaustiva. Los autores también quisieran llamar la atención del lector sobre el hecho de que los datos proporcionados pueden volverse obsoletos rápidamente; pronto, nuevos procesadores vendrán con nuevas soluciones técnicas que pueden requerir un enfoque diferente para la implementación de la infraestructura de software.

Primero, debemos señalar que las implementaciones actuales de firmware para sistemas de servidor ARMv8 constan de varios componentes relativamente independientes. Esto ofrece una serie de ventajas, como la posibilidad de utilizar los mismos componentes tanto en el firmware del servidor como en el de los sistemas integrados, así como la relativa independencia de los cambios introducidos.

Entonces, ¿qué módulos y componentes se utilizan en estos sistemas y cuáles son sus funciones? El gráfico general para la carga y la interacción de los módulos se muestra en la Fig. 1. El proceso comienza con la inicialización de los subsistemas, como la RAM y las interfaces entre procesadores. En las implementaciones actuales, esto es ejecutado por un módulo separado en el modo EL3S inmediatamente después de encender la CPU principal. Por tanto, este componente del sistema tiene los máximos privilegios posibles. Por lo general, no interactúa directamente con el sistema operativo.

Fig 1. La carga e interacción de módulos. (Fuente:Auriga)

Posteriormente, el control se transfiere al siguiente componente, generalmente el módulo ARM Trusted Firmware (ATF), que se ejecuta en el mismo modo. El control ATF se puede transferir directamente desde el cargador de nivel 0 descrito en el párrafo anterior o indirectamente a través de un módulo UEFI especial que implementa el PEI (Inicialización PreEFI). ATF consta de varios módulos que reciben el control en diferentes momentos.

El módulo de inicio BL1 realiza la inicialización de las partes de la plataforma asignadas al modo de procesador seguro. Dado que los sistemas basados ​​en ARMv8 utilizan la separación de hardware para recursos confiables y no confiables, incluida la RAM, el módulo BL1 prepara un entorno donde se puede ejecutar el código confiable. En particular, este tipo de inicialización incluye la configuración de controladores de memoria / caché (las zonas confiables y no confiables se marcan mediante la programación de los registros en estos dispositivos) y el marcado de dispositivos en chip (controladores de memoria independientes de la energía). Este marcado también introduce el filtrado de transacciones DMA en función de los tipos de dispositivos (confiables / no confiables). Dado todo esto, la escritura / lectura de memoria solo es posible hacia / desde áreas cuyas configuraciones de seguridad coinciden con las del dispositivo. Las implementaciones de un entorno confiable pueden ser bastante complejas; por ejemplo, pueden incluir un sistema operativo independiente. Sin embargo, la descripción de tales implementaciones está más allá del alcance de este artículo.

El módulo BL1 configura la tabla de traducción de direcciones MMU, así como la tabla del controlador de excepciones, donde el elemento más importante es el controlador de excepciones para la instrucción Secure Monitor Call (SMC). En este punto, el controlador es mínimo y en realidad solo puede transferir el control a las imágenes cargadas en la RAM. Mientras se ejecuta, el módulo BL1 carga la siguiente etapa (BL2) en la RAM y le transfiere el control. El módulo BL2 funciona en el modo EL1S con privilegios reducidos. Por lo tanto, la transferencia de control a este módulo se realiza mediante la instrucción "ERET".

El propósito del módulo BL2 es cargar los módulos de firmware restantes (partes BL3) y transferirles el control. El nivel de privilegio reducido se utiliza para evitar posibles daños en el código y los datos EL3S que ya se encuentran en la memoria. El código de estas partes se ejecuta llamando al código EL3S ubicado en la etapa BL1 usando la instrucción SMC.

La tercera etapa de carga e inicialización del ATF puede constar de tres etapas, pero la segunda etapa generalmente se omite. Así, de hecho, solo quedan dos. El módulo BL3-1 es parte del código confiable al que puede acceder el software de propósito general (SO, etc.) en tiempo de ejecución. La parte clave de este módulo es el controlador de excepciones llamado por la instrucción "SMC". Hay funciones en el propio módulo para implementar llamadas SMC estándar:el código que implementa la interfaz PSCI estándar (diseñado para controlar toda la plataforma, como habilitar / deshabilitar núcleos de procesador, administración de energía en toda la plataforma y reinicio) y también maneja el proveedor -llamadas específicas (proporcionando información sobre la plataforma, gestión de dispositivos integrados, etc.).

Como se mencionó anteriormente, la presencia del módulo BL3-2 es opcional; su código (en el caso de un módulo) se ejecuta en el modo EL1S. Por lo general, sirve como un servicio / monitor especializado para los eventos que ocurren durante el funcionamiento de la plataforma (interrupciones de ciertos temporizadores, dispositivos, etc.)

De hecho, BL3-3 no es un módulo ATF, sino una imagen de firmware ejecutada en modo no seguro. Por lo general, toma el control en el modo EL2 y representa una imagen de un cargador de arranque similar al ampliamente conocido U-Boot o el de un entorno UEFI, que es estándar para los sistemas de servidor.

El gráfico general de la inicialización del módulo ATF se muestra en la Fig. 2.

Fig. 2. Inicialización del módulo ATF. (Fuente:Auriga)