SIGSEGV crash dengan kode 9 (SEGV_MTESERR) atau kode 8 (SEGV_MTEAERR) merupakan kesalahan Memory Tagging. Memory Tagging Extension (MTE) adalah fitur Armv9 yang didukung di Android 12 dan lebih baru. MTE adalah implementasi perangkat keras dari memori yang diberi tag. Ini memberikan perlindungan memori yang sangat baik untuk deteksi dan mitigasi bug keamanan memori .
Dalam C/C++, pointer yang dikembalikan dari panggilan ke malloc() atau operator new() atau fungsi serupa hanya dapat digunakan untuk mengakses memori dalam batas alokasi tersebut, dan hanya ketika alokasi tersebut aktif (tidak dikosongkan atau hapus-red). MTE digunakan di Android untuk mendeteksi pelanggaran aturan ini, yang dalam laporan kerusakan disebut sebagai masalah "Buffer Overflow"/"Buffer Underflow" dan "Gunakan Setelah Gratis".
MTE memiliki dua mode: sinkron (atau "sinkronisasi") dan asinkron (atau "async"). Yang pertama berjalan lebih lambat tetapi memberikan diagnosis yang lebih akurat. Yang terakhir berjalan lebih cepat, tetapi hanya dapat memberikan perkiraan detail. Kami akan membahas keduanya secara terpisah, karena diagnosisnya sedikit berbeda.
Mode sinkron MTE
Dalam mode sinkron ("sinkronisasi") MTE, SIGSEGV lumpuh dengan kode 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)
Semua laporan kerusakan MTE berisi register dump dan penelusuran balik yang biasa untuk titik di mana masalah terdeteksi. Baris "Penyebab:" untuk kesalahan yang terdeteksi oleh MTE akan berisi "[MTE]" seperti pada contoh di atas, beserta lebih detailnya. Dalam hal ini, jenis kesalahan spesifik yang terdeteksi adalah "Gunakan setelah gratis", dan "0 byte menjadi alokasi 32-byte di 0x7ae92853a0" memberi tahu kita ukuran dan alamat alokasi, dan offset ke dalam alokasi yang kita mencoba mengakses.
Laporan kerusakan MTE juga mencakup penelusuran balik tambahan, bukan hanya penelusuran dari titik deteksi.
Kesalahan "Gunakan Setelah Gratis" menambahkan bagian "tidak dialokasikan oleh" dan "dialokasikan oleh" ke dump kerusakan, memperlihatkan jejak tumpukan pada saat memori ini dibatalkan alokasinya (sebelum digunakan!), dan waktu dialokasikan sebelumnya. Ini juga memberi tahu Anda thread mana yang melakukan pengalokasian/pembatalan alokasi. Ketiga thread pendeteksi, thread pengalokasian, dan thread pembatalan alokasi sama dalam contoh sederhana ini, namun dalam kasus dunia nyata yang lebih kompleks, hal ini belum tentu benar, dan mengetahui bahwa ketiganya berbeda dapat menjadi petunjuk penting dalam menemukan konkurensi. bug terkait.
Kesalahan "Buffer Overflow" dan "Buffer Underflow" hanya menyediakan trek tumpukan "dialokasikan oleh" tambahan, karena menurut definisi kesalahan tersebut belum dibatalkan alokasinya (atau akan muncul sebagai "Gunakan Setelah Gratis"):
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 32-byte allocation at 0x7ae92853a0 [...] backtrace: [...] allocated by thread 13949:
Perhatikan penggunaan kata "benar" di sini: ini berarti kami memberi tahu Anda berapa byte setelah akhir alokasi akses yang salah; aliran bawah akan berbunyi "kiri", dan merupakan jumlah byte sebelum dimulainya alokasi.
Berbagai penyebab potensial
Terkadang laporan SEGV_MTESERR berisi baris berikut:
Note: multiple potential causes for this crash were detected, listing them in decreasing order of likelihood.
Hal ini terjadi bila ada beberapa kandidat yang baik untuk asal kesalahan, dan kita tidak dapat menentukan penyebab sebenarnya. Kami mencetak hingga 3 kandidat tersebut dalam perkiraan urutan kemungkinan, dan menyerahkan analisis kepada pengguna.
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...]Dalam contoh di atas, kami mendeteksi dua alokasi terbaru pada alamat memori yang sama yang mungkin menjadi target akses memori yang tidak valid. Hal ini dapat terjadi ketika alokasi menggunakan kembali memori bebas - misalnya, jika Anda memiliki urutan seperti akses baru, gratis, baru, gratis, baru, gratis. Alokasi terbaru dicetak terlebih dahulu.
Heuristik penentuan penyebab terperinci
"Penyebab" kerusakan harus menunjukkan alokasi memori asal penunjuk yang diakses. Sayangnya, perangkat keras MTE tidak memiliki cara untuk menerjemahkan dari pointer dengan tag yang tidak cocok ke alokasi. Untuk menjelaskan error SEGV_MTESERR, Android menganalisis data berikut:
- Alamat kesalahan (termasuk tag penunjuk).
- Daftar alokasi heap terbaru dengan pelacakan tumpukan dan tag memori.
- Alokasi terdekat saat ini (langsung) dan tag memorinya.
Memori apa pun yang baru saja dibatalkan alokasinya pada alamat kesalahan di mana tag memori cocok dengan tag alamat kesalahan merupakan potensi penyebab "Gunakan Setelah Gratis".
Memori aktif terdekat yang tag memorinya cocok dengan tag alamat kesalahan berpotensi menjadi penyebab "Buffer Overflow" (atau "Buffer Underflow").
Alokasi yang lebih dekat dengan sesar - baik dalam waktu maupun ruang - dianggap lebih mungkin terjadi dibandingkan alokasi yang jauh.
Karena memori yang tidak dialokasikan sering kali digunakan kembali, dan jumlah nilai tag yang berbeda sedikit (kurang dari 16), tidak jarang ditemukan beberapa kandidat yang mungkin, dan tidak ada cara untuk menemukan penyebab sebenarnya secara otomatis. Inilah alasan mengapa terkadang laporan MTE mencantumkan beberapa penyebab potensial.
Disarankan agar pengembang aplikasi melihat potensi penyebab, dimulai dari penyebab yang paling mungkin. Seringkali mudah untuk menyaring penyebab yang tidak berhubungan berdasarkan jejak tumpukan.
Mode asinkron MTE
Dalam mode asinkron ("async") MTE, SIGSEGV lumpuh dengan kode 8 (SEGV_MTEAERR).
Kesalahan SEGV_MTEAERR tidak langsung terjadi ketika suatu program melakukan akses memori yang tidak valid. Masalah terdeteksi segera setelah kejadian, dan program dihentikan pada saat itu. Titik ini biasanya merupakan panggilan sistem berikutnya, namun dapat juga berupa interupsi pengatur waktu - singkatnya, setiap transisi ruang pengguna ke kernel.
Kesalahan SEGV_MTEAERR tidak mempertahankan alamat memori (selalu ditampilkan sebagai "-------"). Pelacakan balik berkaitan dengan saat kondisi terdeteksi (yaitu pada panggilan sistem berikutnya atau peralihan konteks lainnya), dan bukan saat akses tidak valid dilakukan.
Ini berarti bahwa penelusuran balik "utama" dalam kecelakaan MTE asinkron biasanya tidak relevan . Kegagalan mode asinkron jauh lebih sulit untuk di-debug dibandingkan kegagalan mode sinkronisasi. Mereka paling baik dipahami sebagai menunjukkan adanya bug memori dalam kode terdekat di thread yang diberikan. Log di bagian bawah file batu nisan mungkin memberikan petunjuk tentang apa yang sebenarnya terjadi. Jika tidak, tindakan yang disarankan adalah mereproduksi kesalahan dalam mode sinkronisasi dan menggunakan diagnostik yang lebih baik yang disediakan oleh mode sinkronisasi!
Topik lanjutan
Di bawah tenda, penandaan memori bekerja dengan menetapkan nilai tag 4-bit (0..15) acak untuk setiap alokasi heap. Nilai ini disimpan di wilayah metadata khusus yang sesuai dengan memori heap yang dialokasikan. Nilai yang sama diberikan ke byte paling signifikan dari penunjuk heap yang dikembalikan dari fungsi seperti malloc() atau operator new().
Ketika pemeriksaan tag diaktifkan dalam proses, CPU secara otomatis membandingkan byte teratas penunjuk dengan tag memori untuk setiap akses memori. Jika tag tidak cocok, CPU memberi sinyal kesalahan yang menyebabkan kerusakan.
Karena terbatasnya jumlah kemungkinan nilai tag, pendekatan ini bersifat probabilistik. Setiap lokasi memori yang tidak boleh diakses dengan penunjuk tertentu - seperti di luar batas, atau setelah dealokasi ("penunjuk menjuntai") - kemungkinan memiliki nilai tag yang berbeda, dan menyebabkan kerusakan. Ada kemungkinan ~7% untuk tidak mendeteksi satu pun kemunculan bug. Karena nilai tag ditetapkan secara acak, terdapat peluang independen ~93% untuk mendeteksi bug saat bug tersebut terjadi lagi.
Nilai tag dapat dilihat di bidang alamat kesalahan serta di register dump, seperti yang disorot di bawah. Bagian ini dapat digunakan untuk memeriksa apakah tag disetel dengan cara yang wajar, serta untuk melihat alokasi memori terdekat lainnya dengan nilai tag yang sama karena tag tersebut dapat menjadi penyebab potensial kesalahan di luar yang tercantum dalam laporan. Kami berharap hal ini terutama bermanfaat bagi orang-orang yang bekerja pada penerapan MTE itu sendiri atau komponen sistem tingkat rendah lainnya, dibandingkan bagi pengembang.
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
Bagian khusus "Tag memori" juga muncul di laporan kerusakan yang menunjukkan tag memori di sekitar alamat kesalahan. Pada contoh di bawah, tag penunjuk "4" tidak cocok dengan tag memori "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
Bagian dari batu nisan yang memperlihatkan isi memori di sekitar semua nilai register juga menampilkan nilai tagnya.
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 ..'.}...........