Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release thay vì aosp-main để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
ShadowCallStack (SCS) là chế độ thiết bị đo lường LLVM giúp bảo vệ khỏi việc ghi đè địa chỉ trả về (chẳng hạn như tràn vùng đệm ngăn xếp) bằng cách lưu địa chỉ trả về của hàm vào một ShadowCallStack được phân bổ riêng trong phần mở đầu hàm của các hàm không phải lá và tải địa chỉ trả về từ ShadowCallStack trong phần kết thúc hàm. Địa chỉ trả về cũng được lưu trữ trên ngăn xếp thông thường để tương thích với trình gỡ bỏ, nhưng không được sử dụng.
Điều này đảm bảo rằng các cuộc tấn công sửa đổi địa chỉ trả về trên ngăn xếp thông thường không ảnh hưởng đến luồng kiểm soát chương trình.
Trên aarch64, hoạt động đo lường sử dụng thanh ghi x18 để tham chiếu đến ShadowCallStack, nghĩa là các tệp tham chiếu đến ShadowCallStack không cần được lưu trữ trong bộ nhớ.
Điều này giúp bạn có thể triển khai một môi trường thời gian chạy tránh tiết lộ địa chỉ của ShadowCallStack cho những kẻ tấn công có thể đọc bộ nhớ tuỳ ý.
Triển khai
Android hỗ trợ ShadowCallStack cho cả nhân hệ điều hành và không gian người dùng.
Bật SCS cho nhân
Để bật ShadowCallStack cho nhân, hãy thêm dòng sau vào tệp cấu hình nhân:
CONFIG_SHADOW_CALL_STACK=y
Bật SCS trong không gian người dùng
Để bật ShadowCallStack trong các thành phần không gian người dùng, hãy thêm các dòng sau vào tệp bản thiết kế của thành phần:
sanitize: {
scs: true
}
SCS giả định rằng thanh ghi x18 được dành để lưu trữ địa chỉ của ShadowCallStack và không được dùng cho bất kỳ mục đích nào khác. Mặc dù tất cả thư viện hệ thống đều được biên dịch để đặt trước thanh ghi x18, nhưng điều này có thể gây ra sự cố nếu bạn bật SCS cho các thành phần không gian người dùng tương tác với mã cũ trong quá trình (ví dụ: các thư viện có thể được tải bằng ứng dụng bên thứ ba), điều này có thể làm hỏng thanh ghi x18. Do đó, bạn chỉ nên bật SCS trong các thành phần độc lập sẽ không được tải vào tệp nhị phân cũ.
Xác nhận kết quả
Không có quy trình kiểm thử CTS dành riêng cho SCS. Thay vào đó, hãy đảm bảo rằng các kiểm thử CTS đạt yêu cầu khi bật và không bật SCS để xác minh rằng SCS không ảnh hưởng đến thiết bị.
Nội dung và mã mẫu trên trang này phải tuân thủ các giấy phép như mô tả trong phần Giấy phép nội dung. Java và OpenJDK là nhãn hiệu hoặc nhãn hiệu đã đăng ký của Oracle và/hoặc đơn vị liên kết của Oracle.
Cập nhật lần gần đây nhất: 2025-07-27 UTC.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 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."]]
