A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
ShadowCallStack (SCS) è una modalità di strumentazione LLVM che protegge dalle sovrascritture dell'indirizzo di ritorno (come gli overflow del buffer dello stack) salvando l'indirizzo di ritorno di una funzione in un ShadowCallStack allocato separatamente nel prologo della funzione delle funzioni non a foglia e caricando l'indirizzo di ritorno da ShadowCallStack nell'epilogo della funzione. L'indirizzo di ritorno viene memorizzato anche
sull'apposita pila per la compatibilità con gli unwinder, ma altrimenti non viene utilizzato.
In questo modo, gli attacchi che modificano l'indirizzo di ritorno nello stack normale
non hanno alcun effetto sul flusso di controllo del programma.
Su aarch64, la strumentazione utilizza il registro x18
per fare riferimento a ShadowCallStack, il che significa che i riferimenti
a ShadowCallStack non devono essere memorizzati in memoria.
In questo modo è possibile implementare un runtime che evita di esporre
l'indirizzo di ShadowCallStack ad attaccanti in grado di leggere
memoria arbitraria.
Implementazione
Android supporta ShadowCallStack sia per il kernel che per lo spazio utente.
Attivare la crittografia lato client per il kernel
Per attivare ShadowCallStack per il kernel, aggiungi la seguente riga al
file di configurazione del kernel:
CONFIG_SHADOW_CALL_STACK=y
Attivare SCS nello spazio utente
Per attivare ShadowCallStack nei componenti dello spazio utente, aggiungi le righe seguenti al file blueprint di un componente:
sanitize: {
scs: true
}
SCS presuppone che il registro x18 sia riservato per memorizzare l'indirizzo di ShadowCallStack e non venga utilizzato per altri scopi. Sebbene tutte le librerie di sistema siano compilate per riservare il registro x18, questo è potenzialmente problematico se SCS è attivato per i componenti dello spazio utente che interoperano con il codice legacy in-process (ad esempio le librerie che potrebbero essere caricate da app di terze parti), che potrebbero sovrascrivere il registro x18. Pertanto, consigliamo di attivare SCS solo nei componenti autocontenuti che non verranno caricati nei file binari legacy.
Convalida
Non sono disponibili test CTS specifici per SCS. Assicurati invece che i test CTS superino con e senza l'SCS abilitato per verificare che l'SCS non influisca sul dispositivo.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
