Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

ShadowCallStack

ShadowCallStack (SCS) es un modo de instrumentación LLVM que protege contra sobrescrituras de direcciones de retorno (como desbordamientos de búfer de pila) al guardar la dirección de retorno de una función en un ShadowCallStack asignado por separado en el prólogo de funciones de funciones no hoja y cargar la dirección de retorno de ShadowCallStack en la función epílogo. La dirección de retorno también se almacena en la pila normal para que sea compatible con los desenrolladores, pero por lo demás no se utiliza. Esto asegura que los ataques que modifiquen la dirección de retorno en la pila normal no tengan ningún efecto en el flujo de control del programa.

En aarch64, la instrumentación hace uso del registro x18 para hacer referencia a ShadowCallStack, lo que significa que las referencias a ShadowCallStack no tienen que almacenarse en la memoria. Esto hace posible implementar un tiempo de ejecución que evita exponer la dirección de ShadowCallStack a atacantes que pueden leer memoria arbitraria.

Implementación

Android es compatible con ShadowCallStack tanto para el kernel como para el espacio de usuario.

Habilitando SCS para el kernel

Para habilitar ShadowCallStack para el kernel, agregue la siguiente línea al archivo de configuración del kernel:

CONFIG_SHADOW_CALL_STACK=y

Habilitación de SCS en el espacio de usuario

Para habilitar ShadowCallStack en los componentes del espacio de usuario, agregue las siguientes líneas al archivo de plano de un componente:

sanitize: {
  scs: true
}

SCS asume que el registro x18 está reservado para almacenar la dirección de ShadowCallStack y no se usa para ningún otro propósito. Si bien todas las bibliotecas del sistema se compilan para reservar el registro x18 , esto es potencialmente problemático si SCS está habilitado para los componentes del espacio de usuario que interoperan con el código heredado en proceso (por ejemplo, bibliotecas que podrían ser cargadas por aplicaciones de terceros), lo que puede fallar el registro x18 . Como tal, solo recomendamos habilitar SCS en componentes autónomos que no se cargarán en binarios heredados.

Validación

No hay una prueba CTS específicamente para SCS. En su lugar, asegúrese de que las pruebas CTS pasen con y sin SCS habilitado para verificar que SCS no esté afectando el dispositivo.