קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
ShadowCallStack (SCS) הוא מצב של הוספת רכיבים ל-LLVM שמגן מפני מחיקה של כתובת ההחזרה (כמו זליגה של מאגר ה-stack) על ידי שמירת כתובת ההחזרה של פונקציה ב-ShadowCallStack שהוקצה בנפרד בתחילת הפונקציה של פונקציות שאינן פונקציות עלים, וטעינה של כתובת ההחזרה מ-ShadowCallStack בסוף הפונקציה. כתובת ההחזרה מאוחסנת גם בסטאק הרגיל לצורך תאימות ל-unwinders, אבל לא נעשה בה שימוש אחר.
כך מתקפות שמשתנות את כתובת ההחזרה בסטאק הרגיל לא משפיעות על תהליך הבקרה של התוכנית.
ב-aarch64, התכונה משתמשת ברשומה x18 כדי להפנות ל-ShadowCallStack, כלומר אין צורך לאחסן את ההפניות ל-ShadowCallStack בזיכרון.
כך אפשר להטמיע סביבת זמן ריצה שלא חושפת את הכתובת של ShadowCallStack לתוקפים שיכולים לקרוא זיכרון שרירותי.
הטמעה
ב-Android יש תמיכה ב-ShadowCallStack גם בליבה וגם במרחב המשתמש.
הפעלת SCS בליבה
כדי להפעיל את ShadowCallStack בליבה, מוסיפים את השורה הבאה לקובץ התצורה של הליבה:
CONFIG_SHADOW_CALL_STACK=y
הפעלת SCS במרחב המשתמש
כדי להפעיל את ShadowCallStack ברכיבים של מרחב המשתמש, מוסיפים את השורות הבאות לקובץ התוכנית של הרכיב:
sanitize: {
scs: true
}
ב-SCS מניחים שהרשם x18 שמור לאחסון הכתובת של ShadowCallStack, ולא משמש למטרות אחרות. כל ספריות המערכת מתורגמות כדי להקצות את המרשם x18, אבל יכול להיות שיהיו בעיות אם SCS מופעל לרכיבים במרחב המשתמש שמבצעים פעולות שיתוף פעולה עם קוד מדור קודם בתהליך (לדוגמה, ספריות שאפשר לטעון על ידי אפליקציות של צד שלישי), שעלול למחוק את המרשם x18. לכן, מומלץ להפעיל את SCS רק ברכיבים עצמאיים שלא יוטמעו בקובצי בינארי מדור קודם.
אימות
אין בדיקת CTS ספציפית ל-SCS. במקום זאת, צריך לוודא שבדיקות CTS עוברות גם עם SCS מופעל וגם בלי SCS מופעל, כדי לוודא ש-SCS לא משפיע על המכשיר.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-27 (שעון UTC).
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 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."]]
