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

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

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

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

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

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

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

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

"บัฟเฟอร์ล้น" และ "Buffer Underflow" จะให้เพียงข้อผิดพลาด "จัดสรรโดย" สแต็กแทร็ก เนื่องจากตามคำจำกัดความแล้ว แทร็กเหล่านั้นยังไม่ได้มีการซื้อขาย (หรืออาจแสดงเป็น "ใช้ 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...]

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

การประเมินสาเหตุโดยละเอียด

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

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

หน่วยความจำที่มีการจัดสรรเมื่อเร็วๆ นี้ ณ ที่อยู่ที่ไม่ถูกต้องซึ่งแท็กหน่วยความจำตรงกับแท็กที่อยู่ผิดพลาดถือว่าเป็น "Use After Free" สาเหตุ

หน่วยความจำแบบเรียลไทม์ที่อยู่ใกล้เคียงซึ่งแท็กหน่วยความจำตรงกับแท็กที่อยู่ผิดพลาดถือว่าเป็น "Buffer Overflow" (หรือ "การบัฟเฟอร์ล้นออก")

การจัดสรรตำแหน่งที่มีความใกล้กับข้อผิดพลาดมากที่สุด ไม่ว่าจะอยู่ในเวลาหรือในอวกาศ จะได้รับการพิจารณาให้มากกว่าการจัดสรรที่อยู่ที่อยู่ไกล

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

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

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

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

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

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

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

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

ในส่วนขั้นสูง การติดแท็กหน่วยความจำจะทำงานโดยกำหนดค่าแท็กแบบ 4 บิตแบบสุ่ม (0..15) ให้กับการจัดสรรฮีปทุกรายการ ค่านี้จะจัดเก็บไว้ในภูมิภาคข้อมูลเมตาพิเศษที่สอดคล้องกับหน่วยความจำฮีปที่จัดสรร ระบบจะกำหนดค่าเดียวกันให้กับไบต์ที่สำคัญที่สุดของฮีปพอยต์ที่ส่งคืนจากฟังก์ชัน เช่น Malloc() หรือโอเปอเรเตอร์ 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

ส่วนของ Tombstone ที่แสดงเนื้อหาหน่วยความจำรอบๆ ค่ารีจิสเตอร์ทั้งหมดจะแสดงค่าของแท็กด้วย

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  ..'.}...........