Se usó la API de Cloud Translation para traducir esta página.

Seguridad

Para evitar la ejecución de cargas útiles arbitrarias dentro de una pVM, Android Virtualization Framework (AVF) utiliza un enfoque de seguridad en capas en el que cada capa agrega refuerzos adicionales. La siguiente es una lista de las capas de seguridad de AVF:

Android: Android garantiza que solo las aplicaciones con permisos de pVM puedan crear o inspeccionar pVM.
Cargador de arranque: el cargador de arranque garantiza que solo las imágenes pVM firmadas por Google o los proveedores de dispositivos puedan arrancar y respeta el procedimiento de arranque verificado de Android . Esta arquitectura implica que las aplicaciones que ejecutan pVM no pueden empaquetar sus propios núcleos.
pVM: el pVM proporciona defensa en profundidad, como con SELinux , para las cargas útiles que se ejecutan en el pVM. La defensa en profundidad no permite que los datos de mapeo sean ejecutables ( neverallow execmem ) y garantiza que W^X se mantenga para todos los tipos de archivos.

modelo de seguridad

Confidencialidad, integridad y disponibilidad, también conocida como la tríada CIA, es 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 seguridad 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.

Tenga en cuenta que pKVM se diseñó para mantener la confidencialidad y la integridad, pero no la disponibilidad, de los invitados. Estos principios influyen en las decisiones de diseño que abarcan todos los aspectos de la arquitectura, desde el hipervisor hasta los componentes del espacio del usuario.

Confidencialidad e integridad

La confidencialidad se deriva de las propiedades de aislamiento de la memoria impuestas por el hipervisor pKVM. pKVM rastrea la propiedad de la memoria de páginas de memoria física individuales y cualquier solicitud de los propietarios de páginas para compartir. pKVM garantiza que solo los pVM autorizados (host e invitados) tengan asignada la página dada en sus tablas de página de etapa 2 que están controladas por el hipervisor. Esta arquitectura mantiene que el contenido de la memoria propiedad de 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 del sistema que realice accesos a la memoria en nombre de las pVM, es decir, dispositivos y servicios con capacidad DMA que se ejecutan en capas más privilegiadas . Los proveedores de SoC deben cumplir con un nuevo conjunto de requisitos antes de que puedan admitir pKVM; de lo contrario, no se puede proporcionar confidencialidad.

La integridad se aplica tanto a los datos en la memoria como a la computación:

Los pVM no pueden modificar la memoria de los demás sin consentimiento.
Los pVM no pueden influir en el estado de la CPU de los demás.

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

Estos principios no son diferentes del aislamiento de procesos que ofrece Linux, donde el acceso a las páginas de memoria se controla con las tablas de páginas de la etapa 1 y el contexto del núcleo cambia entre procesos. Sin embargo, la porción EL2 de pKVM, que hace cumplir estas propiedades, tiene aproximadamente la mitad de la superficie de ataque 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 seguridad para casos de uso que son demasiado sensibles para confiar. en el aislamiento del proceso.

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

El resto de este documento cubre las garantías de confidencialidad e integridad que proporciona cada componente alrededor de un pKVM.

hipervisor

pKVM es un hipervisor basado en KVM que aísla pVM y Android en entornos de ejecución en los que no se confía mutuamente. Estas propiedades se mantienen en caso de compromiso dentro de cualquier pVM, incluido el host. Los hipervisores alternativos que cumplen con AVF deben proporcionar propiedades similares.

Un pVM no puede acceder a una página que pertenece a otra entidad, como un pVM o un hipervisor, a menos que el propietario de la página lo comparta explícitamente. Esta regla incluye el host pVM y se aplica a los accesos de CPU y DMA.
Antes de que una página utilizada por un pVM se devuelva al host, como cuando se destruye el pVM, se borra.
La memoria de todas las pVM y el firmware de la pVM del arranque de un dispositivo se borra antes de que se ejecute el gestor de arranque del sistema operativo en el arranque del dispositivo posterior.
Cuando se adjunta un depurador de hardware, como SJTAG, un pVM no puede acceder a sus claves acuñadas previamente.
El firmware de pVM no arranca si no puede verificar la imagen inicial.
El firmware de pVM no arranca si la integridad de la instance.img está comprometida.
La cadena de certificados de arranque (BCC) y los identificadores de dispositivos compuestos (CDI) proporcionados a una instancia de pVM solo pueden derivarse de esa instancia en particular.

SO invitado

Microdroid es un ejemplo de un sistema operativo que se ejecuta dentro de una pVM. Microdroid consta de un gestor de arranque basado en U-boot, GKI, un subconjunto del espacio de usuario de Android y un iniciador de carga útil. Estas propiedades se mantienen en caso de compromiso dentro de cualquier pVM, incluido el host. Los sistemas operativos alternativos que se ejecutan en una pVM deberían 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 de APK.
La misma instancia de Microdroid no se iniciará incluso si se actualizó el APK.
Microdroid no arrancará si alguno de los APEX falla en la verificación.
Microdroid no arranca (o arranca con un estado inicial limpio) si el archivo instance.img se modifica fuera del pVM invitado.
Microdroid proporciona atestación de la cadena de arranque.
Cualquier modificación (sin firmar) de las imágenes de disco compartidas con el pVM invitado provoca un error de E/S en el lado del pVM.
Los BCC y CDI proporcionados a una instancia de pVM solo pueden derivarse de esa instancia en particular.

Androide

Estas son propiedades mantenidas por Android como anfitrión, pero no son válidas en caso de compromiso del anfitrión:

Un pVM invitado no puede interactuar directamente con (por ejemplo, establecer una conexión vsock con) otros pVM invitados.
Solo el VirtualizationService en el host pVM puede hacer un canal de comunicación a un pVM (Nota: puede pasar el canal establecido a otros).
Solo las aplicaciones que están firmadas con la clave de la plataforma pueden solicitar permiso para crear, poseer o interactuar con pVM.
El identificador, denominado identificador de contexto (CID) , que se usa para configurar conexiones vsock entre el host y pVM no se reutiliza mientras se ejecuta el host pVM. Por ejemplo, no es posible reemplazar una pVM en ejecución por otra.

Disponibilidad

En el contexto de las pVM, la disponibilidad se refiere a que el host asigna suficientes recursos a los invitados para que puedan realizar las tareas para las que fueron diseñados.

Las responsabilidades del host incluyen la programación de las CPU virtuales de pVM. KVM, a diferencia de los hipervisores Tipo-1 tradicionales, 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 de hoy, esta decisión de diseño reduce significativamente el tamaño de la base informática confiable (TCB) y permite que el host tome decisiones de programación más informadas para optimizar el rendimiento. Sin embargo, un host malintencionado puede optar por no programar nunca un invitado.

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

Finalmente, el proceso de monitor 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 brinda disponibilidad a los invitados, el diseño protege la disponibilidad del host de invitados maliciosos porque el host siempre puede adelantarse o cancelar a un invitado y recuperar sus recursos.

Arranque 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 arranque de una instancia la aprovisiona generando aleatoriamente un salt secreto 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 arranques posteriores de la instancia de pVM y garantizar que los secretos de la instancia se publiquen solo para las imágenes que pasan la verificación. Este proceso ocurre para cada etapa de carga dentro de pVM: firmware de pVM, pVM ABL, Microdroid, etc.

DICE proporciona a cada etapa de carga un par de claves de atestación, cuya parte pública está certificada en la entrada BCC para esa etapa. Este par de claves puede cambiar entre arranques, por lo que también se deriva un secreto de sellado que es estable para la instancia de VM durante los reinicios y, como tal, es adecuado para proteger el estado persistente. El secreto de sellado es muy valioso para la máquina virtual, por lo que no debe usarse directamente. En cambio, las claves de sellado deben derivarse del secreto de sellado y el secreto de sellado debe destruirse lo antes posible.

Cada etapa entrega un objeto CBOR codificado de forma determinista a la siguiente etapa. Este objeto contiene secretos y el BCC, que contiene información de estado acumulada, como si la última etapa se cargó de forma segura.

Dispositivos desbloqueados

Cuando un dispositivo se desbloquea con fastboot oem unlock , los datos del usuario se borran. 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 produce el desbloqueo de un dispositivo.

Una vez desbloqueado, el propietario del dispositivo puede actualizar las particiones que generalmente están protegidas por un arranque verificado, incluidas las particiones que contienen la implementación de pKVM. Por lo tanto, no se confiará en pKVM en un dispositivo desbloqueado para mantener el modelo de seguridad.

Las partes remotas pueden observar este estado potencialmente inseguro al inspeccionar el estado de arranque verificado del dispositivo en un certificado de atestación de clave.