Ah, fragmentación: una palabra que ha manchado la plataforma Android desde sus inicios. La forma en que Google diseñó y licenció Android fue concebida para promover su pronta adopción por parte de los fabricantes de equipos originales, pero esas primeras decisiones de diseño condujeron a años de deuda técnica acumulada que requieren grandes esfuerzos técnicos para ser resueltos. Poco a poco, Google está recuperando el control de Android para hacer frente a la fragmentación. En primer lugar, abordó el marco central de Android con el Proyecto Treble y la Imagen Genérica del Sistema (GSI). Después, se centró en los componentes principales del sistema Android con el Proyecto Mainline. Más recientemente, abordó la fragmentación del kernel con la Imagen Genérica del Kernel (GKI). El siguiente frente en la guerra de varios años de Google contra la fragmentación es la virtualización.

La virtualización en Android es un tema sobre el que no encontrarás mucha discusión porque es esotérico y el trabajo está en curso en silencio, pero si has seguido mi trabajo, sabrás que no importa lo nicho que sea: si está relacionado con Android, es mi especialidad. Por eso voy a dedicar la edición de esta semana de Android Dessert Bites a la virtualización en Android y a lo que Google planea hacer con ella.

Gracias por suscribirse al boletín de The Android Edge. Cada semana, mi columna Android Dessert Bites compartirá las últimas noticias sobre la plataforma Android que son importantes para los ingenieros de sistemas, los desarrolladores de aplicaciones y los usuarios avanzados.

Llevando KVM a Android

La virtualización en Android es hoy "el salvaje oeste de la fragmentación", según Will Deacon, del equipo de sistemas de Android. Esto se debe a que los hipervisores pueden o no estar presentes en un dispositivo, y cuando lo están, a menudo ni siquiera se utilizan para su propósito previsto, que es ejecutar un sistema operativo en una máquina virtual. En cambio, se utilizan para cosas como mejorar la seguridad del núcleo (o al menos intentarlo) y ejecutar código diverso (como código de terceros para DRM, criptografía y otros binarios de código cerrado) fuera del sistema operativo Android.

Para entender por qué esto último es particularmente problemático, considere que en el modelo de excepción de Armv8/v9, el hipervisor se ejecuta en el nivel de excepción 2 (EL2). En la nomenclatura de Arm, cuanto más alto es el número, más alto es el nivel de privilegio, lo que significa que el código que se ejecuta en EL0 (por ejemplo, las aplicaciones del espacio de usuario) es el menos privilegiado, el código que se ejecuta en EL1 (por ejemplo, el sistema operativo Android y el núcleo de Linux) es más privilegiado, y así sucesivamente. Por lo tanto, un montón de bloques binarios opacos de terceros se ejecutan con privilegios más altos que incluso el sistema operativo y el kernel. Esto es perjudicial para la seguridad, ya que aumenta la superficie de ataque del código privilegiado que puede ser explotado, ya que el código que se ejecuta en un EL superior puede acceder a todos los registros de los niveles inferiores.

Con el fin de eliminar los privilegios de este código de terceros y aislarlo de Android y otros programas de terceros, Google está trabajando para ofrecer una solución de hipervisor común sobre la que una máquina virtual que se ejecuta al mismo nivel de privilegios que el sistema operativo y el núcleo ejecutará ese código. Existe un mecanismo maduro de virtualización del kernel llamado KVM que ya está soportado por Linux, así que naturalmente Google está eligiendo desplegarlo como el hipervisor común. Y gracias a los esfuerzos continuos de Google por reducir la fragmentación del núcleo, KVM puede ser habilitado en un amplio espectro de dispositivos Android que cuenten con una versión reciente de la GKI.

(Nota: Google está ampliando KVM con características de seguridad adicionales y lo llama pKVM, o "KVM protegido". pKVM está diseñado para permitir la confidencialidad de los datos en una máquina virtual, incluso si el sistema operativo se ve comprometido. La implementación está disponible en las ramas de Android Common Kernel mainline, android13-5.10 y android13-5.15).

Para gestionar estas máquinas virtuales, Google está portando crosvm, el gestor de máquinas virtuales (VMM) basado en Rust que se utiliza para ejecutar aplicaciones de Linux en Chrome OS, a Android, y se entregará a los dispositivos a través de un nuevo módulo de la línea principal llamado "Virtualización" (com.android.virt). Actualmente, ningún dispositivo Android del mercado viene con el módulo de virtualización -ni siquiera el propio Pixel 6 de Google-, pero esto cambiará con la próxima versión de Android 13. De hecho, Google está probando actualmente sus nuevas herramientas de virtualización en el Pixel 6; si construyes AOSP con el objetivo aosp_oriole_pkvm, verás que com.android.virt se heredará automáticamente. No sé si Google habilitará pKVM en la serie Pixel 6 con la actualización de Android 13, pero hay pruebas de que Google planea que Android 13 incluya la primera versión del hipervisor pKVM y el marco de la máquina virtual.

Compilación aislada en una máquina virtual con CompOS

Una vez sentadas las bases para ejecutar máquinas virtuales en un hipervisor, la pregunta es la siguiente: ¿Para qué función(es) planea Google utilizar esto? Gracias a una serie de cambios en el código enviados a AOSP Gerrit, me he enterado de una forma en la que Google planea demostrar el nuevo soporte de virtualización de Android: la compilación aislada.

A principios de este año, compartí que Google está trabajando en una nueva compilación de Android llamada "microdroid". Google describe microdroid como "una versión (muy) ligera de Android que está pensada para ejecutarse en máquinas virtuales en el dispositivo" y albergar cargas de trabajo nativas y sin interfaz gráfica. Está construido "a partir del mismo código fuente que Android normal, pero es mucho más pequeño", ya que carece del proceso system_server, de HALs o de una GUI. Microdroid está incluido en el módulo de virtualización con su carga útil de módulos APEX y APKs definidos en un archivo JSON y sus particiones y memoria asignada definidos en otro.

Curiosamente, parece que microdroid es sólo el nombre por defecto del sistema operativo en la VM - puede ser configurado para ser llamado de otra manera. Esto es lo que creo que es "CompOS" - una instancia de microdroid que se dedica a realizar la compilación aislada. (CompOS es la abreviatura de "Compilation OS", en caso de que te lo preguntes).

Puede que te preguntes en este punto qué significa compilación aislada. Según Google, la compilación aislada es la compilación de los JAR de arranque y del classpath del system_server en una VM protegida. Cuando se configura la ROM del sistema, los fabricantes de dispositivos suelen enviar código precompilado para servicios básicos como system_server y otras clases que zygote inicializa al arrancar. Cada vez que se actualiza el tiempo de ejecución de Android (ART), lo que ahora puede ocurrir fuera de banda ya que se convirtió en un módulo de línea principal en Android 12, es posible que los artefactos de compilación para las extensiones de la ruta de la clase de arranque y system_server necesiten ser regenerados usando la herramienta odrefresh (por lo que las actualizaciones de ART APEX a veces muestran una barra de progreso durante el arranque). En Android 12, todo esto ocurre en el SO anfitrión porque no hay soporte de virtualización, pero en Android 13, esto podría ocurrir en CompOS.

Para ser totalmente honesto, no estoy completamente seguro de por qué es ventajoso mover esta compilación a una VM aislada, pero he escuchado algunas teorías. En primer lugar, mover esta funcionalidad a una VM hace que el proceso en general sea más seguro. Cualquier exploit durante el proceso necesitaría encadenarse en un exploit del hipervisor para escapar de la VM y acceder a los datos en el SO anfitrión. Ten en cuenta que muchas partes del marco de la máquina virtual están escritas en Rust, un lenguaje de programación diseñado teniendo en cuenta la seguridad de la gestión de la memoria, por lo que esto no es trivial. En segundo lugar, un proceso system_server comprometido podría ser utilizado para aceptar archivos OAT modificados. Ejecutando dex2oat en una VM verificada por el hipervisor, el archivo OAT compilado puede ser verificado criptográficamente. Sin embargo, estas son sólo teorías. Sólo Google sabe la razón exacta de esta función, pero no estoy al tanto de las discusiones internas que llevaron al desarrollo de CompOS.

La compilación aislada no parece un uso especialmente interesante de la virtualización en Android, pero lo más probable es que no sea el único caso de uso en el que está trabajando Google. Lo que ocurre es que es el único caso de uso que se desarrolla principalmente en público. Hay otras cosas que Google puede hacer con una versión virtualizada de Android, pero tendremos que esperar al lanzamiento de Android 13 para saber cuáles son. Mientras tanto, si estás interesado en jugar con la virtualización en Android por ti mismo, Google tiene una guía sobre cómo empezar con máquinas virtuales protegidas y microdroid.

Link - Fuente

Si te ha gustado el contenido, puedes apoyarnos con un

Donativo

¡Gracias por tu colaboración!