Extensión de etiquetado de memoria de brazo

Arm v9 presenta Arm Memory Tagging Extension (MTE), una implementación de hardware de memoria etiquetada.

En un nivel alto, MTE etiqueta cada asignación/desasignación de memoria con metadatos adicionales. Asigna una etiqueta a una ubicación de memoria, que luego puede asociarse con punteros que hacen referencia a esa ubicación de memoria. En 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 dinámica 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 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 funcionamiento MTE

MTE tiene tres modos de funcionamiento:

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

Modo síncrono (SYNC)

Este modo está optimizado para la corrección de la detección de errores sobre el rendimiento y se puede utilizar como una herramienta de detección de errores precisa, cuando es aceptable una mayor sobrecarga de rendimiento. Cuando está habilitado, MTE SYNC actúa como mitigación de seguridad. Si la etiqueta no coincide, el procesador aborta la ejecución inmediatamente y finaliza el proceso con SIGSEGV (código SEGV_MTESERR ) e información completa sobre el acceso a la memoria y la dirección errónea.

Recomendamos utilizar este modo durante las pruebas como alternativa a HWASan/KASAN o en producción cuando el proceso objetivo representa una superficie de ataque vulnerable. Además, cuando el modo ASYNC ha indicado la presencia de un error, se puede obtener un informe de error preciso utilizando las API en tiempo 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 la pila para todas las asignaciones y desasignaciones y los utiliza para proporcionar mejores informes de errores que incluyen una explicación de un error de memoria, como uso después de la liberación o desbordamiento del búfer, y la pila. huellas de los acontecimientos mnémicos relevantes. Estos informes proporcionan más información contextual y facilitan el seguimiento y la corrección de errores.

Modo asíncrono (ASYNC)

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

Modo asimétrico (ASYMM)

Una característica adicional en Arm v8.7-A, el modo MTE asimétrico, proporciona verificación sincrónica de lecturas de memoria y verificación asincrónica de escrituras de 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 recomendamos usarlo en lugar de ASYNC siempre que esté disponible.

Por este motivo, ninguna de las API que se describen a continuación menciona el modo asimétrico. En su lugar, el sistema operativo se puede configurar para usar siempre el modo asimétrico cuando se solicita asincrónico. Consulte la sección "Configuración del nivel MTE preferido específico de la CPU" para obtener más información.

MTE en el espacio de usuario

Las siguientes secciones describen cómo se puede habilitar MTE para procesos y aplicaciones del sistema. MTE está deshabilitado de forma predeterminada, a menos que una de las siguientes opciones esté configurada para un proceso en particular (consulte para qué componentes está habilitado MTE a continuación ).

Habilitando MTE usando el sistema de compilación

Como propiedad de todo el proceso, MTE está controlado por la configuración del tiempo de compilación del ejecutable principal. Las siguientes opciones permiten cambiar esta 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 de prueba.

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

  sanitize: {
  memtag_heap: true,
  }

  sanitize: {
  memtag_heap: true,
  diag: {
  memtag_heap: true,
  },
  }

o en Android.mk:

2. Habilitar MTE en un subdirectorio en el árbol de origen usando una variable de producto:

o

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

Ejemplo (uso similar a PRODUCT_CFI_INCLUDE_PATHS )

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

Habilitar MTE usando las propiedades del sistema

La configuración de compilación anterior se puede anular en tiempo de ejecución configurando la siguiente propiedad del sistema:

Donde basename representa el nombre base del ejecutable.

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

Habilitar MTE usando una variable de entorno

Una forma más de anular la configuración de compilación es definiendo la variable de entorno: MEMTAG_OPTIONS=(off|sync|async) Si se definen tanto la variable de entorno como la propiedad del sistema, la variable tiene prioridad.

Habilitación de MTE para aplicaciones

Si no se especifica, MTE está deshabilitado de forma predeterminada, pero las aplicaciones que quieran usar MTE pueden hacerlo configurando android:memtagMode en la etiqueta <application> o <process> en AndroidManifest.xml .

Cuando se establece en la etiqueta <application> , el atributo afecta a todos los procesos utilizados por la aplicación y se puede anular para procesos individuales configurando la etiqueta <process> .

Para experimentar, se pueden usar cambios de compatibilidad para establecer el valor predeterminado del atributo memtagMode para una aplicación que no especifica ningún valor en el manifiesto (o especifica default ).
Estos se pueden encontrar en System > Advanced > Developer options > App Compatibility Changes en el menú de configuración global. Configurar NATIVE_MEMTAG_ASYNC o NATIVE_MEMTAG_SYNC habilita MTE para una aplicación particular.
Alternativamente, esto se puede configurar usando el comando am de la siguiente manera:

Construyendo una imagen del sistema MTE

Recomendamos encarecidamente habilitar MTE en todos los archivos binarios nativos durante el desarrollo y la puesta en marcha. Esto ayuda a detectar errores de seguridad de la memoria de manera temprana y proporciona una cobertura realista para el usuario, si se habilita en las compilaciones de prueba.

Recomendamos encarecidamente habilitar MTE en modo síncrono en todos los archivos binarios nativos durante el desarrollo.

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

Configuración del nivel MTE preferido específico de la CPU

En algunas CPU, el rendimiento de MTE en modo ASYMM o incluso SYNC puede ser similar al de ASYNC. Esto hace que valga la pena habilitar controles más estrictos en esas CPU cuando se solicita un modo de control menos estricto, para obtener los beneficios de detección de errores de los controles más estrictos sin las desventajas de rendimiento.
De forma predeterminada, los procesos configurados para ejecutarse en modo ASYNC se ejecutarán en modo ASYNC en todas las CPU. Para configurar el kernel para ejecutar estos procesos en modo SYNC en CPU específicas, el valor sync debe escribirse en la entrada sysfs /sys/devices/system/cpu/cpu<N>/mte_tcf_preferred en el momento del arranque. Esto se puede hacer con un script de inicio. Por ejemplo, para configurar las CPU 0-1 para ejecutar procesos en modo ASYNC en modo SYNC y las CPU 2-3 para ejecutar en modo ASYMM, se puede agregar lo siguiente a la cláusula init de un script de inicio 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

Los lápidas de los procesos en modo ASYNC que se ejecutan en 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 la 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.

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

donde 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 subdesbordamiento del búfer lineal mediante la asignación de distintos valores de etiquetas a 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 etiquetas posibles están disponibles para cada ubicación de memoria. Tenga en cuenta que MTE no puede detectar desbordamientos dentro del mismo gránulo de etiqueta (fragmento alineado de 16 bytes) y puede pasar por alto pequeños desbordamientos incluso en este modo. Este desbordamiento no puede ser la causa de daños en la memoria, porque la memoria dentro de un gránulo nunca se utiliza para asignaciones múltiples.
• M_MEMTAG_TUNING_UAF : habilita etiquetas aleatorias independientes para una probabilidad uniforme de ~93 % de detectar errores tanto espaciales (desbordamiento de búfer) como temporales (uso después de la liberación).

Además de las API descritas anteriormente, es posible que los usuarios experimentados deseen tener en cuenta lo siguiente:

• Configurar el registro de hardware PSTATE.TCO puede suprimir temporalmente la verificación de etiquetas ( ejemplo ). Por ejemplo, al copiar un rango de memoria con contenidos de etiquetas desconocidos o al abordar 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 el indicador SA_EXPOSE_TAGBITS al configurar el controlador de señal. Se recomienda que cualquier programa que establezca su propio controlador de señales y delega fallos desconocidos en el sistema haga lo mismo.

MTE en el núcleo

Para habilitar KASAN acelerado por MTE para el kernel, configure el kernel con CONFIG_KASAN=y , CONFIG_KASAN_HW_TAGS=y . Estas configuraciones están habilitadas de forma predeterminada en los kernels GKI, a partir de Android 12-5.10 .
Esto se puede controlar en el momento del arranque utilizando los siguientes argumentos de línea de comando:

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

Uso recomendado

Recomendamos encarecidamente utilizar el modo SYNC durante el inicio, el desarrollo y las pruebas. Esta opción debe habilitarse globalmente para todos los procesos que utilizan la variable de entorno o con el sistema de compilación . En este modo, los errores se detectan temprano en el proceso de desarrollo, el código base se estabiliza más rápido y se evita el costo de detectar errores más adelante en la producción.

Recomendamos encarecidamente utilizar el modo ASYNC en producción. Esto proporciona una herramienta de bajo costo 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 API en tiempo de ejecución para cambiar al modo SYNC y obtener un seguimiento de pila preciso de un conjunto de usuarios de muestra.

Recomendamos encarecidamente configurar el nivel MTE preferido específico de la CPU para el SoC. El modo Asymm normalmente tiene las mismas características de rendimiento que ASYNC y casi siempre es preferible a él. Los núcleos pequeños en orden suelen mostrar un rendimiento similar en los tres modos y se pueden configurar para preferir SYNC.

Los desarrolladores deben verificar la presencia de fallas verificando /data/tombstones , logcat o monitoreando la canalización DropboxManager del proveedor para detectar errores del usuario final. Para obtener más información sobre la depuración del código nativo de Android, consulte la información aquí .

Componentes de plataforma habilitados para MTE

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

• Demonios y utilidades de red (con la excepción de netd )
• Bluetooth, SecureElement, NFC HAL y aplicaciones del sistema
• demonio statsd
• system_server
• zygote64 (para permitir que las aplicaciones opten por usar MTE)

Estos objetivos fueron seleccionados en base a los siguientes criterios:

• Un proceso privilegiado (definido como un proceso que tiene acceso a algo que el dominio SELinux unprivileged_app no ​​tiene)
• Procesa entradas no confiables ( Regla de dos )
• Desaceleración del rendimiento aceptable (la desaceleración no crea latencia visible para el usuario)

Alentamos a los proveedores a habilitar MTE en producción para más componentes, siguiendo los criterios mencionados anteriormente. Durante el desarrollo, recomendamos probar estos componentes usando el modo SYNC, para detectar errores que se solucionen fácilmente y evaluar el impacto de ASYNC en su rendimiento.
En el futuro, Android planea ampliar la lista de componentes del sistema en los que está habilitado MTE, guiado por las características de rendimiento de los próximos diseños de hardware.