A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O ShadowCallStack (SCS) é um modo de instrumentação LLVM que protege contra
substituições de endereço de retorno (como estouro de buffer de pilha) salvando o endereço de retorno de uma
função em um ShadowCallStack alocado separadamente no
prólogo da função de funções não-folhas e carregando o endereço de retorno do
ShadowCallStack no epílogo da função. O endereço de retorno também é armazenado
na pilha regular para compatibilidade com desrolamentos, mas não é usado.
Isso garante que ataques que modificam o endereço de retorno na pilha regular
não tenham efeito no fluxo de controle do programa.
No aarch64, a instrumentação usa o registro x18
para fazer referência à ShadowCallStack, o que significa que as referências
à ShadowCallStack não precisam ser armazenadas na memória.
Isso permite implementar um ambiente de execução que evita expor
o endereço da ShadowCallStack para invasores que podem ler
memória arbitrária.
Implementação
O Android oferece suporte a ShadowCallStack para kernel e espaço do usuário.
Ativar a SCS para o kernel
Para ativar a ShadowCallStack para o kernel, adicione a seguinte linha ao
arquivo de configuração do kernel:
CONFIG_SHADOW_CALL_STACK=y
Ativar a SCS no espaço do usuário
Para ativar a ShadowCallStack em componentes do espaço do usuário, adicione as
linhas abaixo ao arquivo de modelo de um componente:
sanitize: {
scs: true
}
O SCS presume que o registro x18 está reservado para armazenar o endereço da
ShadowCallStack e não é usado para outras finalidades. Embora todas as bibliotecas
do sistema sejam compiladas para reservar o registro x18, isso pode ser
problemático se o SCS estiver ativado para componentes do espaço do usuário que interagem com
códigos legados em processo (por exemplo, bibliotecas que podem ser carregadas por apps
de terceiros), o que pode sobrescrever o registro x18. Portanto, só recomendamos
ativar o SCS em componentes independentes que não serão carregados em binários
legados.
Validação
Não há um teste CTS específico para o SCS. Em vez disso, verifique se os testes de CTS
são aprovados com e sem o SCS ativado para verificar se o SCS não está afetando o
dispositivo.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-27 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]