27 Mart 2025'ten itibaren AOSP'yi derlemek ve AOSP'ye katkıda bulunmak için aosp-main yerine android-latest-release kullanmanızı öneririz. Daha fazla bilgi için AOSP'de yapılan değişiklikler başlıklı makaleyi inceleyin.
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
ShadowCallStack (SCS), bir işlevin döndürdüğü adresi, yapraklı olmayan işlevlerin işlev prologunda ayrı olarak ayrılmış bir ShadowCallStack'e kaydederek ve döndürülen adresi işlev epilogunda ShadowCallStack'ten yükleyerek döndürülen adresin üzerine yazılmasına (ör. yığın arabelleği taşmaları) karşı koruma sağlayan bir LLVM enstrümantasyonu modudur. İade adresi, çözücüler ile uyumluluk için normal yığınta da depolanır ancak başka bir şekilde kullanılmaz.
Bu sayede, normal yığıntaki dönüş adresini değiştiren saldırıların program kontrol akışını etkilemesi önlenir.
aarch64'te, ShadowCallStack'e referans vermek için x18 kaydedicisi kullanılır. Bu, ShadowCallStack'e yapılan referansların bellekte saklanması gerekmediği anlamına gelir.
Bu sayede, ShadowCallStack'in adresini rastgele belleği okuyabilen saldırganlara göstermeyen bir çalışma zamanı uygulamak mümkün olur.
Uygulama
Android, hem çekirdek hem de kullanıcı alanı için ShadowCallStack'i destekler.
Çekirdek için SCS'yi etkinleştirme
ShadowCallStack'i çekirdek için etkinleştirmek üzere çekirdek yapılandırma dosyasına aşağıdaki satırı ekleyin:
CONFIG_SHADOW_CALL_STACK=y
Kullanıcı alanında SCS'yi etkinleştirme
ShadowCallStack'i kullanıcı alanı bileşenlerinde etkinleştirmek için aşağıdaki satırları bileşenin taslak dosyasına ekleyin:
sanitize: {
scs: true
}
SCS, x18 yazmaçının ShadowCallStack'in adresini depolamak için ayrıldığını ve başka amaçlar için kullanılmadığını varsayar. Tüm sistem kitaplıkları, x18 yazmacını ayırmak için derlenir. Ancak, işlemdeki eski kodla birlikte çalışan kullanıcı alanı bileşenleri (ör. üçüncü taraf uygulamaları tarafından yüklenebilecek kitaplıklar) için SCS etkinleştirilirse bu durum x18 yazmacını bozabilir ve soruna yol açabilir. Bu nedenle, SCS'yi yalnızca eski ikili dosyalara yüklenmeyecek olan kendi kendine yeten bileşenlerde etkinleştirmenizi öneririz.
Doğrulama
SCS için özel bir CTS testi yoktur. Bunun yerine, SCS'nin cihazı etkilemediğini doğrulamak için CTS testlerinin SCS etkinken ve devre dışıyken geçtiğinden emin olun.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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."]]
