Google se compromete a promover la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Verificación de arranque

El arranque verificado requiere verificar criptográficamente todo el código ejecutable y los datos que forman parte de la versión de Android que se está iniciando antes de usarse. Esto incluye el kernel (cargado desde la partición de boot ), el árbol de dispositivos (cargado desde la partición dtbo ), la partición del system , la partición del vendor , etc.

Las particiones pequeñas, como boot y dtbo , que se leen solo una vez, generalmente se verifican al cargar todo el contenido en la memoria y luego calcular su hash. Este valor de hash calculado se compara con el valor de hash esperado . Si el valor no coincide, Android no se cargará. Para más detalles, vea Boot Flow .

Las particiones más grandes que no caben en la memoria (como los sistemas de archivos) pueden usar un árbol hash donde la verificación es un proceso continuo que ocurre cuando los datos se cargan en la memoria. En este caso, el hash raíz del árbol hash se calcula durante el tiempo de ejecución y se compara con el valor hash raíz esperado . Android incluye el controlador dm-verity para verificar particiones más grandes. Si en algún momento el hash raíz calculado no coincide con el valor de hash raíz esperado , los datos no se usan y Android entra en un estado de error. Para más detalles, vea corrupción de dm-verity .

Los hashes esperados generalmente se almacenan al final o al principio de cada partición verificada, en una partición dedicada o en ambos. Fundamentalmente, estos hash están firmados (ya sea directa o indirectamente) por la raíz de la confianza. Como ejemplo, la implementación de AVB es compatible con ambos enfoques; consulte Inicio verificado de Android para obtener más información.

Protección de retroceso

Incluso con un proceso de actualización completamente seguro, es posible que un exploit de kernel de Android no persistente instale manualmente una versión anterior y más vulnerable de Android, reinicie en la versión vulnerable y luego use esa versión de Android para instalar un exploit persistente. A partir de ahí, el atacante posee permanentemente el dispositivo y puede hacer cualquier cosa, incluida la desactivación de actualizaciones.

La protección contra esta clase de ataques se llama Rollback Protection . La protección de reversión generalmente se implementa mediante el uso de almacenamiento a prueba de manipulaciones para registrar la versión más reciente de Android y negarse a iniciar Android si es inferior a la versión registrada. Las versiones suelen rastrearse por partición.

Para obtener más detalles sobre cómo AVB maneja las protecciones de reversión, consulte el archivo AVB README .

Manejo de errores de verificación

La verificación puede fallar en el momento del arranque (por ejemplo, si el hash calculado en la partición de boot no coincide con el hash esperado) o en el tiempo de ejecución (por ejemplo, si dm-verity encuentra un error de verificación en la partición del system ). Si la verificación falla en el momento del arranque, el dispositivo no puede arrancar y el usuario final debe seguir los pasos para recuperar el dispositivo.

Si la verificación falla en tiempo de ejecución, el flujo es un poco más complicado. Si el dispositivo usa dm-verity, debe configurarse en modo de restart . En el modo de restart , si se encuentra un error de verificación, el dispositivo se reinicia inmediatamente con un indicador específico establecido para indicar el motivo. El gestor de arranque debe notar este indicador y cambiar dm-verity para usar el modo de error de E / S ( eio ) y permanecer en este modo hasta que se haya instalado una nueva actualización.

Al arrancar en modo eio , el dispositivo muestra una pantalla de error que informa al usuario que se ha detectado corrupción y que el dispositivo no funciona correctamente. La pantalla se muestra hasta que el usuario la descarta. En el modo eio , el controlador dm-verity no reiniciará el dispositivo si se encuentra un error de verificación, en su lugar, se devuelve un error EIO y la aplicación debe lidiar con el error.

La intención es que se ejecute el actualizador del sistema (para que se pueda instalar un nuevo sistema operativo sin errores de corrupción) o que el usuario pueda sacar la mayor cantidad de datos posible del dispositivo. Una vez que se ha instalado el nuevo sistema operativo, el gestor de arranque se da cuenta del sistema operativo recién instalado y vuelve al modo de restart .