À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
ShadowCallStack (SCS) est un mode d'instrumentation LLVM qui protège contre les écrasements d'adresse de retour (comme les débordements de tampon de pile) en enregistrant l'adresse de retour d'une fonction dans un ShadowCallStack alloué séparément dans le prolog de fonction des fonctions non feuilles et en chargeant l'adresse de retour à partir de ShadowCallStack dans l'épilogue de la fonction. L'adresse de retour est également stockée sur la pile régulière pour assurer la compatibilité avec les outils de débogage, mais elle n'est pas utilisée.
Cela garantit que les attaques qui modifient l'adresse de retour sur la pile régulière n'ont aucun effet sur le flux de contrôle du programme.
Sur aarch64, l'instrumentation utilise le registre x18 pour référencer ShadowCallStack, ce qui signifie que les références à ShadowCallStack n'ont pas besoin d'être stockées en mémoire.
Cela permet d'implémenter un environnement d'exécution qui évite d'exposer l'adresse de ShadowCallStack aux pirates informatiques pouvant lire une mémoire arbitraire.
Implémentation
Android est compatible avec ShadowCallStack pour le noyau et l'espace utilisateur.
Activer le SCS pour le kernel
Pour activer ShadowCallStack pour le noyau, ajoutez la ligne suivante au fichier de configuration du noyau:
CONFIG_SHADOW_CALL_STACK=y
Activer le SCS dans l'espace utilisateur
Pour activer ShadowCallStack dans les composants de l'espace utilisateur, ajoutez les lignes suivantes au fichier de modèle d'un composant:
sanitize: {
scs: true
}
SCS suppose que le registre x18 est réservé au stockage de l'adresse de ShadowCallStack et qu'il n'est utilisé à aucune autre fin. Bien que toutes les bibliothèques système soient compilées pour réserver le registre x18, cela peut poser problème si le SCS est activé pour les composants de l'espace utilisateur qui interagissent avec le code ancien en cours de traitement (par exemple, les bibliothèques pouvant être chargées par des applications tierces), ce qui peut écraser le registre x18. Par conséquent, nous vous recommandons de n'activer le SCS que dans les composants autonomes qui ne seront pas chargés dans les binaires existants.
Validation
Il n'existe aucun test CTS spécifique au SCS. Assurez-vous plutôt que les tests CTS sont réussis avec et sans SCS activé pour vérifier que SCS n'a aucun impact sur l'appareil.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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."]]
