קריסות SIGSEGV עם קוד 9 (SEGV_MTESERR) או קוד 8 (SEGV_MTEAERR) הן תקלות בתיוג זיכרון. הרחבת תיוג זיכרון (MTE) היא תכונת Armv9 הנתמכת באנדרואיד 12 ואילך. MTE הוא יישום חומרה של זיכרון מתויג. הוא מספק הגנת זיכרון עדינה לזיהוי והפחתה של באגי בטיחות בזיכרון .
ב-C/C++, מצביע שהוחזר מקריאה ל- malloc() או לפונקציות new() למפעיל או דומות ניתן להשתמש רק כדי לגשת לזיכרון בתוך גבולות ההקצאה, ורק בזמן שההקצאה קיימת (לא משוחרר או delete-ed). משתמשים ב-MTE באנדרואיד כדי לזהות הפרות של כלל זה, המכונה בדוחות הקריסה כבעיות "הצפת מאגר"/"הפרת מאגר" ו"השתמש לאחר חינם".
ל-MTE שני מצבים: סינכרוני (או "סינכרוני") ואסינכרוני (או "אסינכרוני"). הראשון פועל לאט יותר אך מספק אבחון מדויק יותר. האחרון פועל מהר יותר, אבל יכול לתת רק פרטים משוערים. נסקור את שניהם בנפרד, מכיוון שהאבחון מעט שונה.
מצב סינכרוני MTE
במצב הסינכרוני ("סינכרון") של 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 מכילים את ה-Register dump ו-backtrace הרגילים לנקודה שבה זוהתה הבעיה. השורה "סיבה:" עבור שגיאה שזוהתה על ידי MTE תכיל את "[MTE]" כמו בדוגמה למעלה, יחד עם פרטים נוספים. במקרה זה, הסוג הספציפי של שגיאה שזוהה היה "השתמש לאחר פנוי", וה-"0 בתים להקצאה של 32 בתים ב-0x7ae92853a0" אומר לנו את הגודל והכתובת של ההקצאה, ואת הקיזוז להקצאה שאנו ניסה לגשת.
דוחות התרסקות של MTE כוללים גם עקבות נוספות לאחור, לא רק את זה מנקודת הזיהוי.
שגיאות "Use After Free" מוסיפות קטעים "מבוטל על ידי" ו-"מוקצים על ידי" למזבלה של התרסקות, ומציגות את עקבות המחסנית בזמן ביטול ההקצאה של זיכרון זה (לפני השימוש בו!), ואת הזמן שבו הוקצה קודם לכן. אלה גם אומרים לך איזה שרשור ביצע את ההקצאה/ביטול ההקצאה. כל שלושת השרשור הזיהוי, ההקצאה וההקצאה של השרשור וביטול ההקצאה זהים בדוגמה הפשוטה הזו, אבל במקרים מורכבים יותר בעולם האמיתי זה לא בהכרח נכון, והידיעה שהם שונים יכולה להיות רמז חשוב במציאת מקבילות -באג הקשור.
שגיאות "הצפת חוצץ" ו-"החצץ תת" מספקות רק רצועת מחסנית נוספת "הוקצתה על ידי", מכיוון שבהגדרה הן לא הוקצו עדיין (או שהן יופיעו כ"שימוש לאחר חינם"):
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 32-byte allocation at 0x7ae92853a0 [...] backtrace: [...] allocated by thread 13949:
שימו לב לשימוש במילה "נכון" כאן: זה אומר שאנחנו אומרים לכם כמה בתים אחרי סוף ההקצאה הייתה הגישה השגויה; תת-זרם יאמר "שמאל", ויהיה מספר בתים לפני תחילת ההקצאה.
סיבות אפשריות מרובות
לפעמים דוחות 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...]בדוגמה שלמעלה, זיהינו שתי הקצאות אחרונות באותה כתובת זיכרון שיכלו להיות היעד המיועד לגישה לא חוקית לזיכרון. זה יכול לקרות כאשר הקצאות משתמשות מחדש בזיכרון פנוי - לדוגמה, אם יש לך רצף כגון חדש, חינם, חדש, חינם, חדש, חינם, גישה. ההקצאה העדכנית יותר מודפסת תחילה.
היוריסטיקה מפורטת לקביעת סיבה
ה"סיבה" לקריסה צריכה להראות את הקצאת הזיכרון שממנה נגזר במקור המצביע שניגש אליו. לרוע המזל, לחומרת MTE אין דרך לתרגם מצביע עם תג לא תואם להקצאה. כדי להסביר קריסת SEGV_MTESERR, אנדרואיד מנתחת את הנתונים הבאים:
- כתובת התקלה (כולל תג המצביע).
- רשימה של הקצאות ערימה אחרונות עם עקבות מחסנית ותגי זיכרון.
- הקצאות נוכחיות (חיות) בקרבת מקום ותגי הזיכרון שלהן.
כל זיכרון שהוקצה לאחרונה בכתובת התקלה שבה תג הזיכרון תואם לתג כתובת התקלה הוא גורם פוטנציאלי ל-"Use After Free".
כל זיכרון חי בקרבת מקום שבו תג הזיכרון תואם לתג כתובת התקלה הוא גורם פוטנציאלי ל-"Buffer Overflow" (או "Buffer Underflow").
הקצאות הקרובות יותר לתקלה - או בזמן או במרחב - נחשבות סבירות יותר מאלו הרחוקות.
מכיוון שלעתים קרובות נעשה שימוש חוזר בזיכרון שהוקצה, ומספר ערכי התג השונים קטן (פחות מ-16), אין זה נדיר למצוא מספר מועמדים סבירים, ואין דרך למצוא באופן אוטומטי את הסיבה האמיתית. זו הסיבה שלפעמים דוחות MTE מפרטים מספר סיבות אפשריות.
מומלץ למפתח האפליקציה לבחון את הסיבות הפוטנציאליות החל מהסיבה הסבירה ביותר. לעתים קרובות קל לסנן גורמים לא קשורים בהתבסס על מעקב הערימה.
מצב אסינכרוני MTE
במצב האסינכרוני ("אסינכרוני") של MTE, SIGSEGV קורס עם קוד 8 (SEGV_MTEAERR).
תקלות SEGV_MTEAERR אינן קורות מיד כאשר תוכנית מבצעת גישה לא חוקית לזיכרון. הבעיה מזוהה זמן קצר לאחר האירוע, והתוכנית מופסקת בשלב זה במקום זאת. נקודה זו היא בדרך כלל קריאת המערכת הבאה, אבל היא יכולה להיות גם פסיקת טיימר - בקיצור, כל מעבר ממרחב משתמש לקרנל.
תקלות SEGV_MTEAERR אינן שומרות על כתובת הזיכרון (היא תמיד מוצגת בתור "-------"). העקיבה האחורית תואמת לרגע שבו התגלה המצב (כלומר בשיחת המערכת הבאה או מתג הקשר אחר), ולא כאשר בוצעה הגישה הלא חוקית.
המשמעות היא שהעקיבה ה"ראשית" לאחור בהתרסקות MTE אסינכרונית בדרך כלל אינה רלוונטית . לפיכך, תקלות במצב אסינכרון קשים הרבה יותר לאיפוי מאשר כשלים במצב סנכרון. הכי טוב להבין אותם כמראים את קיומו של באג זיכרון בקוד הסמוך בשרשור הנתון. יומנים בתחתית קובץ המצבה עשויים לספק רמז למה שקרה בפועל. אחרת, דרך הפעולה המומלצת היא לשחזר את השגיאה במצב סנכרון ולהשתמש באבחון טוב יותר שמצב הסנכרון מספק!
נושאים מתקדמים
מתחת למכסה המנוע, תיוג זיכרון פועל על ידי הקצאת ערך אקראי של 4 סיביות (0..15) לכל הקצאת ערימה. ערך זה מאוחסן באזור מטא נתונים מיוחד המתאים לזיכרון הערימה שהוקצה. אותו ערך מוקצה לבייט המשמעותי ביותר של מצביע הערימה המוחזר מפונקציות כגון malloc() או אופרטור new().
כאשר בדיקת תגים מופעלת בתהליך, ה-CPU משווה אוטומטית את הבת העליון של המצביע עם תג הזיכרון עבור כל גישה לזיכרון. אם התגים אינם תואמים, המעבד מאותת על שגיאה שמובילה להתרסקות.
בגלל המספר המצומצם של ערכי תג אפשריים, גישה זו היא הסתברותית. כל מיקום זיכרון שאסור לגשת אליו עם מצביע נתון - כגון מחוץ לתחום, או לאחר ביטול הקצאה ("מצביע מתנדנד") - צפוי להיות בעל ערך תג שונה, ולגרום לקריסה. יש סיכוי של ~7% לא לזהות אירוע בודד של באג. מכיוון שערכי התג מוקצים באופן אקראי, יש סיכוי בלתי תלוי של ~93% לזיהוי הבאג בפעם הבאה שהוא יקרה.
ניתן לראות את ערכי התג בשדה כתובת התקלה וכן ב-Register 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 ..'.}...........