Extensión de etiquetado de memoria de Arm

Arm v9 presenta la extensión de etiquetado de memoria (MTE) de Arm, una implementación de hardware de la memoria etiquetada.

A un nivel alto, MTE etiqueta cada asignación o desasignación de memoria con metadatos adicionales. Asigna una etiqueta a una ubicación de memoria, que luego se puede asociar con punteros que hacen referencia a esa ubicación de memoria. Durante el tiempo de ejecución, la CPU verifica que el puntero y las etiquetas de metadatos coincidan en cada carga y almacenamiento.

En Android 12, el asignador de memoria de montón del kernel y del espacio de usuario puede aumentar cada asignación con metadatos. Esto ayuda a detectar errores de uso después de la liberación y de desbordamiento del búfer, que son la fuente más común de errores de seguridad de la memoria en nuestras bases de código.

Modos de operación de MTE

MTE tiene tres modos de operación:

  • Modo síncrono (SYNC)
  • Modo asíncrono (ASYNC)
  • Modo asimétrico (ASYMM)

Modo síncrono (SYNC)

Este modo está optimizado para la precisión de la detección de errores por sobre el rendimiento y se puede usar como una herramienta de detección de errores precisa; se debe tener en cuenta que la sobrecarga de rendimiento será mayor. Cuando MTE SYNC está habilitado, actúa como mitigación de seguridad. En una discrepancia de etiqueta, el procesador aborta la ejecución de inmediato y finaliza el proceso con SIGSEGV (código SEGV_MTESERR) y la información completa sobre el acceso a la memoria y la dirección con errores.

Recomendamos usar este modo durante las pruebas como alternativa a HWASan/KASAN o en producción cuando el proceso de destino representa una superficie de ataque vulnerable. Además, cuando el modo ASYNC indica la presencia de un error, se puede obtener un informe de errores preciso usando las APIs de entorno de ejecución para cambiar la ejecución al modo SYNC.

Cuando se ejecuta en modo SYNC, el asignador de Android registra los seguimientos de pila para todas las asignaciones y desasignaciones, y los usa para proporcionar mejores informes de errores que incluyen una explicación de un error de memoria, como el uso después de la liberación o el desbordamiento de búfer, y los seguimientos de pila de los eventos de memoria relevantes. Esos informes proporcionan más información contextual y hacen que los errores sean más fáciles de rastrear y corregir.

Modo asíncrono (ASYNC)

Este modo está optimizado para el rendimiento por sobre la precisión de los informes de errores y se puede usar como detección de baja sobrecarga para errores de seguridad de memoria.
En una discrepancia de etiqueta, el procesador continúa la ejecución hasta la entrada de kernel más cercana (por ejemplo, una llamada de sistema o interrupción del temporizador), donde finaliza el proceso con SIGSEGV (código SEGV_MTEAERR) sin registrar la dirección o el acceso a la memoria con errores.
Recomendamos usar este modo en producción en bases de código probadas donde se sabe que la densidad de errores de seguridad de la memoria es baja, lo que se logra usando el modo SYNC durante las pruebas.

Modo asimétrico (ASYMM)

Una función adicional en Arm v8.7-A, el modo MTE asimétrico, proporciona una verificación síncrona de las operaciones de lectura de memoria y una verificación asíncrona de las operaciones de escritura en la memoria, con un rendimiento similar al del modo ASYNC. En la mayoría de las situaciones, este modo es una mejora con respecto al modo ASYNC, y te recomendamos que lo uses en lugar de ASYNC siempre que esté disponible.

Por este motivo, ninguna de las APIs que se describen a continuación menciona el modo asimétrico. En su lugar, el SO se puede configurar para que siempre use el modo asimétrico cuando se solicite lo asíncrono. Consulta la sección "Configura el nivel de MTE preferido específico de la CPU" para obtener más información.

MTE en el espacio de usuario

En las siguientes secciones, se describe cómo se puede habilitar MTE para los procesos y las apps del sistema. MTE está inhabilitada de forma predeterminada, a menos que se configure una de las siguientes opciones para un proceso en particular (consulta en a continuación para ver para qué componentes está habilitada MTE).

Habilita MTE con el sistema de compilación

Como propiedad de todo el proceso, MTE está controlada por la configuración del tiempo de compilación del ejecutable principal. Las siguientes opciones permiten cambiar este parámetro de configuración para ejecutables individuales o para subdirectorios completos en el árbol de origen. La configuración se ignora en las bibliotecas o en cualquier destino que no sea ejecutable ni una prueba.

1. Habilita MTE en Android.bp (ejemplo) para un proyecto en particular:

Modo MTE Configuración
MTE asíncrono 
  sanitize: {
  memtag_heap: true,
  }
MTE síncrona 
  sanitize: {
  memtag_heap: true,
  diag: {
  memtag_heap: true,
  },
  }

o en Android.mk:

Modo MTE Configuración
Asynchronous MTE LOCAL_SANITIZE := memtag_heap
Synchronous MTE LOCAL_SANITIZE := memtag_heap
LOCAL_SANITIZE_DIAG := memtag_heap

2. Habilita MTE en un subdirectorio del árbol de origen con una variable de producto:

Modo MTE Incluir lista Lista de exclusiones
asincrónico PRODUCT_MEMTAG_HEAP_ASYNC_INCLUDE_PATHS MEMTAG_HEAP_ASYNC_INCLUDE_PATHS PRODUCT_MEMTAG_HEAP_EXCLUDE_PATHS MEMTAG_HEAP_EXCLUDE_PATHS
sincronizar PRODUCT_MEMTAG_HEAP_SYNC_INCLUDE_PATHS MEMTAG_HEAP_SYNC_INCLUDE_PATHS

o

Modo MTE Configuración
MTE asíncrono MEMTAG_HEAP_ASYNC_INCLUDE_PATHS
MTE síncrona MEMTAG_HEAP_SYNC_INCLUDE_PATHS

o bien especificando la ruta de acceso de exclusión de un ejecutable:

Modo MTE Configuración
MTE asíncrono PRODUCT_MEMTAG_HEAP_EXCLUDE_PATHS MEMTAG_HEAP_EXCLUDE_PATHS
MTE síncrona

Ejemplo (uso similar a PRODUCT_CFI_INCLUDE_PATHS):

  PRODUCT_MEMTAG_HEAP_SYNC_INCLUDE_PATHS=vendor/$(vendor)
  PRODUCT_MEMTAG_HEAP_EXCLUDE_PATHS=vendor/$(vendor)/projectA \
                                    vendor/$(vendor)/projectB

Habilita MTE con propiedades del sistema

La configuración de compilación anterior se puede anular durante el tiempo de ejecución si se establece la siguiente propiedad del sistema:

arm64.memtag.process.<basename> = (off|sync|async)

En el que basename representa el nombre base del ejecutable.

Por ejemplo, para configurar /system/bin/ping o /data/local/tmp/ping para usar MTE asíncrono, usa adb shell setprop arm64.memtag.process.ping async.

Habilita MTE con una variable de entorno

Otra forma de anular la configuración de compilación es definir la variable de entorno: MEMTAG_OPTIONS=(off|sync|async). Si se definen la variable de entorno y la propiedad del sistema, la variable tiene prioridad.

Cómo habilitar MTE para apps

Si no se especifica, MTE se inhabilita de forma predeterminada, pero las apps que quieran usar MTE pueden configurar android:memtagMode en la etiqueta <application> o <process> en AndroidManifest.xml.

android:memtagMode=(off|default|sync|async)

Cuando se establece en la etiqueta <application>, el atributo afecta a todos los procesos que usa la app y se puede anular en procesos individuales si configuras la etiqueta <process>.

Durante la experimentación, los cambios de compatibilidad se pueden usar para establecer el valor predeterminado del atributo memtagMode para una app que no especifica ningún valor en el manifiesto (o especifica default).
se puede encontrar en System > Advanced > Developer options > App Compatibility Changes en el menú de configuración global. La configuración de NATIVE_MEMTAG_ASYNC o NATIVE_MEMTAG_SYNC habilita MTE para una app en particular.
Como alternativa, esto se puede configurar con el comando am de la siguiente manera:

$ adb shell am compat enable NATIVE_MEMTAG_[A]SYNC my.app.name

Compila una imagen del sistema de MTE

Te recomendamos que habilites MTE en todos los objetos binarios nativos durante el desarrollo y el inicio. Esto ayuda a detectar errores de seguridad de la memoria con anticipación y proporciona una cobertura de usuarios realista, si está habilitada en las compilaciones de prueba.

Te recomendamos que habilites MTE en modo síncrono en todos los objetos binarios nativos durante el desarrollo.

SANITIZE_TARGET=memtag_heap SANITIZE_TARGET_DIAG=memtag_heap m

Al igual que con cualquier variable del sistema de compilación, SANITIZE_TARGET se puede usar como variable de entorno o como configuración de make (por ejemplo, en un archivo product.mk).
Ten en cuenta que esto habilita MTE para todos los procesos nativos, pero no para las apps (que se bifurcan desde zygote64) para las que se puede habilitar MTE siguiendo las instrucciones anteriores.

Configura el nivel de MTE preferido específico de la CPU

En algunas CPU, el rendimiento de MTE en los modos ASYMM o incluso SYNC puede ser similar al de ASYNC. Por lo tanto, vale la pena habilitar verificaciones más estrictas en esas CPUs cuando se solicita un modo de verificación menos estricto para obtener los beneficios de detección de errores de las verificaciones más estrictas sin las desventajas de rendimiento.
De forma predeterminada, los procesos configurados para ejecutarse en el modo ASYNC se ejecutarán en el modo ASYNC en todas las CPUs. Para configurar el kernel para que ejecute estos procesos en el modo SYNC en CPUs específicas, la sincronización de valores se debe escribir en la entrada sysfs /sys/devices/system/cpu/cpu<N>/mte_tcf_preferred durante el inicio. Esto se puede hacer con una secuencia de comandos de init. Por ejemplo, para configurar las CPUs del 0 al 1 para que ejecuten procesos en modo ASYNC en modo SYNC, y las CPUs del 2 al 3 para que se ejecuten en modo ASYMM, se puede agregar lo siguiente a la cláusula init de una secuencia de comandos de init del proveedor: 

  write /sys/devices/system/cpu/cpu0/mte_tcf_preferred sync
  write /sys/devices/system/cpu/cpu1/mte_tcf_preferred sync
  write /sys/devices/system/cpu/cpu2/mte_tcf_preferred asymm
  write /sys/devices/system/cpu/cpu3/mte_tcf_preferred asymm

Las lápidas de los procesos del modo ASYNC que se ejecutan en el modo SYNC contendrán un seguimiento de pila preciso de la ubicación del error de memoria. Sin embargo, no incluirán un seguimiento de pila de asignación o desasignación. Estos seguimientos de pila solo están disponibles si el proceso está configurado para ejecutarse en modo SYNC.

int mallopt(M_THREAD_DISABLE_MEM_INIT, level)

donde level es 0 o 1.
Inhabilita la inicialización de la memoria en malloc y evita cambiar las etiquetas de memoria, a menos que sea necesario para la corrección.

int mallopt(M_MEMTAG_TUNING, level)

En el ejemplo anterior, level es:

  • M_MEMTAG_TUNING_BUFFER_OVERFLOW
  • M_MEMTAG_TUNING_UAF

Selecciona la estrategia de asignación de etiquetas.

  • La configuración predeterminada es M_MEMTAG_TUNING_BUFFER_OVERFLOW.
  • M_MEMTAG_TUNING_BUFFER_OVERFLOW: Permite la detección determinista de errores de desbordamiento y subflujo de búfer lineal asignando valores de etiqueta distintos a las asignaciones adyacentes. Este modo tiene una probabilidad ligeramente reducida de detectar errores de uso después de la liberación porque solo la mitad de los valores de etiqueta posibles están disponibles para cada ubicación de memoria. Ten en cuenta que MTE no puede detectar derrames dentro del mismo gránulo de etiqueta (fragmento alineado de 16 bytes) y puede pasar por alto derrames pequeños incluso en este modo. Ese desbordamiento no puede ser la causa de la corrupción de la memoria, ya que la memoria dentro de un gránulo nunca se usa para varias asignaciones.
  • M_MEMTAG_TUNING_UAF: Habilita etiquetas aleatorias independientes para una probabilidad uniforme de alrededor del 93% de detectar errores espaciales (desbordamiento del búfer) y temporales (uso después de la liberación).

Además de las APIs que se describieron anteriormente, es posible que los usuarios experimentados deban tener en cuenta lo siguiente:

  • La configuración del registro de hardware PSTATE.TCO puede suprimir temporalmente la verificación de etiquetas (ejemplo). Por ejemplo, cuando se copia un rango de memoria con contenido de etiqueta desconocido o se aborda un cuello de botella de rendimiento en un bucle activo.
  • Cuando se usa M_HEAP_TAGGING_LEVEL_SYNC, el controlador de fallas del sistema proporciona información adicional, como seguimientos de pila de asignación y desasignación. Esta funcionalidad requiere acceso a los bits de etiqueta y se habilita pasando la marca SA_EXPOSE_TAGBITS cuando se configura el controlador de indicadores. Se recomienda que cualquier programa que establezca su propio controlador de señales y delegue fallas desconocidas al sistema haga lo mismo.

MTE en el kernel

Para habilitar KASAN acelerado por MTE para el kernel, configúralo con CONFIG_KASAN=y, CONFIG_KASAN_HW_TAGS=y. Estas configuraciones están habilitadas de forma predeterminada en los kernels de GKI, a partir de Android 12-5.10.
Esto se puede controlar durante el inicio con los siguientes argumentos de línea de comandos:

  • kasan=[on|off]: Habilita o inhabilita KASAN (predeterminado: on).
  • kasan.mode=[sync|async]: Elige entre el modo síncrono y asíncrono (predeterminado: sync).
  • kasan.stacktrace=[on|off]: Indica si se deben recopilar los seguimientos de pila (predeterminado: on).
    • La recopilación de seguimiento de pila también requiere stack_depot_disable=off.
  • kasan.fault=[report|panic]: Indica si solo se debe imprimir el informe o si también se debe generar un error de pánico en el kernel (predeterminado: report). Independientemente de esta opción, la verificación de etiquetas se inhabilita después del primer error informado.

Te recomendamos que uses el modo SYNC durante el inicio, el desarrollo y las pruebas. Esta opción debe estar habilitada de forma global para todos los procesos que usan la variable de entorno o el sistema de compilación. En este modo, los errores se detectan al comienzo del proceso de desarrollo, la base de código se estabiliza más rápido y se evita el costo de detectar errores más adelante en la producción.

Te recomendamos que uses el modo ASYNC en producción. Esto proporciona una herramienta de baja sobrecarga para detectar la presencia de errores de seguridad de la memoria en un proceso, así como una mayor defensa en profundidad. Una vez que se detecta un error, el desarrollador puede aprovechar las APIs del entorno de ejecución para cambiar al modo SYNC y obtener un seguimiento de pila preciso de un conjunto de usuarios muestreados.

Te recomendamos configurar el nivel de MTE preferido específico de la CPU para el SoC. Por lo general, el modo asimétrico tiene las mismas características de rendimiento que ASYNC y casi siempre es preferible. Los núcleos en orden pequeños suelen mostrar un rendimiento similar en los tres modos y se pueden configurar para que prefieran SYNC.

Los desarrolladores deben verificar la presencia de fallas. Para ello, deben consultar /data/tombstones, logcat o supervisar la canalización DropboxManager del proveedor en busca de errores del usuario final. Para obtener más información sobre la depuración de código nativo de Android, consulta la información aquí.

Componentes de la plataforma habilitados para MTE

En Android 12, varios componentes del sistema críticos para la seguridad usan MTE ASYNC para detectar fallas del usuario final y actuar como una capa adicional de defensa en profundidad. Estos componentes son los siguientes:

  • Utilidades y demonios de red (excepto netd)
  • Bluetooth, SecureElement, HAL de NFC y apps del sistema
  • Daemon de statsd
  • system_server
  • zygote64 (para permitir que las apps habiliten el uso de MTE)

Estos objetivos se seleccionaron en función de los siguientes criterios:

  • Un proceso con privilegios (definido como un proceso que tiene acceso a algo que el dominio SELinux de unprivileged_app no tiene)
  • Procesa entradas poco confiables (regla de dos)
  • Disminución aceptable del rendimiento (la disminución no crea latencia visible para el usuario)

Recomendamos a los proveedores que habiliten la MTE en producción para más componentes, según los criterios mencionados anteriormente. Durante el desarrollo, te recomendamos que pruebes estos componentes con el modo SYNC para detectar errores que se puedan corregir fácilmente y evaluar el impacto de ASYNC en su rendimiento.
En el futuro, Android planea expandir la lista de componentes del sistema en los que está habilitada la MTE, según las características de rendimiento de los próximos diseños de hardware.