หน้านี้ได้รับการแปลโดย Cloud Translation API

ทําความเข้าใจรายงาน MTE

ข้อขัดข้องของ SIGSEGV ที่มีรหัส 9 (SEGV_MTESERR) หรือรหัส 8 (SEGV_MTEAERR) คือข้อบกพร่องในการติดแท็กหน่วยความจำ Memory Tagging Extension (MTE) เป็นฟีเจอร์ Armv9 ที่รองรับใน Android 12 ขึ้นไป MTE คือการใช้งานฮาร์ดแวร์ของหน่วยความจําที่ติดแท็ก ซึ่งจะมอบการป้องกันหน่วยความจำแบบละเอียดเพื่อตรวจหาและบรรเทาข้อบกพร่องด้านความปลอดภัยของหน่วยความจำ

ใน C/C++ พ้อยเตอร์ที่แสดงผลจากการเรียก malloc() หรือ operator new() หรือฟังก์ชันที่คล้ายกันจะใช้ได้เพื่อเข้าถึงหน่วยความจำภายในขอบเขตของการจองเท่านั้น และใช้ได้เฉพาะในขณะที่การจองยังมีอยู่ (ไม่ได้ถูกปล่อยหรือลบ) MTE ใช้อยู่ใน Android เพื่อตรวจหาการละเมิดกฎนี้ ซึ่งจะแสดงในรายงานข้อขัดข้องเป็นปัญหา "บัฟเฟอร์ล้น"/"บัฟเฟอร์ไม่เพียงพอ" และ "การใช้งานหลังช่วงใช้ฟรี"

MTE มี 2 โหมด ได้แก่ แบบซิงค์ (หรือ "sync") และแบบอะซิงโครนัส (หรือ "async") ตัวเลือกแรกจะทํางานช้ากว่าแต่ให้การวินิจฉัยที่แม่นยํากว่า วิธีการหลังจะทำงานได้เร็วกว่า แต่จะให้รายละเอียดโดยประมาณเท่านั้น เราจะอธิบายทั้ง 2 อย่างแยกกันเนื่องจากการวินิจฉัยจะแตกต่างกันเล็กน้อย

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 ทั้งหมดจะมีการดัมพ์รีจิสเตอร์และแบ็กเทรซตามปกติสำหรับจุดที่ตรวจพบปัญหา บรรทัด "สาเหตุ:" สำหรับข้อผิดพลาดที่ MTE ตรวจพบจะมี "[MTE]" ดังตัวอย่างด้านบน พร้อมด้วยรายละเอียดเพิ่มเติม ในกรณีนี้ ข้อผิดพลาดที่ตรวจพบคือ "ใช้หลังจากปล่อย" และ "0 ไบต์ในการจอง 32 ไบต์ที่ 0x7ae92853a0" บอกขนาดและที่อยู่ของการจอง รวมถึงออฟเซตในการจองที่เราพยายามเข้าถึง

รายงานข้อขัดข้องของ MTE ยังมีแบ็กเทรซเพิ่มเติมด้วย ไม่ใช่แค่แบ็กเทรซจากจุดที่ตรวจพบ

ข้อผิดพลาด "ใช้หลังจากยกเลิกการจัดสรร" จะเพิ่มส่วน "ยกเลิกการจัดสรรโดย" และ "จัดสรรโดย" ลงในดัมพ์ข้อขัดข้อง ซึ่งจะแสดงสแต็กเทรซ ณ เวลาที่มีการยกเลิกการจัดสรรหน่วยความจำนี้ (ก่อนที่ระบบจะใช้) และเวลาที่จัดสรรหน่วยความจำก่อนหน้านี้ ข้อมูลเหล่านี้ยังบอกด้วยว่าเธรดใดเป็นผู้จัดสรร/ยกเลิกการจัดสรร เทรดสำหรับตรวจหา เทรดสำหรับจัดสรร และเทรดสำหรับการยกเลิกการจัดสรรทั้ง 3 รายการเหมือนกันในตัวอย่างง่ายๆ นี้ แต่ในกรณีจริงที่ซับซ้อนกว่านั้น เทรดเหล่านี้อาจไม่เหมือนกัน และการทราบว่าเทรดเหล่านี้แตกต่างกันอาจเป็นเบาะแสสำคัญในการค้นหาข้อบกพร่องที่เกี่ยวข้องกับการทํางานพร้อมกัน

ข้อผิดพลาด "Buffer Overflow" และ "Buffer Underflow" จะแสดงเฉพาะการติดตามสแต็ก "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...]

ในตัวอย่างข้างต้น เราตรวจพบการจัดสรรล่าสุด 2 รายการที่ที่อยู่หน่วยความจำเดียวกัน ซึ่งอาจเป็นเป้าหมายของการเข้าถึงหน่วยความจำที่ไม่ถูกต้อง กรณีนี้อาจเกิดขึ้นเมื่อมีการเรียกใช้หน่วยความจำว่างซ้ำ เช่น หากคุณมีลําดับ เช่น ใหม่ ว่าง ใหม่ ว่าง ใหม่ ว่าง เข้าถึง ระบบจะพิมพ์การกําหนดล่าสุดก่อน

วิธีการหาสาเหตุโดยละเอียด

"สาเหตุ" ของข้อขัดข้องควรแสดงการจัดสรรหน่วยความจำที่มาจากตัวชี้ที่เข้าถึงในตอนแรก ขออภัย ฮาร์ดแวร์ MTE ไม่สามารถแปลจากพอยน์เตอร์ที่มีแท็กไม่ตรงกันเป็นการจองได้ Android จะวิเคราะห์ข้อมูลต่อไปนี้เพื่ออธิบายข้อขัดข้อง SEGV_MTESERR

ที่อยู่ข้อบกพร่อง (รวมถึงแท็กเคอร์เซอร์)
รายการการจัดสรรฮีพล่าสุดพร้อมสแต็กเทรซและแท็กหน่วยความจำ
การจัดสรรปัจจุบัน (แบบเรียลไทม์) ที่อยู่ใกล้เคียงและแท็กหน่วยความจำของการจัดสรรดังกล่าว

หน่วยความจําที่เพิ่งยกเลิกการจัดสรรที่ที่อยู่ข้อบกพร่องซึ่งแท็กหน่วยความจําตรงกับแท็กที่อยู่ข้อบกพร่องอาจเป็นสาเหตุที่ทำให้เกิด "การใช้หลังจากยกเลิกการจัดสรร"

หน่วยความจําที่ใช้งานอยู่ใกล้เคียงซึ่งแท็กหน่วยความจําตรงกับแท็กที่อยู่ข้อบกพร่องอาจเป็นสาเหตุของ "บัฟเฟอร์ที่ล้น" (หรือ "บัฟเฟอร์ที่ขาด")

การจัดสรรที่อยู่ใกล้กับข้อบกพร่องมากกว่า ทั้งในแง่เวลาและพื้นที่ จะถือว่ามีแนวโน้มมากกว่าการจัดสรรที่อยู่ไกล

เนื่องจากระบบมักนำหน่วยความจำที่ยกเลิกการจัดสรรไปใช้งานซ้ำ และจำนวนค่าแท็กต่างๆ มีไม่มาก (น้อยกว่า 16) จึงเป็นเรื่องปกติที่จะเห็นรายการที่เป็นไปได้หลายรายการ และไม่มีวิธีค้นหาสาเหตุที่แท้จริงโดยอัตโนมัติ ด้วยเหตุนี้ บางครั้งรายงาน MTE จึงแสดงสาเหตุที่เป็นไปได้หลายรายการ

เราขอแนะนำให้นักพัฒนาแอปพิจารณาสาเหตุที่เป็นไปได้โดยเริ่มจากสาเหตุที่เป็นไปได้มากที่สุด มักกรองสาเหตุที่ไม่เกี่ยวข้องออกได้ง่ายๆ ตามสแต็กเทรซ

MTE โหมดอะซิงโครนัส

ในโหมดแบบอะซิงโครนัส ("async") ของ MTE นั้น SIGSEGV จะขัดข้องด้วยรหัส 8 (SEGV_MTEAERR)

ข้อบกพร่อง SEGV_MTEAERR จะไม่เกิดขึ้นทันทีเมื่อโปรแกรมทำการเข้าถึงหน่วยความจำที่ไม่ถูกต้อง ระบบจะตรวจพบปัญหาหลังจากเหตุการณ์ไม่นาน และโปรแกรมจะสิ้นสุดลง ณ จุดนั้นแทน โดยปกติแล้วจุดนี้จะเป็นการเรียกใช้ระบบครั้งถัดไป แต่อาจเป็นการขัดจังหวะตัวจับเวลาก็ได้ กล่าวโดยย่อคือการเปลี่ยนจากพื้นที่ผู้ใช้ไปยังเคอร์เนล

ข้อบกพร่อง SEGV_MTEAERR จะไม่เก็บที่อยู่หน่วยความจำไว้ (จะแสดงเป็น "-------" เสมอ) การย้อนกลับจะสอดคล้องกับเวลาที่ตรวจพบเงื่อนไข (เช่น ที่การเรียกใช้ระบบครั้งถัดไปหรือการเปลี่ยนบริบทอื่นๆ) ไม่ใช่เวลาที่ทำการเข้าถึงที่ไม่ถูกต้อง

ซึ่งหมายความว่าการแบ็กเทรซ "หลัก" ในการขัดข้องของ MTE แบบไม่พร้อมกันมักจะไม่เกี่ยวข้อง ดังนั้น การแก้ไขข้อบกพร่องของโหมดแอซิงค์จึงยากกว่าโหมดซิงค์ วิธีที่เข้าใจได้ง่ายที่สุดคือแสดงว่ามีข้อบกพร่องเกี่ยวกับหน่วยความจําในโค้ดที่อยู่ใกล้เคียงในชุดข้อความนั้น บันทึกที่ด้านล่างของไฟล์ Tombstone อาจให้เบาะแสเกี่ยวกับสิ่งที่เกิดขึ้นจริง หรือวิธีที่เราแนะนำคือให้สร้างข้อผิดพลาดซ้ำในโหมดซิงค์และใช้การวินิจฉัยที่ดีกว่าซึ่งโหมดซิงค์มีให้

หัวข้อขั้นสูง

การทำงานเบื้องหลังของการติดแท็กหน่วยความจำคือการกําหนดค่าแท็ก 4 บิต (0..15) แบบสุ่มให้กับการจัดสรรฮีปทุกครั้ง ค่านี้จะจัดเก็บไว้ในภูมิภาคข้อมูลเมตาพิเศษซึ่งสอดคล้องกับหน่วยความจำฮีปที่จัดสรร ระบบจะกําหนดค่าเดียวกันให้กับไบต์สําคัญที่สุดของพอยน์เตอร์ฮีปที่แสดงผลจากฟังก์ชัน เช่น malloc() หรือ operator new()

เมื่อเปิดใช้การตรวจสอบแท็กในกระบวนการ CPU จะเปรียบเทียบไบต์บนสุดของพอยน์เตอร์กับแท็กหน่วยความจำสำหรับการเข้าถึงหน่วยความจำทุกครั้งโดยอัตโนมัติ หากแท็กไม่ตรงกัน CPU จะส่งสัญญาณข้อผิดพลาดที่ทําให้ระบบขัดข้อง

วิธีการนี้เป็นแบบสถิติเนื่องจากค่าแท็กที่เป็นไปได้มีจํานวนจำกัด ตำแหน่งหน่วยความจำที่ไม่ควรเข้าถึงด้วยพอยน์เตอร์หนึ่งๆ เช่น อยู่นอกขอบเขต หรือหลังจากการจัดสรรหน่วยความจำใหม่ ("พอยน์เตอร์ที่ไม่มีการอ้างอิง") มีแนวโน้มที่จะมีค่าแท็กที่ต่างกันและทำให้เกิดข้อขัดข้อง มีโอกาสประมาณ 7% ที่จะไม่พบข้อบกพร่องแม้แต่รายการเดียว เนื่องจากระบบกําหนดค่าแท็กแบบสุ่ม จึงมีโอกาสประมาณ 93% ที่ระบบจะตรวจพบข้อบกพร่องได้อีกครั้งเมื่อเกิดข้อบกพร่องขึ้น

ค่าแท็กจะแสดงในช่องที่อยู่ข้อบกพร่องและในดัมพ์รีจิสเตอร์ ดังที่ไฮไลต์ไว้ด้านล่าง ส่วนนี้ใช้เพื่อตรวจสอบว่าแท็กได้รับการตั้งค่าอย่างถูกต้อง รวมถึงดูการจัดสรรหน่วยความจําอื่นๆ ที่อยู่ใกล้เคียงซึ่งมีค่าแท็กเดียวกัน เนื่องจากอาจเป็นสาเหตุที่ทำให้เกิดข้อผิดพลาดนอกเหนือจากที่ระบุไว้ในรายงาน เราคาดว่าฟีเจอร์นี้จะเป็นประโยชน์สําหรับผู้ที่ทํางานเกี่ยวกับการติดตั้งใช้งาน 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  ..'.}...........