Hipervisor integrado - Enciclopedia

Un hipervisor integrado es un hipervisor que cumple con los requisitos de los sistemas embebidos.
Los requisitos de un hipervisor integrado son diferentes de los hipervisores orientados a aplicaciones de servidor y escritorio.
Un hipervisor integrado se diseña en el dispositivo embebido desde el principio, en lugar de cargarse después de la implementación del dispositivo.

Mientras que los entornos de escritorio y empresa utilizan hipervisores para consolidar hardware e隔离计算环境， en un sistema embebido, los diversos componentes suelen funcionar conjuntamente para proporcionar la funcionalidad del dispositivo. La virtualización móvil se superpone a la virtualización de sistemas embebidos y comparte algunos casos de uso.

Atributos típicos de la virtualización embebida incluyen eficiencia, seguridad, comunicación, aislamiento y capacidades en tiempo real.


Antecedentes
La virtualización de software ha sido un tema principal en el espacio empresarial desde fines de los años 1960, pero solo desde principios de los 2000 su uso ha aparecido en sistemas embebidos. El uso de la virtualización y su implementación en forma de hipervisor en sistemas embebidos es muy diferente de las aplicaciones empresariales. Una implementación efectiva de un hipervisor integrado debe manejar una serie de problemas específicos de dichas aplicaciones. Estos problemas incluyen la naturaleza altamente integrada de los sistemas embebidos, la necesidad de bloques funcionales aislados dentro del sistema para comunicarse rápidamente, la necesidad de un rendimiento en tiempo real/determinista, el entorno de destino con restricciones en recursos y la amplia gama de requisitos de seguridad y confiabilidad.


= Hipervisor =
Un hipervisor proporciona uno o más entornos de virtualización de software en los que otros programas, incluyendo sistemas operativos, pueden ejecutarse con la apariencia de tener acceso completo al hardware subyacente del sistema, donde en realidad tal acceso está bajo el completo control del hipervisor. Estos entornos virtuales se llaman máquinas virtuales (VM), y un hipervisor típicamente admite múltiples VM gestionadas simultáneamente.


Clasificación
Los hipervisores se clasifican generalmente como tipo 1 o tipo 2, dependiendo de si el hipervisor se ejecuta exclusivamente en modo supervisor o modo privilegiado (tipo 1) o si es hospedado por un sistema operativo como una aplicación regular (tipo 2).
Los hipervisores tipo 1 gestionan los recursos del sistema clave necesarios para mantener el control sobre las máquinas virtuales y facilitan una base de confianza mínima (TCB). Los hipervisores tipo 2 típicamente se ejecutan como una aplicación dentro de un sistema operativo de propósito general, aprovechando los servicios del sistema operativo para gestionar los recursos del sistema. Hoy en día, las extensiones del núcleo se cargan a menudo para aprovechar el hardware con soporte de virtualización.


= Hipervisor integrado =
Un hipervisor integrado es más comúnmente un hipervisor tipo 1 que admite los requisitos del desarrollo de sistemas embebidos. Ver referencias y para un debate más detallado.
Estos requisitos se resumen a continuación.

Un hipervisor pequeño y rápido con soporte para múltiples máquinas virtuales aisladas;
Soporte para encapsulación ligera pero segura de componentes de sub系统工程量级， que interactúan fuertemente;
Comunicación de alta banda ancha y baja latencia entre los componentes del sistema, sujeta a una política de seguridad global configurable;
Impacto mínimo en los recursos del sistema y soporte de garantías de latencia en tiempo real;
Capacidad para implementar una política de planificación entre las máquinas virtuales y proporcionar soporte para componentes del sistema en tiempo real.


Implementación
Un hipervisor integrado típicamente proporciona múltiples máquinas virtuales, cada una de las cuales emula una plataforma de hardware en la que se ejecuta el software virtualizado. La máquina virtual puede emular el hardware nativo subyacente, en cuyo caso el código embebido que se ejecuta en la máquina real se ejecutará en la máquina virtual y viceversa. Una emulación del hardware nativo no siempre es posible o deseable, y se puede definir en su lugar una plataforma virtual.
Cuando una máquina virtual proporciona una plataforma virtual, el software invitado debe portarse para ejecutarse en este entorno, sin embargo, ya que una plataforma virtual se puede definir sin depender del hardware nativo, el software invitado que admite una plataforma virtual puede ejecutarse sin cambios en varias plataformas de hardware diferentes admitidas por el hipervisor.
Los hipervisores integrados utilizan tanto la paravirtualización como las características de virtualización del CPU subyacente. La paravirtualización es necesaria en casos donde el hardware no ofrece asistencia y implica a menudo modificaciones extensas a la arquitectura de apoyo del núcleo invitado. La emulación del hardware a nivel de registro rara vez se ve en los hipervisores embebidos, ya que es muy compleja y lenta. La naturaleza personalizada de los sistemas embebidos significa que la necesidad de admitir software invitado binario sin cambios que requiera estas técnicas es rara.
El tamaño y la eficiencia de la implementación también son un problema para un hipervisor integrado, ya que los sistemas embebidos suelen estar mucho más limitados en recursos que las plataformas de escritorio y servidor. Es también deseable que el hipervisor mantenga, tanto como sea posible, la velocidad, la respuesta en tiempo real y la determinación, y la eficiencia energética de la plataforma de hardware subyacente.


= Diseño del hipervisor =
Las implementaciones para aplicaciones de sistemas embebidos se han basado comúnmente en diseños de microkernel y kernel de separación, con la virtualización integrada como una capacidad integral. Esto se introdujo con PikeOS en 2005. Ejemplos de estos enfoques han sido producidos por empresas como Open Kernel Labs (microkernel seguido de un kernel de separación) y LynuxWorks (kernel de separación). VirtualLogix parece tomar la posición de que un enfoque basado en un Monitor de Máquina Virtual (VMM) dedicado sería incluso más pequeño y eficiente. Este problema es el tema de algunos debates en curso. Sin embargo, el punto principal en disputa es el mismo en todos los lados del debate – la velocidad y el tamaño de la implementación (para un nivel dado de funcionalidad) son de gran importancia. Por ejemplo: " ... los hipervisores para uso embebido deben ser capaces de tiempo real, así como ahorrar recursos en el sistema".


= Requisitos de recursos =
Los sistemas embebidos suelen estar altamente limitados en recursos debido a las limitaciones de costo y técnico del hardware. Por lo tanto, es importante que un hipervisor integrado sea tan eficiente como sea posible. Los diseños basados en microkernel y kernel de separación permiten hipervisores pequeños y eficientes.
Por lo tanto, los hipervisores integrados suelen tener una huella de memoria de varios decenas a varios cientos de kilobytes, dependiendo de la eficiencia de la implementación y el nivel de funcionalidad proporcionado. Una implementación que requiera varios megabytes de memoria (o más) generalmente no es aceptable.
Con la pequeña TCB de un hipervisor tipo 1 integrado, el sistema puede hacerse altamente seguro y confiable. Las técnicas de ingeniería de software estándar, como las inspecciones de código y las pruebas sistemáticas, pueden utilizarse para reducir el número de errores en una base de código pequeña a una fracción diminuta de los defectos que deben esperarse para una combinación de hipervisor y sistema operativo invitado que puede tener 100,000-300,000 líneas en total.


= Comunicación de VM =
Una de las funciones más importantes requeridas en un hipervisor integrado es un mecanismo de mensajería segura, necesario para apoyar la comunicación en tiempo real entre procesos. En el entorno embebido, un sistema tendrá típicamente una serie de tareas estrechamente acopladas, algunas de las cuales pueden requerir aislamiento seguro entre ellas. En un entorno virtualizado, el hipervisor integrado apoyará y enforced dicho aislamiento entre múltiples VM. Por lo tanto, estas VM necesitarán acceso a un mecanismo que proporcione una comunicación entre tareas con baja latencia.
Un mecanismo de comunicación entre procesos (IPC) se puede utilizar para proporcionar estas funciones, así como invocar todos los servicios del sistema, y se puede implementar de una manera que asegure que se mantenga el nivel deseado de aislamiento de VM. Además, debido a su impacto significativo en el rendimiento del sistema, dicho mecanismo de IPC debe ser altamente optimizado para minimizar la latencia.


= Requisitos de hardware =
Un hipervisor integrado necesita estar completamente controlado de los recursos del sistema, incluyendo las accesos a la memoria, para asegurar que el software no pueda romper la VM. Por lo tanto, un hipervisor requiere que el CPU de destino proporcione soporte de gestión de memoria (generalmente utilizando un MMU). Muchos procesadores embebidos, incluyendo ARM, MIPS y PowerPC, han seguido a los proveedores de chips de escritorio y servidor en agregar soporte de hardware para virtualización. Sin embargo, aún hay una gran proporción de procesadores embebidos que no proporcionan tal soporte y se requiere un hipervisor que admita la paravirtualización.
Los procesadores ARM son notables en que la mayoría de sus diseños de procesadores de aplicación soportan una tecnología llamada ARM TrustZone, que proporciona esencialmente soporte de hardware para una VM privilegiada y una VM no privilegiada. Normalmente, un sistema operativo de entorno de ejecución confiable (TEE) se ejecuta en el mundo seguro y un kernel nativo se ejecuta en el mundo no seguro.


Casos de uso
Algunos de los casos de uso más comunes para un hipervisor integrado son:
1. Independencia del sistema operativo

Los diseñadores de sistemas embebidos pueden tener muchos controladores de hardware y servicios de sistema específicos de una plataforma de destino. Si se requiere soporte para más de un sistema operativo en la plataforma, ya sea simultáneamente o consecutivamente utilizando un diseño de hardware común, un hipervisor integrado puede simplificar enormemente la tarea. Estos controladores y servicios de sistema se pueden implementar una vez para el entorno virtualizado; estos servicios están disponibles para cualquier sistema operativo hospedado. Este nivel de abstracción también permite que el desarrollador de sistemas embebidos implemente o cambie un controlador o servicio en hardware o software en cualquier momento, sin que esto sea evidente para el sistema operativo hospedado.
2. Soporte para múltiples sistemas operativos en un solo procesador

Generalmente se utiliza para ejecutar un sistema operativo en tiempo real (RTOS) para funcionalidades de bajo nivel en tiempo real (como la pila de comunicación) mientras se ejecuta un sistema operativo de propósito general (GPOS) como Linux o Windows para soportar aplicaciones de usuario, como un navegador web o un calendario. El objetivo podría ser actualizar un diseño existente sin la complejidad adicional de un segundo procesador o simplemente minimizar el costo de materiales (BoM).
3. Seguridad del sistema
Un hipervisor integrado puede proporcionar encapsulación segura para cualquier subsystemo definido por el desarrollador, por lo que un subsystemo comprometido no puede interferir con otros subsystemos. Por ejemplo, un subsystemo de cifrado necesita estar fuertemente protegido contra ataques para evitar la filtración de la información que la cifrado debe proteger. Como el hipervisor integrado puede encapsular un subsystemo en una VM, puede luego imponer las políticas de seguridad requeridas para la comunicación a y desde ese subsystemo.
4. Reliability del sistema
La encapsulación de componentes de subsystemo en una VM garantiza que el fallo de cualquier subsystemo no pueda afectar a otros subsystemos. Esta encapsulación mantiene que los fallos no se propaguen de un subsystemo en una VM a un subsystemo en otra VM, mejorando la reliability. Esto también puede permitir que un subsystemo se cierre y se reinicie automáticamente al detectar un fallo. Esto puede ser particularmente importante para los controladores de dispositivo embebidos, ya que es donde se ve la mayor densidad de condiciones de fallo, y es por lo tanto la causa más común de fallo del sistema operativo y la inestabilidad del sistema. También permite la encapsulación de sistemas operativos que no necesariamente se construyeron al estándar de reliability exigido por el nuevo diseño de sistema.
5. Actualización dinámica de software del sistema
El software de subsystemo o aplicaciones se puede actualizar y probar para integridad de manera segura descargándolos a una VM segura antes de "entrar en producción" en un sistema en ejecución. Incluso si este proceso luego falla, el sistema puede revertir a su estado anterior al reiniciar el subsystemo/software original, sin interrumpir la operación del sistema.
6. Reutilización de código legado
La virtualización permite que el código embebido legado se utilice con el entorno de sistema operativo con el que se ha desarrollado y validado, liberando al desarrollador para utilizar un entorno de sistema operativo diferente en una VM separada para nuevos servicios y aplicaciones. El código embebido legado, escrito para una configuración de sistema específica, puede asumir el control exclusivo de todos los recursos del sistema, como memoria, E/S y procesador. Esta base de código se puede reutilizar sin cambios en configuraciones alternativas de E/S y memoria a través del uso de una VM para presentar un mapa de recursos y funcionalidad que sea consistente con la configuración de sistema original, desacoplando efectivamente el código legado de los detalles de un nuevo o modificado diseño de hardware.
Donde se tiene acceso al código fuente del sistema operativo, se utiliza comúnmente la paravirtualización para virtualizar los sistemas operativos en procesadores sin soporte de hardware de virtualización, y por lo tanto, las aplicaciones admitidas por el sistema operativo también pueden ejecutarse sin cambios y sin recompilación en nuevos diseños de plataformas de hardware.
Incluso sin acceso al código fuente, el código binario legado se puede ejecutar en sistemas que se ejecutan en procesadores con soporte de hardware de virtualización como las tecnologías AMD-V, Intel VT y los últimos procesadores ARM con soporte de virtualización. El código binario legado podría ejecutarse completamente sin cambios en una VM, con toda la gestión de mapeo de recursos manejada por el hipervisor integrado, siempre y cuando el hardware del sistema proporcione funcionalidad equivalente.
7. Protección de IP
La propiedad intelectual valiosa puede necesitar protección contra robo o mal uso cuando se envía una plataforma embebida para trabajo de desarrollo adicional por parte de, por ejemplo, un cliente OEM. Un hipervisor integrado hace posible restringir el acceso de otros componentes del sistema a una parte específica del sistema que contiene IP que necesita protegerse.
8. Segregación de licencias de software
El IP de software que opera bajo un esquema de licencia puede separarse de otro software IP que opera bajo un esquema de licencia diferente. Por ejemplo, el hipervisor integrado puede proporcionar un entorno de ejecución aislado para software propietario que comparte el procesador con software de código abierto sometido a la GPL.
9. Migración de aplicaciones de sistemas mono-núcleo a sistemas multi-núcleo
A medida que los nuevos procesadores utilizan arquitecturas de múltiples núcleos para aumentar el rendimiento, el hipervisor integrado puede gestionar la arquitectura subyacente y presentar un entorno de procesador mono-núcleo a las aplicaciones y sistemas operativos legados, mientras utiliza de manera eficiente el diseño de sistema multiprocesador nuevo. De esta manera, un cambio en el entorno de hardware no requiere un cambio en el software existente.


Productos comerciales
Crucible por Star Lab Corp.
Cross-OS Hypervisor - Permite que las aplicaciones se ejecuten nativamente en una plataforma de un solo sistema operativo desde MapuSoft Technologies, Inc.
OKL4 Hypervisor - Soporta dispositivos inteligentes conectados basados en ARM (embebidos, móviles). Utilizado en aplicaciones sensibles a la defensa y la seguridad. Soportado comercialmente por Cog Systems.
INTEGRITY Multivisor - Un servicio de virtualización de microkernel tipo II del sistema operativo INTEGRITY certificado en seguridad y seguridad.


Referencias