Seguridad

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

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

  • Bootloader: El bootloader garantiza que solo se permitan iniciar 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 pVMs no pueden agrupar sus propios kernels.

  • 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 CIA) 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 entidades autorizadas.

Confidencialidad e integridad

La confidencialidad se deriva de las propiedades de aislamiento de memoria que aplica el hipervisor de la pKVM. La pKVM realiza un seguimiento de la propiedad de la memoria de las páginas de memoria física individuales y de cualquier solicitud de los propietarios para que se compartan las páginas. La pKVM garantiza que solo las pVMs con derechos (host y huéspedes) tengan la página determinada asignada en sus tablas de páginas de etapa 2 que controla el hipervisor. Esta arquitectura mantiene que el contenido de la memoria que posee una pVM permanece 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 en el 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 cumplir con un nuevo conjunto de requisitos antes de que puedan admitir la pKVM. De lo contrario, no se puede proporcionar confidencialidad.

La integridad se aplica a los datos en la memoria y al procesamiento. Las pVMs no pueden hacer lo siguiente:

  • Modificar la memoria de cada una sin consentimiento
  • Influir en el estado de la CPU de cada una

El hipervisor aplica estos requisitos. Sin embargo, también surgen problemas relacionados con la integridad de los datos 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 la pKVM, que aplica estas propiedades, tiene tres órdenes de magnitud menos de superficie de ataque en comparación con todo el kernel de Linux (aproximadamente 10 mil 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 para depender del aislamiento de procesos.

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

En el resto de esta página, se abordan 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 pVMs y Android en entornos de ejecución que no son confiables mutuamente. Estas propiedades se mantienen en caso de que se produzca una vulneración en cualquier pVM, incluido el host. Los hipervisores alternativos que cumplen con el 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 explícitamente. Esta regla incluye la pVM host y se aplica a los accesos de CPU y DMA.

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

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

  • Cuando se conecta un depurador de hardware, como SJTAG, una pVM no puede acceder a sus claves acuñadas 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 vulnera la integridad de instance.img.

  • La cadena de certificados DICE y los identificadores de dispositivos compuestos (CDI) que se proporcionan a una instancia de pVM solo pueden derivarse de esa instancia en particular.

SO invitado

Microdroid es un ejemplo de un SO que se ejecuta dentro de una pVM. Microdroid consta de un bootloader basado en U-boot, GKI, un subconjunto del espacio del usuario de Android y un iniciador de carga útil. 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 certificación a la cadena de inicio.

  • Cualquier modificación (sin firmar) de 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 DICE y los CDI que se proporcionan 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 en la granularidad de un bloque de encriptación. Además, otras manipulaciones externas arbitrarias de un bloque de datos hacen 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 mantiene Android como host, pero no son válidas en caso de que se produzca una vulneración del host:

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

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

  • Solo las apps que están 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 vsock conexiones entre el host y la pVM no se reutiliza cuando se ejecuta la pVM host. Por ejemplo, no puedes reemplazar una pVM en ejecución por otra.

Disponibilidad

En el contexto de las pVMs, la disponibilidad se refiere al host que asigna recursos suficientes a los invitados para que puedan realizar las tareas para las que están diseñados.

Las responsabilidades del host incluyen la programación de las CPUs virtuales de la pVM. KVM, a diferencia de los hipervisores convencionales de tipo 1 (como Xen), toma la decisión de diseño explícita de delegar la programación de la carga de trabajo al 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 informadas para optimizar el rendimiento. Sin embargo, un host malicioso puede optar por no programar nunca un invitado.

Del mismo modo, la pKVM también delega el manejo de interrupciones físicas al kernel del host para reducir la complejidad del hipervisor y dejar el host a cargo de la programación. Se hace un esfuerzo para garantizar que el reenvío de interrupciones de invitados solo genere una denegación de servicio (demasiadas, muy pocas o interrupciones mal enrutadas).

Por último, el proceso del monitor de máquinas virtuales (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.

Aunque la 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 interrumpir o finalizar un invitado y recuperar sus recursos.

Inicio seguro

Los datos están vinculados a instancias de una pVM, y el inicio seguro garantiza que se pueda controlar el acceso a los datos de una instancia. El primer inicio de una instancia la aprovisiona generando aleatoriamente 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 publiquen en las imágenes que pasen la verificación. Este proceso se realiza para 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 DICE para esa etapa. Este par de claves puede cambiar entre inicios, por lo que también se deriva un secreto de sellado que es estable para la instancia de VM en todos los reinicios y, por lo tanto, 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 su lugar, 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 determinista a la siguiente etapa. Este objeto contiene secretos y la cadena de certificados DICE, que contiene 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 que son privados para una pVM también se invalidan cuando se desbloquea un dispositivo.

Una vez desbloqueado, el propietario del dispositivo puede volver a transmitir las particiones que suelen estar protegidas por el inicio verificado, incluidas las particiones que contienen pvmfw y la implementación de la 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 clave.