Sự cố SIGSEGV với mã 9 (SEGV_MTESERR) hoặc mã 8 (SEGV_MTEAERR) là lỗi Gắn thẻ bộ nhớ. Tiện ích gắn thẻ bộ nhớ (MTE) là một tính năng Armv9 được hỗ trợ trong Android 12 trở lên. MTE là một phương thức triển khai phần cứng của bộ nhớ được gắn thẻ. Công cụ này cung cấp tính năng bảo vệ bộ nhớ chi tiết để phát hiện và giảm thiểu lỗi về độ an toàn của bộ nhớ.
Trong C/C++, con trỏ được trả về từ lệnh gọi đến malloc() hoặc toán tử new() hoặc các hàm tương tự chỉ có thể được dùng để truy cập vào bộ nhớ trong giới hạn của quá trình phân bổ đó và chỉ khi quá trình phân bổ vẫn còn hoạt động (không bị giải phóng hoặc xoá). MTE được dùng trong Android để phát hiện các lỗi vi phạm quy tắc này, được gọi trong báo cáo sự cố là "Buffer Overflow"/"Buffer Underflow" (Vùng đệm tràn/Vùng đệm thiếu) và "Use After Free" (Sử dụng sau khi giải phóng).
MTE có hai chế độ: đồng bộ (hoặc "đồng bộ") và không đồng bộ (hoặc "không đồng bộ"). Phương thức trước chạy chậm hơn nhưng cung cấp thông tin chẩn đoán chính xác hơn. Phương thức sau chạy nhanh hơn nhưng chỉ có thể cung cấp thông tin chi tiết gần đúng. Chúng ta sẽ đề cập riêng từng loại, vì thông tin chẩn đoán có đôi chút khác biệt.
MTE ở chế độ đồng bộ
Ở chế độ đồng bộ ("sync") của MTE, SIGSEGV gặp sự cố với mã 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)
Tất cả báo cáo sự cố MTE đều chứa tệp báo lỗi và truy vết ngược thông thường cho điểm phát hiện vấn đề. Dòng "Cause:" (Nguyên nhân:) cho lỗi do MTE phát hiện sẽ chứa "[MTE]" như trong ví dụ ở trên, cùng với thông tin chi tiết hơn. Trong trường hợp này, loại lỗi cụ thể được phát hiện là "Sử dụng sau khi giải phóng" và "0 byte vào vùng phân bổ 32 byte tại 0x7ae92853a0" cho chúng ta biết kích thước và địa chỉ của vùng phân bổ cũng như độ dời vào vùng phân bổ mà chúng ta đã cố gắng truy cập.
Báo cáo sự cố MTE cũng bao gồm các dấu vết lui bổ sung, chứ không chỉ dấu vết từ thời điểm phát hiện.
Lỗi "Sử dụng sau khi giải phóng" sẽ thêm các phần "đã giải phóng bởi" và "đã phân bổ bởi" vào tệp báo lỗi, cho thấy dấu vết ngăn xếp tại thời điểm bộ nhớ này được giải phóng (trước khi được sử dụng!) và thời gian được phân bổ trước đó. Các thông tin này cũng cho bạn biết luồng nào đã thực hiện việc phân bổ/giải phóng. Cả ba luồng phát hiện, luồng phân bổ và luồng giải phóng đều giống nhau trong ví dụ đơn giản này, nhưng trong các trường hợp thực tế phức tạp hơn, điều này không nhất thiết phải đúng và việc biết rằng chúng khác nhau có thể là một gợi ý quan trọng trong việc tìm lỗi liên quan đến tính đồng thời.
Lỗi "Buffer Overflow" (Vượt quá bộ đệm) và "Buffer Underflow" (Dưới mức bộ đệm) chỉ cung cấp thêm một kênh theo dõi ngăn xếp "allocated by" (do phân bổ) vì theo định nghĩa, các lỗi này chưa được giải phóng (hoặc sẽ xuất hiện dưới dạng "Use After Free" (Sử dụng sau khi giải phóng)):
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 32-byte allocation at 0x7ae92853a0 [...] backtrace: [...] allocated by thread 13949:
Lưu ý việc sử dụng từ "phải" ở đây: nghĩa là chúng tôi sẽ cho bạn biết số byte sau khi kết thúc quá trình phân bổ là quyền truy cập không chính xác; tình trạng thiếu dữ liệu sẽ cho biết "trái" và là số byte trước khi bắt đầu quá trình phân bổ.
Có nhiều nguyên nhân tiềm ẩn
Đôi khi, báo cáo SEGV_MTESERR chứa dòng sau:
Note: multiple potential causes for this crash were detected, listing them in decreasing order of likelihood.
Điều này xảy ra khi có một số ứng cử viên phù hợp cho nguồn gốc lỗi và chúng ta không thể biết đâu là nguyên nhân thực sự. Chúng tôi in tối đa 3 ứng viên như vậy theo thứ tự gần đúng về khả năng và để người dùng phân tích.
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...]Trong ví dụ trên, chúng tôi đã phát hiện hai lượt phân bổ gần đây tại cùng một địa chỉ bộ nhớ có thể là mục tiêu dự kiến của hoạt động truy cập bộ nhớ không hợp lệ. Điều này có thể xảy ra khi các lượt phân bổ sử dụng lại bộ nhớ trống – ví dụ: nếu bạn có trình tự như mới, trống, mới, trống, mới, trống, truy cập. Phân bổ gần đây hơn sẽ được in trước.
Phương pháp phỏng đoán chi tiết để xác định nguyên nhân
"Nguyên nhân" của sự cố sẽ cho thấy mức phân bổ bộ nhớ mà con trỏ được truy cập ban đầu bắt nguồn từ đó. Rất tiếc, phần cứng MTE không có cách nào để dịch từ con trỏ có thẻ không khớp sang một lượt phân bổ. Để giải thích sự cố SEGV_MTESERR, Android phân tích dữ liệu sau:
- Địa chỉ lỗi (bao gồm cả thẻ con trỏ).
- Danh sách các lượt phân bổ vùng nhớ khối xếp gần đây có dấu vết ngăn xếp và thẻ bộ nhớ.
- Các lượt phân bổ hiện tại (trực tiếp) lân cận và thẻ bộ nhớ của các lượt phân bổ đó.
Mọi bộ nhớ được giải phóng gần đây tại địa chỉ lỗi mà thẻ bộ nhớ khớp với thẻ địa chỉ lỗi đều có thể là nguyên nhân gây ra lỗi "Sử dụng sau khi giải phóng".
Mọi bộ nhớ trực tiếp lân cận mà thẻ bộ nhớ khớp với thẻ địa chỉ lỗi đều có thể là nguyên nhân gây ra "Vượt quá bộ đệm" (hoặc "Dưới bộ đệm").
Các lượt phân bổ gần lỗi hơn (theo thời gian hoặc không gian) được xem là có nhiều khả năng hơn so với các lượt phân bổ ở xa.
Vì bộ nhớ được giải phóng thường được sử dụng lại và số lượng giá trị thẻ khác nhau là nhỏ (dưới 16), nên việc tìm thấy một số ứng cử viên có thể xảy ra là điều bình thường và không có cách nào để tự động tìm ra nguyên nhân thực sự. Đây là lý do đôi khi báo cáo MTE liệt kê nhiều nguyên nhân tiềm ẩn.
Nhà phát triển ứng dụng nên xem xét các nguyên nhân tiềm ẩn, bắt đầu từ nguyên nhân có nhiều khả năng nhất. Thông thường, bạn có thể dễ dàng lọc ra các nguyên nhân không liên quan dựa trên dấu vết ngăn xếp.
MTE ở chế độ không đồng bộ
Ở chế độ không đồng bộ ("async") của MTE, SIGSEGV gặp sự cố với mã 8 (SEGV_MTEAERR).
Lỗi SEGV_MTEAERR không xảy ra ngay lập tức khi một chương trình thực hiện quyền truy cập bộ nhớ không hợp lệ. Vấn đề được phát hiện ngay sau sự kiện và chương trình sẽ bị chấm dứt tại thời điểm đó. Điểm này thường là lệnh gọi hệ thống tiếp theo, nhưng cũng có thể là một ngắt thời gian – nói ngắn gọn là bất kỳ quá trình chuyển đổi nào từ không gian người dùng sang nhân.
Lỗi SEGV_MTEAERR không giữ lại địa chỉ bộ nhớ (luôn hiển thị là "-------"). Dấu vết ngược tương ứng với thời điểm phát hiện điều kiện (tức là tại lệnh gọi hệ thống tiếp theo hoặc chuyển đổi ngữ cảnh khác), chứ không phải thời điểm thực hiện quyền truy cập không hợp lệ.
Điều này có nghĩa là dấu vết lui "chính" trong sự cố MTE không đồng bộ thường không liên quan. Do đó, lỗi ở chế độ không đồng bộ khó gỡ lỗi hơn nhiều so với lỗi ở chế độ đồng bộ. Bạn nên hiểu rằng các lỗi này cho thấy sự tồn tại của lỗi bộ nhớ trong mã gần đó trong luồng nhất định. Nhật ký ở cuối tệp tombstone có thể cung cấp gợi ý về những gì thực sự đã xảy ra. Nếu không, bạn nên tái tạo lỗi ở chế độ đồng bộ hoá và sử dụng thông tin chẩn đoán tốt hơn mà chế độ đồng bộ hoá cung cấp!
Chủ đề nâng cao
Về cơ bản, tính năng gắn thẻ bộ nhớ hoạt động bằng cách gán một giá trị thẻ 4 bit (0..15) ngẫu nhiên cho mọi lượt phân bổ vùng nhớ khối xếp. Giá trị này được lưu trữ trong một vùng siêu dữ liệu đặc biệt tương ứng với bộ nhớ khối xếp được phân bổ. Giá trị tương tự được gán cho byte có giá trị quan trọng nhất của con trỏ vùng nhớ khối xếp được trả về từ các hàm như malloc() hoặc toán tử new().
Khi tính năng kiểm tra thẻ được bật trong quy trình, CPU sẽ tự động so sánh byte trên cùng của con trỏ với thẻ bộ nhớ cho mỗi lần truy cập bộ nhớ. Nếu các thẻ không khớp, CPU sẽ báo lỗi dẫn đến sự cố.
Do số lượng giá trị thẻ có thể có bị hạn chế, phương pháp này mang tính xác suất. Mọi vị trí bộ nhớ không được truy cập bằng con trỏ nhất định – chẳng hạn như ngoài giới hạn hoặc sau khi giải phóng ("con trỏ lơ lửng") – có thể có giá trị thẻ khác và gây ra sự cố. Có khoảng 7% khả năng không phát hiện được bất kỳ lỗi nào. Vì các giá trị thẻ được chỉ định ngẫu nhiên, nên có khoảng 93% khả năng độc lập để phát hiện lỗi trong lần tiếp theo lỗi xảy ra.
Bạn có thể xem các giá trị thẻ trong trường địa chỉ lỗi cũng như trong tệp kết xuất thanh ghi, như được làm nổi bật bên dưới. Bạn có thể sử dụng phần này để kiểm tra xem các thẻ đã được đặt đúng cách hay chưa, cũng như để xem các lượt phân bổ bộ nhớ lân cận khác có cùng giá trị thẻ vì chúng có thể là nguyên nhân tiềm ẩn gây ra lỗi ngoài những nguyên nhân được liệt kê trong báo cáo. Chúng tôi dự kiến tính năng này chủ yếu hữu ích cho những người đang triển khai chính MTE hoặc các thành phần hệ thống cấp thấp khác, thay vì nhà phát triển.
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
Một phần "Thẻ bộ nhớ" đặc biệt cũng xuất hiện trong báo cáo sự cố, cho thấy các thẻ bộ nhớ xung quanh địa chỉ lỗi. Trong ví dụ dưới đây, thẻ con trỏ "4" không khớp với thẻ bộ nhớ "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
Các phần của bia mộ hiển thị nội dung bộ nhớ xung quanh tất cả các giá trị đăng ký cũng hiển thị giá trị thẻ của các phần đó.
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 ..'.}...........