A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
ShadowCallStack (SCS) es un modo de instrumentación de LLVM que protege contra las anulaciones de la dirección de retorno (como los desbordamientos del búfer de pila) guardando la dirección de retorno de una función en una ShadowCallStack asignada por separado en el prólogo de la función de las funciones no hoja y cargando la dirección de retorno desde la ShadowCallStack en el epílogo de la función. La dirección de devolución también se almacena en la pila normal para la compatibilidad con los desenrolladores, pero no se usa.
Esto garantiza que los ataques que modifican la dirección de retorno en la pila normal no tengan efecto en el flujo de control del programa.
En aarch64, la instrumentación usa el registro x18 para hacer referencia a ShadowCallStack, lo que significa que las referencias a ShadowCallStack no tienen que almacenarse en la memoria.
Esto permite implementar un entorno de ejecución que evita exponer la dirección de ShadowCallStack a atacantes que pueden leer memoria arbitraria.
Implementación
Android admite ShadowCallStack para el kernel y el espacio del usuario.
Habilita SCS para el kernel
Para habilitar ShadowCallStack para el kernel, agrega la siguiente línea al archivo de configuración del kernel:
CONFIG_SHADOW_CALL_STACK=y
Habilita SCS en el espacio de usuario
Para habilitar ShadowCallStack en componentes de espacio de usuario, agrega las siguientes líneas al archivo de blueprint de un componente:
sanitize: {
scs: true
}
SCS supone 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 puede ser problemático si el SCS está habilitado para componentes del espacio de usuario que interoperan con código heredado en proceso (por ejemplo, bibliotecas que podrían cargar apps de terceros), lo que podría anular el registro x18. Por lo tanto, solo recomendamos habilitar SCS en componentes independientes que no se carguen en objetos binarios heredados.
Validación
No hay pruebas de CTS específicas para SCS. En su lugar, asegúrate de que las pruebas de CTS superen con y sin SCS habilitado para verificar que SCS no afecte al dispositivo.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-27 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-07-27 (UTC)"],[],[],null,["# ShadowCallStack\n\n| **Note:** ShadowCallStack is only implemented for aarch64.\n\nShadowCallStack (SCS) is an [LLVM instrumentation](https://clang.llvm.org/docs/ShadowCallStack.html) mode that protects against\nreturn address overwrites (like stack buffer overflows) by saving a function's\nreturn address to a separately allocated **ShadowCallStack** in\nthe function prolog of nonleaf functions and loading the return address from\nthe ShadowCallStack in the function epilog. The return address is also stored\non the regular stack for compatibility with unwinders, but is otherwise unused.\nThis ensures that attacks that modify the return address on the regular stack\nhave no effect on program control flow.\n\nOn aarch64, the instrumentation makes use of the `x18`\nregister to reference the ShadowCallStack, meaning that references\nto the ShadowCallStack don't have to be stored in memory.\nThis makes it possible to implement a runtime that avoids exposing\nthe address of the ShadowCallStack to attackers that can read\narbitrary memory.\n\nImplementation\n--------------\n\nAndroid supports ShadowCallStack for both kernel and userspace.\n\n### Enable SCS for the kernel\n\nTo enable ShadowCallStack for the kernel, add the following line to the\nkernel config file: \n\n```\nCONFIG_SHADOW_CALL_STACK=y\n```\n\n### Enable SCS in userspace\n\nTo enable ShadowCallStack in userspace components, add the\nfollowing lines to a component's blueprint file: \n\n```\nsanitize: {\n scs: true\n}\n```\n\nSCS assumes that the `x18` register is reserved to store the address of the\nShadowCallStack, and isn't used for any other purposes. While all system\nlibraries are compiled to reserve the `x18` register, this is potentially\nproblematic if SCS is enabled for userspace components that interoperate with\nin-process legacy code (for example, libraries that could be loaded by third-party\napps), which may clobber the `x18` register. As such, we only recommend\nenabling SCS in self-contained components that won't be loaded into legacy\nbinaries.\n\nValidation\n----------\n\nThere are no CTS test specifically for SCS. Instead, make sure that CTS tests\npass with and without SCS enabled to verify that SCS isn't impacting the\ndevice."]]
