Seguridad

Para evitar la ejecución de cargas útiles arbitrarias dentro de una pVM, el marco de virtualización de Android (AVF) usa un enfoque de seguridad en capas en el que cada capa agrega refuerzos adicionales. A continuación, se incluye una lista de las capas de seguridad de AVF:

  • Android garantiza que solo las apps con permisos de pVM puedan crear o inspeccionar pVMs.

  • Cargador de arranque: El cargador de arranque garantiza que solo se permitan arrancar las imágenes de pVM firmadas por Google o los proveedores de dispositivos, y respeta el procedimiento de Inicio verificado de Android. Esta arquitectura implica que las apps que ejecutan pVM no pueden incluir sus propios kernels.

  • La pVM proporciona defensa en profundidad, como con SELinux, para las cargas útiles que se ejecutan en la pVM. La defensa en profundidad no permite asignar datos como ejecutables (neverallow execmem) y garantiza que W^X se mantenga para todos los tipos de archivos.

Modelo de seguridad

La confidencialidad, la integridad y la disponibilidad (tríada CID) conforman un modelo diseñado para guiar las políticas de seguridad de la información:

  • La confidencialidad es un conjunto de reglas que limita el acceso a la información.
  • La integridad es la garantía de que la información es confiable y precisa.
  • La disponibilidad es una garantía de acceso confiable a la información por parte de las entidades autorizadas.

Confidencialidad e integridad

La confidencialidad se deriva de las propiedades de aislamiento de la memoria que aplica el hipervisor de pKVM. pKVM hace un seguimiento de la propiedad de la memoria de las páginas de memoria física individuales y de las solicitudes de los propietarios para que se compartan las páginas. pKVM garantiza que solo las pVM con derechos (host y huéspedes) tengan la página determinada asignada en sus tablas de páginas de nivel 2 controladas por el hipervisor. Esta arquitectura sostiene que el contenido de la memoria que posee una pVM sigue siendo privado, a menos que el propietario lo comparta explícitamente con otra pVM.

Las restricciones para mantener la confidencialidad también se extienden a cualquier entidad del sistema que realice accesos a la memoria en nombre de las PVMs, es decir, los dispositivos compatibles con DMA y los servicios que se ejecutan en capas más privilegiadas. Los proveedores de sistemas en chip (SoC) deben satisfacer un nuevo conjunto de requisitos antes de poder admitir pKVM. De lo contrario, no se puede garantizar la confidencialidad.

La integridad se aplica a los datos en la memoria y al cómputo. Las pVM no pueden hacer lo siguiente:

  • Modificar la memoria de otra persona sin su consentimiento
  • Influyen en el estado de la CPU del otro.

El hipervisor aplica estos requisitos. Sin embargo, los problemas relacionados con la integridad de los datos también surgen con el almacenamiento de datos virtuales cuando se deben aplicar otras soluciones, como dm-verity o AuthFS.

Estos principios no son diferentes del aislamiento de procesos que ofrece Linux, en el que el acceso a las páginas de memoria se controla con tablas de páginas de etapa 1 y el kernel cambia de contexto entre procesos. Sin embargo, la parte EL2 de pKVM, que aplica estas propiedades, tiene una superficie de ataque tres órdenes de magnitud menor en comparación con todo el kernel de Linux (aproximadamente 10,000 frente a 20 millones de líneas de código) y, por lo tanto, ofrece una mayor garantía para los casos de uso que son demasiado sensibles como para depender del aislamiento de procesos.

Dado su tamaño, pKVM se presta a la verificación formal. Apoyamos activamente la investigación académica, cuyo objetivo es demostrar formalmente estas propiedades en el binario de pKVM real.

El resto de esta página aborda las garantías de confidencialidad e integridad que proporciona cada componente alrededor de una PKVM.

Hipervisor

La pKVM es un hipervisor basado en KVM que aísla las pVM y Android en entornos de ejecución que no confían entre sí. Estas propiedades se mantienen en caso de que se produzca una vulneración en cualquier PVN, incluido el host. Los hipervisores alternativos que cumplen con AVF deben proporcionar propiedades similares.

  • Una PVm no puede acceder a una página que pertenece a otra entidad, como una PVm o un hipervisor, a menos que el propietario de la página la comparta de forma explícita. Esta regla incluye la pVM del host y se aplica a los accesos de CPU y DMA.

  • Antes de que se devuelva al host una página que usa una pVM, por ejemplo, cuando se destruye la pVM, se borra.

  • La memoria de todas las pVM y el firmware de la pVM de un inicio del dispositivo se borran antes de que se ejecute el bootloader del SO en el inicio posterior del dispositivo.

  • Cuando se conecta un depurador de hardware, como SJTAG, una pVM no puede acceder a sus claves emitidas anteriormente.

  • El firmware de la pVM no se inicia si no puede verificar la imagen inicial.

  • El firmware de la pVM no se inicia si se ve comprometida la integridad de instance.img.

  • Solo esa instancia en particular puede derivar la cadena de certificados de DICE y los identificadores de dispositivo compuestos (CDI) que se proporcionan a una instancia de pVM.

SO invitado

Microdroid es un ejemplo de un SO que se ejecuta dentro de una pVM. Microdroid consta de un cargador de arranque basado en U-boot, GKI, un subconjunto del espacio del usuario de Android y un lanzador de cargas útiles. Estas propiedades se mantienen en caso de que se produzca una vulneración en cualquier pVM, incluido el host. Los SO alternativos que se ejecutan en una PVm deben proporcionar propiedades similares.

  • Microdroid no se iniciará si no se pueden verificar boot.img, super.img, vbmeta.img o vbmeta\_system.img.

  • Microdroid no se iniciará si falla la verificación del APK.

  • La misma instancia de Microdroid no se iniciará, incluso si se actualizó el APK.

  • Microdroid no se iniciará si alguno de los APEX falla en la verificación.

  • Microdroid no se iniciará (o se iniciará con un estado inicial limpio) si se modifica instance.img fuera de la pVM invitada.

  • Microdroid proporciona la certificación de la cadena de inicio.

  • Cualquier modificación (sin firmar) en las imágenes de disco compartidas con la pVM invitada provoca un error de E/S en el lado de la pVM.

  • La cadena de certificados de DICE y los CDI proporcionados a una instancia de pVM solo pueden derivarse de esa instancia en particular.

  • Las escrituras en un volumen de almacenamiento encriptado son confidenciales, pero no hay protección de reversión a la granularidad de un bloque de encriptación. Además, cualquier otra manipulación externa arbitraria de un bloque de datos hace que ese bloque aparezca como basura para Microdroid, en lugar de detectarse explícitamente como un error de E/S.

Android

Estas son propiedades que Android mantiene como host, pero que no se cumplen en caso de que se vea comprometido el host:

  • Una pVM invitada no puede interactuar directamente con otras pVM invitadas (por ejemplo, para establecer una conexión vsock).

  • Solo el VirtualizationService en la pVM del host puede crear un canal de comunicación a una pVM.

  • Solo las apps firmadas con la clave de la plataforma pueden solicitar permiso para crear, poseer o interactuar con pVMs.

  • El identificador, llamado identificador de contexto (CID), que se usa para configurar las conexiones de vsock entre la pVM del host y la pVM no se reutiliza cuando se ejecuta la pVM del host. Por ejemplo, no puedes reemplazar una pVM en ejecución por otra.

Disponibilidad

En el contexto de las pVM, la disponibilidad hace referencia a la asignación de recursos suficientes por parte del host a los invitados para que estos puedan realizar las tareas para las que están diseñados.

Las responsabilidades del host incluyen la programación de las CPU virtuales de la pVM. A diferencia de los hipervisores convencionales de tipo 1 (como Xen), KVM toma la decisión de diseño explícita de delegar la programación de la carga de trabajo en el kernel del host. Dado el tamaño y la complejidad de los programadores actuales, esta decisión de diseño reduce significativamente el tamaño de la base de procesamiento confiable (TCB) y permite que el host tome decisiones de programación más fundamentadas para optimizar el rendimiento. Sin embargo, un host malicioso puede optar por no programar nunca a un invitado.

Del mismo modo, pKVM también delega el control de interrupciones físicas al kernel del host para reducir la complejidad del hipervisor y dejar que el host se encargue de la programación. Se hace todo lo posible para garantizar que el reenvío de interrupciones del invitado solo genere una denegación de servicio (demasiadas, muy pocas o interrupciones mal dirigidas).

Por último, el proceso del supervisor de máquina virtual (VMM) del host es responsable de asignar memoria y proporcionar dispositivos virtuales, como una tarjeta de red. Un VMM malicioso puede retener recursos del invitado.

Si bien pKVM no proporciona disponibilidad a los invitados, el diseño protege la disponibilidad del host de los invitados maliciosos, ya que el host siempre puede anticiparse a un invitado o finalizarlo, y recuperar sus recursos.

Inicio seguro

Los datos están vinculados a instancias de una pVM, y el arranque seguro garantiza que se pueda controlar el acceso a los datos de una instancia. El primer inicio de una instancia la aprovisiona generando de forma aleatoria una sal secreta para la pVM y extrayendo detalles, como claves públicas de verificación y hashes, de las imágenes cargadas. Esta información se usa para verificar los inicios posteriores de la instancia de pVM y garantizar que los secretos de la instancia solo se liberen en las imágenes que pasen la verificación. Este proceso ocurre en cada etapa de carga dentro de la pVM: firmware de la pVM, ABL de la pVM, Microdroid, etcétera.

DICE proporciona a cada etapa de carga un par de claves de certificación, cuya parte pública se certifica en el certificado de DICE para esa etapa. Este par de claves puede cambiar entre los inicios, por lo que también se deriva un secreto de sellado que es estable para la instancia de VM en los reinicios y, como tal, es adecuado para proteger el estado persistente. El secreto de sellado es muy valioso para la VM, por lo que no se debe usar directamente. En cambio, las claves de sellado deben derivarse del secreto de sellado, y este debe destruirse lo antes posible.

Cada etapa entrega un objeto CBOR codificado de forma determinística a la siguiente etapa. Este objeto contiene secretos y la cadena de certificados de DICE, que incluye información de estado acumulada, como si la última etapa se cargó de forma segura.

Dispositivos desbloqueados

Cuando se desbloquea un dispositivo con fastboot oem unlock, se borran los datos del usuario. Este proceso protege los datos del usuario del acceso no autorizado. Los datos privados de una pVM también se invalidan cuando se desbloquea un dispositivo.

Una vez desbloqueado, el propietario del dispositivo puede volver a escribir en las particiones que suelen estar protegidas por el inicio verificado, incluidas las particiones que contienen pvmfw y la implementación de pKVM. Por lo tanto, no se confía en que un dispositivo desbloqueado mantenga el modelo de seguridad de una pVM.

Las partes remotas pueden observar este estado potencialmente inseguro si inspeccionan el estado de inicio verificado del dispositivo en un certificado de certificación de claves.