این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

درک گزارش های MTE

خرابی های SIGSEGV با کد 9 (SEGV_MTESERR) یا کد 8 (SEGV_MTEAERR) خطاهای برچسب گذاری حافظه هستند. افزونه برچسب گذاری حافظه (MTE) یکی از ویژگی های Armv9 است که در اندروید 12 به بعد پشتیبانی می شود. MTE یک پیاده سازی سخت افزاری از حافظه برچسب گذاری شده است. این محافظ حافظه ریز دانه را برای تشخیص و کاهش اشکالات ایمنی حافظه فراهم می کند.

در C/C++، یک اشاره گر برگردانده شده از یک فراخوانی به malloc() یا عملگر new() یا توابع مشابه فقط می تواند برای دسترسی به حافظه در محدوده آن تخصیص استفاده شود، و تنها زمانی که تخصیص زنده است (آزاد نشده یا آزاد نشده است). حذف شده). 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 حاوی روکش ثبت نام معمولی و ردیابی برای نقطه‌ای هستند که مشکل شناسایی شده است. خط "Cause:" برای خطای شناسایی شده توسط 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:

به استفاده از کلمه "درست" در اینجا توجه کنید: این بدان معناست که ما به شما می گوییم که دسترسی نادرست چند بایت پس از پایان تخصیص بوده است. یک 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...]

در مثال بالا، ما دو تخصیص اخیر را در یک آدرس حافظه شناسایی کرده‌ایم که می‌تواند هدف مورد نظر دسترسی نامعتبر به حافظه باشد. این ممکن است زمانی اتفاق بیفتد که تخصیص‌ها مجدداً از حافظه آزاد استفاده کنند - برای مثال، اگر دنباله‌ای مانند جدید، رایگان، جدید، رایگان، جدید، رایگان، دسترسی دارید. تخصیص جدیدتر ابتدا چاپ می شود.

اکتشافی تعیین علت دقیق

"علت" خرابی باید تخصیص حافظه را نشان دهد که نشانگر دسترسی در ابتدا از آن مشتق شده است. متأسفانه، سخت‌افزار MTE راهی برای ترجمه از یک نشانگر با برچسب نامتناسب به یک تخصیص ندارد. برای توضیح خرابی SEGV_MTESERR، Android داده‌های زیر را تجزیه و تحلیل می‌کند:

آدرس خطا (شامل تگ اشاره گر).
فهرستی از تخصیص‌های اخیر پشته با ردیابی پشته و برچسب‌های حافظه.
تخصیص های فعلی (زنده) نزدیک و برچسب های حافظه آنها.

هر حافظه ای که اخیراً در آدرس خطا تخصیص داده شده است، جایی که تگ حافظه با تگ آدرس خطا مطابقت دارد، یک علت بالقوه "استفاده پس از رایگان" است.

هر حافظه زنده نزدیکی که در آن تگ حافظه با برچسب آدرس خطا مطابقت داشته باشد، یک علت بالقوه "سرریز بافر" (یا "سرریز بافر") است.

تخصیص هایی که به گسل نزدیکتر هستند - چه در زمان و چه در مکان - محتمل تر از مواردی هستند که دور هستند.

از آنجایی که حافظه اختصاص داده شده اغلب مورد استفاده مجدد قرار می گیرد، و تعداد مقادیر مختلف تگ کم است (کمتر از 16)، یافتن چندین نامزد احتمالی غیرعادی نیست، و هیچ راهی برای یافتن خودکار علت واقعی وجود ندارد. به همین دلیل است که گاهی اوقات گزارش های MTE دلایل بالقوه متعددی را فهرست می کنند.

توصیه می‌شود که توسعه‌دهنده برنامه به دلایل بالقوه که از محتمل‌ترین آنها شروع می‌شود، نگاه کند. فیلتر کردن علل نامرتبط بر اساس ردیابی پشته اغلب آسان است.

حالت ناهمزمان MTE

در حالت ناهمزمان ("ناهمگام") MTE، SIGSEGV با کد 8 (SEGV_MTEAERR) خراب می شود.

هنگامی که یک برنامه دسترسی نامعتبر به حافظه انجام می دهد، خطاهای SEGV_MTEAERR بلافاصله رخ نمی دهد. مشکل در مدت کوتاهی پس از رویداد شناسایی می‌شود و در عوض برنامه در آن نقطه خاتمه می‌یابد. این نقطه معمولاً تماس بعدی سیستم است، اما همچنین می تواند یک وقفه تایمر باشد - به طور خلاصه، هر انتقال فضای کاربر به هسته.

خطاهای SEGV_MTEAERR آدرس حافظه را حفظ نمی کند (همیشه به صورت "-------" نشان داده می شود). ردیابی برگشتی مربوط به لحظه ای است که شرایط شناسایی شد (یعنی در تماس بعدی سیستم یا سوئیچ زمینه دیگر)، و نه زمانی که دسترسی نامعتبر انجام شد.

این بدان معناست که بک ردیاب اصلی در یک خرابی MTE ناهمزمان معمولاً مرتبط نیست . اشکال‌زدایی در حالت Async بسیار دشوارتر از خرابی‌های حالت همگام‌سازی است. آنها به بهترین وجه به عنوان نشان دادن وجود یک اشکال حافظه در کد نزدیک در رشته داده شده درک می شوند. گزارش‌های موجود در پایین فایل سنگ قبر ممکن است اشاره‌ای به آنچه واقعاً اتفاق افتاده است ارائه دهند. در غیر این صورت، اقدام توصیه شده این است که خطا را در حالت همگام سازی مجدد تولید کنید و از تشخیص بهتری که حالت همگام سازی ارائه می دهد استفاده کنید!

موضوعات پیشرفته

در زیر هود، برچسب گذاری حافظه با اختصاص یک مقدار تگ تصادفی 4 بیتی (0..15) به هر تخصیص پشته کار می کند. این مقدار در یک منطقه ابرداده ویژه که مربوط به حافظه Heap اختصاص داده شده است ذخیره می شود. همین مقدار به مهم ترین بایت نشانگر پشته که از توابعی مانند malloc() یا عملگر new() بازگردانده شده است، اختصاص داده می شود.

هنگامی که بررسی برچسب در این فرآیند فعال می شود، CPU به طور خودکار بایت بالای اشاره گر را با تگ حافظه برای هر دسترسی به حافظه مقایسه می کند. اگر تگ ها مطابقت نداشته باشند، CPU خطایی را نشان می دهد که منجر به خرابی می شود.

به دلیل تعداد محدودی از مقادیر برچسب ممکن، این رویکرد احتمالی است. هر مکان حافظه ای که نباید با یک اشاره گر معین به آن دسترسی پیدا کرد - مانند خارج از محدوده، یا پس از جابجایی ("اشاره گر آویزان") - احتمالاً دارای یک مقدار برچسب متفاوت است و باعث خرابی می شود. ~ 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  ..'.}...........