דף זה תורגם על ידי Cloud Translation API.

הסבר על דוחות MTE

קריסות SIGSEGV עם קוד 9 (SEGV_MTESERR) או קוד 8 (SEGV_MTEAERR) הן תקלות בתיוג הזיכרון. תוסף תיוג זיכרון (MTE) הוא התכונה Armv9 נתמכת ב-Android 12 ואילך. MTE הוא הטמעת חומרה של זיכרון. היא מספקת הגנת זיכרון פרטנית לזיהוי ולצמצום של באגי בטיחות בזיכרון.

ב-C/C++ , מצביע שמוחזר מקריאה ל-Malloc() או מאופרטור new() או מפונקציות דומות, יכול ישמשו רק כדי לגשת לזיכרון בגבולות ההקצאה הזו, ורק ההקצאה פעילה (לא בוטלה או נמחקה). MTE משמש ב-Android כדי לזהות הפרות של הכלל הזה נקרא בדוחות הקריסה "Buffer Overflow"/"Buffer belowflow" וגם "לשימוש לאחר התשלום" בעיות נפוצות.

ל-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 מכילים את תמונת המצב הרגילה של הרישום והמעקב אחרי הנקודה שבה זוהתה בעיה. 'הסיבה': שורה לשגיאה שזוהה על ידי MTE תכלול את המחרוזת '[MTE]'. כמו בדוגמה שלמעלה, בצירוף פרטים נוספים. במקרה הזה, סוג השגיאה הספציפי שזוהתה היה "שימוש אחרי חינם", ו-"0 בייט בהקצאה של 32 בייטים ב-0x7ae92853a0" אומר לנו הגודל והכתובת של ההקצאה, וההפרש ביחס להקצאה שניסינו לגשת אליה.

דוחות קריסה של MTE כוללים גם מעקבים לאחור נוספים, לא רק את המעקב בנקודת הזיהוי.

"לשימוש לאחר התשלום" שגיאות שהוסיפו את הכיתוב 'הוקצה על ידי' וגם "מוקצה על ידי" לקטע 'קריסת מחשב', שמציג את דוחות הקריסות בזמן שהזיכרון הזה הוקצה (לפני שנעשה בו שימוש!), וגם הזמן שהוקצה להם בעבר. הם גם מציינים באיזה שרשור הקצאה/הקצאה. כל שלושת השרשורים לזיהוי, הקצאת שרשור ואיתור עסקה והשרשורים זהים בדוגמה הפשוטה, אבל במקרים מורכבים יותר בעולם האמיתי זו לא הדרך הם בהכרח נכונים, והידיעה שהם שונים יכולה להיות רמז חשוב באג הקשור בו-זמניות (concurrency).

'גלישת מאגר' ו-Buffer Andflow מספקים רק ערך נוסף של 'מוקצה על ידי' בגלל שהם עדיין לא הוקצו, בגלל שהם עדיין לא הוקצו (או שהם יופיעו "Use After Free"):

Cause: [MTE]: Buffer Overflow, 0 bytes right of a 32-byte allocation at 0x7ae92853a0
[...]
backtrace:
[...]
allocated by thread 13949:

שימו לב לשימוש במילה "right" כאן אנחנו מציינים כמה בייטים מעבר לסוף מתוך ההקצאה: הגישה השגויה הייתה זרם תחתון ייאמר "left", בייטים לפני תחילת ההקצאה.

סיבות אפשריות רבות

לפעמים דוחות 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, מערכת Android מנתחת את הנתונים הבאים:

כתובת הכשל (כולל תג המצביע).
רשימה של הקצאות ערימה (heap) מהזמן האחרון עם דוחות קריסות ותגי זיכרון.
הקצאות נוכחיות (פעיל) בקרבת מקום ותגי הזיכרון שלהן.

כל זיכרון שהוקדש לאחרונה בכתובת הכשל שבה תג הזיכרון תואם לתג כתובת של השגיאה הוא 'שימוש לאחר חינם'. סיבה.

כל זיכרון פעיל שנמצא בקרבת מקום שבו תג הזיכרון תואם לתג הכתובת של התקלה, עלול לגרום ל-Buffer Overflow (או 'זרימת מאגר נתונים זמני').

הקצאות שקרובות יותר לשגיאה – בזמן או בחלל – נחשבות בסבירות יותר מאשר הקצאות רחוקות.

לרוב, נעשה שימוש חוזר בזיכרון שנמצא במיקום המשותף, ומספר הערכים השונים של התגים הוא קטן (פחות מ-16), ולכן לפעמים ניתן למצוא כמה מועמדים אפשריים, ואין דרך למצוא אוטומטית את הסיבה האמיתית. זו הסיבה לכך שלפעמים דוחות MTE מפרטים כמה סיבות אפשריות.

מומלץ שמפתח האפליקציה יבדוק את הסיבות האפשריות, החל מהסיבה הסבירה ביותר. בעזרת דוח הקריסות, בדרך כלל קל לסנן סיבות לא קשורות.

מצב אסינכרוני MTE

במצב האסינכרוני של MTE ('אסינכרוני'), SIGSEGV קורס עם קוד 8 (SEGV_MTEAERR).

שגיאות SEGV_MTEAERR לא מתרחשות באופן מיידי כשתוכנה מבצעת גישה לא חוקית לזיכרון. הבעיה מזוהה זמן קצר אחרי האירוע, והתוכנית מפסיקה באותו הזמן. הנקודה הזו היא בדרך כלל קריאת המערכת הבאה, אבל היא יכולה גם לשמש כהפרעה לשעון - בקיצור, כל מעבר בין מרחב משתמש לליבה (kernel).

שגיאות SEGV_MTEAERR לא שומרות את כתובת הזיכרון (היא תמיד מוצגת בתור "-------"). המעקב החוזר תואם לרגע שבו התנאי זוהה (כלומר, בקריאת המערכת הבאה או במתג הקשר אחר), ולא למועד שבו בוצעה הגישה הלא חוקית.

כלומר, החלק "הראשי" מעקב לאחור בקריסת MTE אסינכרונית בדרך כלל לא רלוונטי. לכן, קל יותר לנפות באגים כשלים במצב אסינכרוני מאשר כשלים במצב הסנכרון. הדרך הטובה ביותר להבין אותם היא שהם מראים את קיומו של באג בזיכרון בקוד בקרבת מקום בשרשור הנתון. היומנים שבתחתית קובץ המצבה עשויים לספק רמז על מה שקרה בפועל. אם לא, דרך הפעולה המומלצת היא לשחזר את השגיאה במצב סנכרון ולהשתמש בכלי האבחון הטוב יותר שזמין במצב הסנכרון.

נושאים מתקדמים

באופן כללי, תיוג הזיכרון פועל על ידי הקצאת ערך תג אקראי של 4 ביט (0..15) לכל הקצאת ערימה. הערך הזה מאוחסן באזור מיוחד של מטא-נתונים שתואם לזיכרון הערימה שהוקצה. אותו ערך מוקצה לבייט המשמעותי ביותר של מצביע הערימה שמוחזר מפונקציות כמו Malloc() או האופרטור new().

כשבדיקת התגים מופעלת בתהליך הזה, המעבד (CPU) משווה באופן אוטומטי את הבייט העליון של הסמן לבין תג הזיכרון בכל גישה לזיכרון. אם התגים לא תואמים, המעבד (CPU) מסמן שגיאה שמובילה לקריסה.

בגלל המספר המוגבל של ערכי תגים אפשריים, הגישה הזו היא הסתברותית. לכל מיקום זיכרון שלא צריך לגשת אליו באמצעות מצביע נתון – כמו מחוץ לתחום או אחרי Deallocation (מצביע תלוי) – סביר להניח שהערך של התג יהיה שונה, והוא יגרום לקריסה. יש סיכוי של כ-7% לא לזהות אירוע אחד של באג. מאחר שהערכים של התג מוקצים באופן אקראי, יש סיכוי עצמאי של כ-93% לזהות את הבאג בפעם הבאה שהוא יקרה.

ערכי התג מופיעים בשדה כתובת השגיאה וגם בקובץ ה-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  ..'.}...........