SIGSEGV kod 9 (SEGV_MTESERR) veya kod 8 (SEGV_MTEAERR) ile çökmeler Bellek Etiketleme hatalarıdır. Bellek Etiketleme Uzantısı (MTE), Android 12 ve sonraki sürümlerde desteklenen bir Armv9 özelliğidir. MTE, etiketli belleğin donanım uygulamasıdır. Bellek güvenliği hatalarının tespiti ve azaltılması için ayrıntılı bellek koruması sağlar.
C/C++'da, malloc() veya new() operatörüne veya benzer işlevlere yapılan bir çağrıdan döndürülen bir işaretçi, yalnızca söz konusu tahsisin sınırları dahilindeki belleğe erişmek için ve yalnızca tahsis canlıyken (serbest veya serbest değilken) kullanılabilir. sil-ed). MTE, Android'de, kilitlenme raporlarında "Arabellek Taşması"/"Arabellek Yetersizliği" ve "Serbest Sonra Kullan" sorunları olarak anılan bu kuralın ihlallerini tespit etmek için kullanılır.
MTE'nin iki modu vardır: eşzamanlı (veya "senkronizasyon") ve eşzamansız (veya "eşzamansız"). İlki daha yavaş çalışır ancak daha doğru teşhis sağlar. İkincisi daha hızlı çalışır ancak yalnızca yaklaşık ayrıntıları verebilir. Tanılamalar biraz farklı olduğundan her ikisini de ayrı ayrı ele alacağız.
Senkron mod MTE
MTE'nin senkronize ("senkronizasyon") modunda, SIGSEGV kod 9 (SEGV_MTESERR) ile çöküyor.
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üm MTE kilitlenme raporları, sorunun tespit edildiği noktaya ilişkin olağan kayıt dökümü ve geri izlemeyi içerir. MTE tarafından tespit edilen bir hatanın "Neden:" satırı, yukarıdaki örnekte olduğu gibi "[MTE]" ifadesini ve daha fazla ayrıntıyı içerecektir. Bu durumda, tespit edilen spesifik hata türü "Ücretsiz olduktan sonra kullan" idi ve "0x7ae92853a0'da 32 baytlık tahsise 0 bayt" bize tahsisin boyutunu ve adresini ve tahsis ettiğimiz tahsisin uzaklığını söyler. erişmeye çalıştı.
MTE kilitlenme raporları ayrıca yalnızca tespit noktasından gelenleri değil, ekstra geriye dönük izleri de içerir.
"Serbest Bıraktıktan Sonra Kullan" hataları, kilitlenme dökümüne "tahsisi kaldırılan" ve "tarafından ayrılan" bölümleri ekleyerek, bu belleğin serbest bırakıldığı andaki (kullanılmadan önce!) ve daha önce tahsis edildiği zamanı gösteren yığın izlerini gösterir. Bunlar aynı zamanda tahsis/dağıtmayı hangi iş parçacığının yaptığını da gösterir. Bu basit örnekte tespit eden iş parçacığı, tahsis eden iş parçacığı ve serbest bırakma iş parçacığının üçü de aynıdır, ancak daha karmaşık gerçek dünya durumlarında bu mutlaka doğru değildir ve bunların farklı olduğunu bilmek bir eşzamanlılık bulmada önemli bir ipucu olabilir -ilgili hata.
"Arabellek Taşması" ve "Arabellek Yetersizliği" hataları yalnızca ek bir "tahsis edilen" yığın yolu sağlar, çünkü tanım gereği henüz tahsis edilmemiştir (veya "Serbest Sonra Kullan" olarak görünürler):
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 32-byte allocation at 0x7ae92853a0 [...] backtrace: [...] allocated by thread 13949:
Burada "doğru" kelimesinin kullanıldığına dikkat edin: bu, size yanlış erişimin tahsisin sonundan kaç bayt geçtiğini söylediğimiz anlamına gelir; bir yetersiz akış "sol" der ve tahsisin başlangıcından önceki bayt sayısıdır.
Çoklu potansiyel nedenler
Bazen SEGV_MTESERR raporları aşağıdaki satırı içerir:
Note: multiple potential causes for this crash were detected, listing them in decreasing order of likelihood.
Bu, hatanın kaynağı için birden fazla iyi adayın olduğu ve asıl nedenin hangisi olduğunu söyleyemediğimiz durumlarda meydana gelir. Yaklaşık olasılık sırasına göre bu türden en fazla 3 aday yazdırıyoruz ve analizi kullanıcıya bırakıyoruz.
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...]Yukarıdaki örnekte, aynı bellek adresinde, geçersiz bellek erişiminin amaçlanan hedefi olabilecek iki yeni tahsis tespit ettik. Bu, tahsisler boş hafızayı yeniden kullandığında meydana gelebilir; örneğin, yeni, ücretsiz, yeni, ücretsiz, yeni, ücretsiz, erişim gibi bir diziniz varsa. Daha yeni tahsis ilk olarak yazdırılır.
Ayrıntılı neden belirleme buluşsal yöntemi
Bir kilitlenmenin "Nedeni", erişilen işaretçinin orijinal olarak türetildiği bellek tahsisini göstermelidir. Ne yazık ki, MTE donanımının eşleşmeyen etikete sahip bir işaretçiyi tahsise çevirme yolu yoktur. SEGV_MTESERR çökmesini açıklamak için Android aşağıdaki verileri analiz eder:
- Arıza adresi (işaretçi etiketi dahil).
- Yığın izlemeleri ve bellek etiketlerini içeren son yığın tahsislerinin listesi.
- Yakındaki mevcut (canlı) tahsisler ve bunların hafıza etiketleri.
Bellek etiketinin hata adresi etiketiyle eşleştiği, hata adresinde yakın zamanda tahsisi kaldırılan herhangi bir bellek, olası bir "Serbest Sonra Kullan" nedenidir.
Bellek etiketinin arıza adres etiketiyle eşleştiği yakındaki herhangi bir canlı bellek, potansiyel bir "Arabellek Taşması" (veya "Arabellek Yetersizliği") nedenidir.
Faya zaman veya mekan açısından daha yakın olan tahsislerin, uzak olanlara göre daha muhtemel olduğu kabul edilir.
Serbest bırakılan bellek sıklıkla yeniden kullanıldığından ve farklı etiket değerlerinin sayısı az olduğundan (16'dan az), birkaç olası adayın bulunması alışılmadık bir durum değildir ve gerçek nedeni otomatik olarak bulmanın bir yolu yoktur. Bazen MTE raporlarının birden fazla potansiyel nedeni listelemesinin nedeni budur.
Uygulama geliştiricisinin, en muhtemel olandan başlayarak potansiyel nedenlere bakması önerilir. Yığın izlemesine dayalı olarak ilgisiz nedenleri filtrelemek genellikle kolaydır.
Asenkron mod MTE
MTE'nin eşzamansız ("eşzamansız") modunda, SIGSEGV kod 8 (SEGV_MTEAERR) ile çöküyor.
SEGV_MTEAERR hataları, bir program geçersiz bir bellek erişimi gerçekleştirdiğinde hemen oluşmaz. Sorun, olaydan kısa bir süre sonra algılanır ve program bu noktada sonlandırılır. Bu nokta genellikle bir sonraki sistem çağrısıdır, ancak aynı zamanda bir zamanlayıcı kesintisi de olabilir, kısacası kullanıcı alanından çekirdeğe herhangi bir geçiş olabilir.
SEGV_MTEAERR hataları hafıza adresini korumaz (her zaman "----------" olarak gösterilir). Geri izleme, geçersiz erişimin gerçekleştirildiği zamana değil, koşulun tespit edildiği ana karşılık gelir (yani bir sonraki sistem çağrısında veya diğer bağlam anahtarında).
Bu, eşzamansız bir MTE çökmesindeki "ana" geri izlemenin genellikle konuyla ilgili olmadığı anlamına gelir. Bu nedenle, eşzamansız mod hatalarının hatalarını ayıklamak, eşitleme modu hatalarından çok daha zordur. Bunların en iyi şekilde, verilen iş parçacığında yakındaki kodda bir bellek hatasının varlığını gösterdiği anlaşılmaktadır. Mezar taşı dosyasının altındaki günlükler gerçekte ne olduğuna dair bir ipucu sağlayabilir. Aksi takdirde önerilen eylem şekli, hatayı senkronizasyon modunda yeniden oluşturmak ve senkronizasyon modunun sağladığı daha iyi tanılamayı kullanmaktır!
Gelişmiş konular
Temel olarak bellek etiketleme, her yığın tahsisine rastgele 4 bitlik (0..15) bir etiket değeri atayarak çalışır. Bu değer, tahsis edilen yığın belleğine karşılık gelen özel bir meta veri bölgesinde saklanır. Malloc() veya new() operatörü gibi işlevlerden dönen yığın işaretçisinin en anlamlı baytına aynı değer atanır.
Süreçte etiket kontrolü etkinleştirildiğinde CPU, her bellek erişimi için otomatik olarak işaretçinin üst baytını bellek etiketiyle karşılaştırır. Etiketler eşleşmezse CPU, çökmeye neden olan bir hata sinyali verir.
Olası etiket değerlerinin sınırlı sayıda olması nedeniyle bu yaklaşım olasılıksaldır. Belirli bir işaretçiyle erişilmemesi gereken herhangi bir bellek konumu (sınırların dışında veya serbest bırakma ("sarkan işaretçi") gibi) büyük olasılıkla farklı bir etiket değerine sahip olacak ve bir çökmeye neden olacaktır. Tek bir hatanın tespit edilememesi ihtimali ~%7'dir. Etiket değerleri rastgele atandığından, bir dahaki sefere hatanın tespit edilmesi için bağımsız olarak ~%93 şans vardır.
Etiket değerleri, aşağıda vurgulandığı gibi, arıza adresi alanının yanı sıra kayıt dökümünde de görülebilir. Bu bölüm, etiketlerin mantıklı bir şekilde ayarlandığını kontrol etmenin yanı sıra, aynı etiket değerine sahip yakındaki diğer bellek tahsislerini görmek için de kullanılabilir; çünkü bunlar, raporda listelenenlerin ötesinde hatanın potansiyel nedenleri olabilir. Bunun, geliştiricilerden ziyade esas olarak MTE'nin kendisinin veya diğer düşük seviyeli sistem bileşenlerinin uygulanması üzerinde çalışan kişiler için faydalı olmasını bekliyoruz.
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
Arıza adresinin etrafındaki hafıza etiketlerini gösteren kilitlenme raporunda özel bir "Hafıza etiketleri" bölümü de görünür. Aşağıdaki örnekte "4" işaretçi etiketi "a" bellek etiketiyle eşleşmedi.
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
Tüm kayıt değerleri etrafındaki bellek içeriğini gösteren bir mezar taşının bölümleri aynı zamanda etiket değerlerini de görüntüler.
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 ..'.}...........