קריסות של SIGSEGV עם קוד 9 (SEGV_MTESERR) או קוד 8 (SEGV_MTEAERR) הן שגיאות של תיוג זיכרון. תוסף תיוג זיכרון (MTE) הוא תכונת Armv9 שנתמכת ב-Android מגרסה 12 ואילך. MTE היא הטמעה בחומרה של זיכרון מתויג. הוא מספק הגנה מפורטת על הזיכרון לצורך זיהוי באגים של בטיחות זיכרון ומזעור שלהם.
ב-C/C++, אפשר להשתמש ב-pointer שמוחזר מהקריאה ל-malloc() או ל-operator new() או לפונקציות דומות רק כדי לגשת לזיכרון במסגרת ההקצאה הזו, ורק כל עוד ההקצאה פעילה (לא שוחררה או נמחקה). מערכת MTE משמשת ב-Android כדי לזהות הפרות של הכלל הזה, שמופיעות בדוחות הקריסה בתור בעיות מסוג 'Buffer Overflow'/'Buffer Underflow' ו'Use After Free'.
ל-MTE יש שני מצבים: סינכרוני (או 'sync') ואסינכרוני (או 'async'). הבדיקה הראשונה פועלת לאט יותר, אבל מספקת אבחון מדויק יותר. האפשרות השנייה פועלת מהר יותר, אבל היא יכולה לספק רק פרטים משוערים. נסביר על כל אחת מהן בנפרד, כי אמצעי האבחון שונים במקצת.
MTE במצב סינכרוני
במצב הסינכרוני ('sync') של MTE, מתרחשת קריסה של SIGSEGV עם קוד 9 (SEGV_MTESERR).
pid: 13935, tid: 13935, name: sanitizer-statu >>> sanitizer-status <<< uid: 0 tagged_addr_ctrl: 000000000007fff3 signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x800007ae92853a0 Cause: [MTE]: Use After Free, 0 bytes into a 32-byte allocation at 0x7ae92853a0 x0 0000007cd94227cc x1 0000007cd94227cc x2 ffffffffffffffd0 x3 0000007fe81919c0 x4 0000007fe8191a10 x5 0000000000000004 x6 0000005400000051 x7 0000008700000021 x8 0800007ae92853a0 x9 0000000000000000 x10 0000007ae9285000 x11 0000000000000030 x12 000000000000000d x13 0000007cd941c858 x14 0000000000000054 x15 0000000000000000 x16 0000007cd940c0c8 x17 0000007cd93a1030 x18 0000007cdcac6000 x19 0000007fe8191c78 x20 0000005800eee5c4 x21 0000007fe8191c90 x22 0000000000000002 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007fe8191b70 lr 0000005800eee0bc sp 0000007fe8191b60 pc 0000005800eee0c0 pst 0000000060001000 backtrace: #00 pc 00000000000010c0 /system/bin/sanitizer-status (test_crash_malloc_uaf()+40) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #01 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #02 pc 00000000000019cc /system/bin/sanitizer-status (main+1032) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #03 pc 00000000000487d8 /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+96) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) deallocated by thread 13935: #00 pc 000000000004643c /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::quarantineOrDeallocateChunk(scudo::Options, void*, scudo::Chunk::UnpackedHeader*, unsigned long)+688) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #01 pc 00000000000421e4 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::deallocate(void*, scudo::Chunk::Origin, unsigned long, unsigned long)+212) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #02 pc 00000000000010b8 /system/bin/sanitizer-status (test_crash_malloc_uaf()+32) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #03 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) allocated by thread 13935: #00 pc 0000000000042020 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::allocate(unsigned long, scudo::Chunk::Origin, unsigned long, bool)+1300) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #01 pc 0000000000042394 /apex/com.android.runtime/lib64/bionic/libc.so (scudo_malloc+36) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #02 pc 000000000003cc9c /apex/com.android.runtime/lib64/bionic/libc.so (malloc+36) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #03 pc 00000000000010ac /system/bin/sanitizer-status (test_crash_malloc_uaf()+20) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #04 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30)
כל דוחות הקריסה של MTE מכילים את נתוני ה-dump הרגילים של הרישום ואת מעקב ה-backtrace לנקודה שבה זוהתה הבעיה. השורה Cause: (סימה) של שגיאה ש-MTE זיהתה תכיל את הערך [MTE] כמו בדוגמה שלמעלה, יחד עם פרטים נוספים. במקרה הזה, סוג השגיאה הספציפי שזוהה היה 'שימוש לאחר שחרור', והחלק '0 bytes into a 32-byte allocation at 0x7ae92853a0' מציין את הגודל והכתובת של ההקצאה ואת הזזת האופרטור (offset) בהקצאה שניסינו לגשת אליה.
דוחות קריסה של MTE כוללים גם מעקב נתיב חזרה נוסף, ולא רק את המעקב מנקודת הזיהוי.
שגיאות מסוג 'שימוש לאחר שחרור' מוסיפות לדמפ הקריסה את הקטעים 'הקצאה מחדש על ידי' ו'הקצאה על ידי', שמציגים את מעקב ה-stack בזמן שהזיכרון הזה הוקצה מחדש (לפני שהשתמשו בו!) ובזמן שהוקצה בעבר. הם גם מציינים את הליבה שביצעה את ההקצאה או את ביטול ההקצאה. בכל שלוש הדוגמאות הפשוטות האלה, אשכול הזיהוי, אשכול ההקצאה ואשכול ביטול ההקצאה הם זהים, אבל במקרים מורכבים יותר בעולם האמיתי זה לא בהכרח נכון, וההבנה שהם שונים יכולה להיות רמז חשוב לזיהוי באג שקשור לפעילות בו-זמנית.
שגיאות מסוג 'Buffer Overflow' ו-'Buffer Underflow' מספקות רק עוד מסלול ב-stack של 'allocated by', כי מעצם הגדרתן עדיין לא בוצעה ביטול הקצאה שלהן (אחרת הן יופיעו בתור 'Use After Free'):
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 32-byte allocation at 0x7ae92853a0 [...] backtrace: [...] allocated by thread 13949:
שימו לב לשימוש במילה 'ימין' כאן: המשמעות היא שאנחנו מציינים כמה בייטים אחרי סוף ההקצאה הייתה הגישה השגויה. במקרה של זרימה לאחור (underflow), תופיע המילה 'שמאל', והערך יהיה מספר בייטים לפני תחילת ההקצאה.
כמה סיבות אפשריות
לפעמים דוחות SEGV_MTESERR מכילים את השורה הבאה:
Note: multiple potential causes for this crash were detected, listing them in decreasing order of likelihood.
המצב הזה קורה כשיש כמה מועמדים טובים למקור השגיאה, ולא ניתן לדעת מהו המקור בפועל. אנחנו מדפיסים עד 3 מועמדים כאלה בסדר משוער של הסבירות, ומשאירים את הניתוח למשתמש.
signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x400007b43063db5
backtrace:
[stack...]
Note: multiple potential causes for this crash were detected, listing them in decreasing order of probability.
Cause: [MTE]: Use After Free, 5 bytes into a 10-byte allocation at 0x7b43063db0
deallocated by thread 6663:
[stack...]
allocated by thread 6663:
[stack...]
Cause: [MTE]: Use After Free, 5 bytes into a 6-byte allocation at 0x7b43063db0
deallocated by thread 6663:
[stack...]
allocated by thread 6663:
[stack...]בדוגמה שלמעלה, זיהינו שתי הקצאות מהזמן האחרון באותה כתובת זיכרון, שיכולות להיות היעד המיועד של הגישה הלא חוקית לזיכרון. מצב כזה יכול לקרות כשמשתמשים מחדש בזיכרון פנוי – לדוגמה, אם יש רצף כמו new, free, new, free, new, free, access. ההקצאה העדכנית יותר תודפס קודם.
שיטות ניתוח מפורטות לזיהוי הסיבה
בשדה 'סיבה' של קריסה אמורה להופיע הקצאת הזיכרון שממנה נגזר במקור המצביע שדרכו בוצעה הגישה. לצערנו, לחומרה של MTE אין דרך לתרגם מצביע עם תג לא תואם להקצאה. כדי להסביר תאונה מסוג SEGV_MTESERR, מערכת Android מנתחת את הנתונים הבאים:
- כתובת השגיאה (כולל תג ההפניה).
- רשימה של הקצאות אשכול מהזמן האחרון עם מעקב סטאק ותגי זיכרון.
- הקצאות נוכחיות (פעילות) בקרבת מקום ותגי הזיכרון שלהן.
כל זיכרון שהוקצה לאחרונה בכתובת השגיאה, שבו תג הזיכרון תואם לתג כתובת השגיאה, הוא גורם פוטנציאלי לבעיה מסוג 'שימוש לאחר שחרור'.
כל זיכרון פעיל בקרבת מקום שבו תג הזיכרון תואם לתג של כתובת השגיאה הוא גורם פוטנציאלי ל'מלאי מוגזם בקטגוריה' (או 'מלאי חסר בקטגוריה').
הקצאות שנמצאות קרוב יותר לבעיה – במרחב או בזמן – נחשבות לסבירות יותר מאשר הקצאות שנמצאות רחוק.
מאחר שזיכרון שהוקצה מחדש משמש לעתים קרובות, ומספר ערכי התגים השונים קטן (פחות מ-16), לרוב מתגלים כמה גורמים אפשריים, ואין דרך למצוא את הגורם האמיתי באופן אוטומטי. זו הסיבה לכך שלפעמים בדוחות MTE מפורטות כמה סיבות אפשריות.
מומלץ שמפתח האפליקציה יבדוק את הגורמים האפשריים, החל מהסיבה הסבירה ביותר. לרוב קל לסנן סיבות לא קשורות על סמך נתיב הסטאק.
MTE במצב אסינכרוני
במצב האסינכרוני ('async') של MTE, מתרחשת קריסה של SIGSEGV עם קוד 8 (SEGV_MTEAERR).
שגיאות SEGV_MTEAERR לא מתרחשות באופן מיידי כשתוכנית מבצעת גישה לא חוקית לזיכרון. הבעיה מזוהה זמן קצר אחרי האירוע, והתוכנית מסתיימת במקום זאת בנקודה הזו. הנקודה הזו היא בדרך כלל קריאת המערכת הבאה, אבל היא יכולה להיות גם הפסקה של טיימר – בקיצור, כל מעבר ממרחב המשתמש לליבת המעבד.
כשמתרחשות שגיאות SEGV_MTEAERR, כתובת הזיכרון לא נשמרת (היא תמיד מוצגת כ-"-------"). ה-backtrace תואם לרגע שבו זוהתה התנאי (כלומר בקריאה הבאה למערכת או במעבר הבא להקשר), ולא לרגע שבו בוצעה הגישה הלא חוקית.
כלומר, בדרך כלל לא רלוונטי לבדוק את ה-backtrace 'הראשי' בתאונה אסינכררונית של MTE. לכן קשה הרבה יותר לנפות באגים כשהקריסה מתרחשת במצב אסינכרוני מאשר במצב סינכרוני. הדרך הטובה ביותר להבין אותן היא כעדות לקיומה של באג בזיכרון בקוד הסמוך בשרשור הנתון. יומנים שבתחתית קובץ tombstone עשויים לספק רמז לגבי מה שקרה בפועל. אחרת, מומלץ לשחזר את השגיאה במצב סנכרון ולהשתמש באבחון הטוב יותר שמצב הסנכרון מספק.
נושאים מתקדמים
מתחת לפני השטח, תיוג הזיכרון פועל על ידי הקצאת ערך תג אקראי של 4 ביט (0..15) לכל הקצאה של אשכול. הערך הזה מאוחסן באזור מטא-נתונים מיוחד שתואם לזיכרון האוסף שהוקצה. אותו ערך מוקצה לבית המשמעותי ביותר של מצביע האשפה שמוחזרים מפונקציות כמו malloc() או operator new().
כשבדיקת התגים מופעלת בתהליך, המעבד משווה באופן אוטומטי את הבית העליון של המצביע לתג הזיכרון בכל גישה לזיכרון. אם התגים לא תואמים, המעבד מאותת על שגיאה שמובילה לקריסה.
בגלל המספר המוגבל של ערכי התגים האפשריים, הגישה הזו היא סטטיסטית. לכל מיקום זיכרון שאסור לגשת אליו באמצעות מצביע נתון – למשל מחוץ למגבלות או אחרי ביטול ההקצאה ('מצביע תלוי') – סביר להניח שיהיה ערך תג שונה, וזה עלול לגרום לקריסה. יש סיכוי של כ-7% שלא תזוהה אף הופעה של באג. מאחר שערכי התגים מוקצים באופן אקראי, יש סיכוי עצמאי של כ-93% לזהות את הבאג בפעם הבאה שהוא יקרה.
ערכי התגים מופיעים בשדה fault address וגם ב-dump של הרישום, כפי שמודגש בהמשך. אפשר להשתמש בקטע הזה כדי לבדוק שהתגים מוגדרים בצורה תקינה, וגם כדי לראות הקצאות זיכרון אחרות בסביבה עם אותו ערך תג, כי הן יכולות להיות סיבות אפשריות לשגיאה מעבר לאלה שמפורטות בדוח. אנחנו צופים שהתכונה הזו תהיה שימושית בעיקר לאנשים שעובדים על הטמעת MTE עצמו או על רכיבי מערכת אחרים ברמה נמוכה, ולא למפתחים.
signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x0800007ae92853a0 Cause: [MTE]: Use After Free, 0 bytes into a 32-byte allocation at 0x7ae92853a0 x0 0000007cd94227cc x1 0000007cd94227cc x2 ffffffffffffffd0 x3 0000007fe81919c0 x4 0000007fe8191a10 x5 0000000000000004 x6 0000005400000051 x7 0000008700000021 x8 0800007ae92853a0 x9 0000000000000000 x10 0000007ae9285000 x11 0000000000000030 x12 000000000000000d x13 0000007cd941c858 x14 0000000000000054 x15 0000000000000000 x16 0000007cd940c0c8 x17 0000007cd93a1030 x18 0000007cdcac6000 x19 0000007fe8191c78 x20 0000005800eee5c4 x21 0000007fe8191c90 x22 0000000000000002 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007fe8191b70 lr 0000005800eee0bc sp 0000007fe8191b60 pc 0000005800eee0c0 pst 0000000060001000
בקטע 'תגי זיכרון' המיוחד שמופיע בדוח הקריסה מוצגים תגי זיכרון סביב כתובת השגיאה. בדוגמה הבאה, תג הסמן '4' לא התאים לתג הזיכרון 'a'.
Memory tags around the fault address (0x0400007b43063db5), one tag per 16 bytes: 0x7b43063500: 0 f 0 2 0 f 0 a 0 7 0 8 0 7 0 e 0x7b43063600: 0 9 0 8 0 5 0 e 0 f 0 c 0 f 0 4 0x7b43063700: 0 b 0 c 0 b 0 2 0 1 0 4 0 7 0 8 0x7b43063800: 0 b 0 c 0 3 0 a 0 3 0 6 0 b 0 a 0x7b43063900: 0 3 0 4 0 f 0 c 0 3 0 e 0 0 0 c 0x7b43063a00: 0 3 0 2 0 1 0 8 0 9 0 4 0 3 0 4 0x7b43063b00: 0 5 0 2 0 5 0 a 0 d 0 6 0 d 0 2 0x7b43063c00: 0 3 0 e 0 f 0 a 0 0 0 0 0 0 0 4 =>0x7b43063d00: 0 0 0 a 0 0 0 e 0 d 0 [a] 0 f 0 e 0x7b43063e00: 0 7 0 c 0 9 0 a 0 d 0 2 0 0 0 c 0x7b43063f00: 0 0 0 6 0 b 0 8 0 3 0 0 0 5 0 e 0x7b43064000: 0 d 0 2 0 7 0 a 0 7 0 a 0 d 0 8 0x7b43064100: 0 b 0 2 0 b 0 4 0 1 0 6 0 d 0 4 0x7b43064200: 0 1 0 6 0 f 0 2 0 f 0 6 0 5 0 c 0x7b43064300: 0 1 0 4 0 d 0 6 0 f 0 e 0 1 0 8 0x7b43064400: 0 f 0 4 0 3 0 2 0 1 0 2 0 5 0 6
בקטעים של סטטוס 'קבורה' שמוצגים בהם תוכן הזיכרון סביב כל ערכי הרישום מוצגים גם ערכי התגים שלהם.
memory near x10 ([anon:scudo:primary]): 0000007b4304a000 7e82000000008101 000003e9ce8b53a0 .......~.S...... 0700007b4304a010 0000200000006001 0000000000000000 .`... .......... 0000007b4304a020 7c03000000010101 000003e97c61071e .......|..a|.... 0200007b4304a030 0c00007b4304a270 0000007ddc4fedf8 p..C{.....O.}... 0000007b4304a040 84e6000000008101 000003e906f7a9da ................ 0300007b4304a050 ffffffff00000042 0000000000000000 B............... 0000007b4304a060 8667000000010101 000003e9ea858f9e ......g......... 0400007b4304a070 0000000100000001 0000000200000002 ................ 0000007b4304a080 f5f8000000010101 000003e98a13108b ................ 0300007b4304a090 0000007dd327c420 0600007b4304a2b0 .'.}......C{... 0000007b4304a0a0 88ca000000010101 000003e93e5e5ac5 .........Z^>.... 0a00007b4304a0b0 0000007dcc4bc500 0300007b7304cb10 ..K.}......s{... 0000007b4304a0c0 0f9c000000010101 000003e9e1602280 ........."`..... 0900007b4304a0d0 0000007dd327c780 0700007b7304e2d0 ..'.}......s{... 0000007b4304a0e0 0d1d000000008101 000003e906083603 .........6...... 0a00007b4304a0f0 0000007dd327c3b8 0000000000000000 ..'.}...........