Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release, bukan aosp-main, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
ShadowCallStack (SCS) adalah mode instrumentasi LLVM yang melindungi terhadap
penulisan ulang alamat return (seperti overflow buffer stack) dengan menyimpan alamat
return fungsi ke ShadowCallStack yang dialokasikan secara terpisah di
prolog fungsi dari fungsi non-leaf dan memuat alamat return dari
ShadowCallStack di epilog fungsi. Alamat return juga disimpan
di stack reguler untuk kompatibilitas dengan unwinder, tetapi tidak digunakan.
Hal ini memastikan bahwa serangan yang memodifikasi alamat return pada stack reguler
tidak berpengaruh pada alur kontrol program.
Di aarch64, instrumentasi menggunakan register x18
untuk mereferensikan ShadowCallStack, yang berarti bahwa referensi
ke ShadowCallStack tidak harus disimpan dalam memori.
Hal ini memungkinkan penerapan runtime yang menghindari eksposur
alamat ShadowCallStack kepada penyerang yang dapat membaca
memori arbitrer.
Implementasi
Android mendukung ShadowCallStack untuk kernel dan ruang pengguna.
Mengaktifkan SCS untuk kernel
Untuk mengaktifkan ShadowCallStack untuk kernel, tambahkan baris berikut ke
file konfigurasi kernel:
CONFIG_SHADOW_CALL_STACK=y
Mengaktifkan SCS di ruang pengguna
Untuk mengaktifkan ShadowCallStack di komponen ruang pengguna, tambahkan
baris berikut ke file blueprint komponen:
sanitize: {
scs: true
}
SCS mengasumsikan bahwa register x18 dicadangkan untuk menyimpan alamat
ShadowCallStack, dan tidak digunakan untuk tujuan lain apa pun. Meskipun semua library
sistem dikompilasi untuk mencadangkan register x18, hal ini berpotensi
bermasalah jika SCS diaktifkan untuk komponen ruang pengguna yang berinteraksi dengan
kode lama dalam proses (misalnya, library yang dapat dimuat oleh aplikasi
pihak ketiga), yang dapat menghapus register x18. Oleh karena itu, sebaiknya
aktifkan SCS dalam komponen mandiri yang tidak akan dimuat ke biner
lama.
Validasi
Tidak ada pengujian CTS khusus untuk SCS. Sebagai gantinya, pastikan pengujian CTS
lulus dengan dan tanpa SCS diaktifkan untuk memverifikasi bahwa SCS tidak memengaruhi
perangkat.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-27 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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."]]
