Kod 9 (SEGV_MTESERR) veya kod 8 (SEGV_MTEAERR) olan SIGSEGV kilitlenmeleri, Bellek Etiketleme hatalarıdır. Bellek Etiketleme Uzantısı (MTE), Armv9 özelliği Android 12 ve sonraki sürümlerde desteklenir. MTE, etiketli bir donanımın uygulanmasıdır. hafızada bulabilirsiniz. Sorunların algılanması ve azaltılması için ayrıntılı bellek koruması sunar. bellek güvenliği hataları var.
C/C++ ürününde, Malloc() veya new() operatörü ya da benzer işlevlere yapılan bir çağrıdan döndürülen işaretçi yalnızca bu ayırma sınırları içindeki belleğe erişmek için ve yalnızca tahsisin aktif olup olmadığı (serbest bırakılmış veya silinmiş değil). MTE, Android'de şu ihlallerin tespit edilmesi için kullanılır: kilitlenme raporlarında "Arabellek Taşması"/"Arabellek Altı" ve "Ücretsiz Sonrasında Kullan" sorunları.
MTE'nin iki modu vardır: eşzamanlı (veya "senkronize") ve eşzamansız (ya da "eş zamansız"). Birincisi daha çok ancak daha doğru teşhisler sağlar. İkincisi daha hızlı çalışır, ancak yaklaşık olarak belirleyin. Teşhisler biraz farklı olduğu için her ikisini de ayrı ayrı ele alacağız.
Eşzamanlı mod MTE'si
MTE'nin eşzamanlı ("senkronizasyon") modunda, SIGSEGV kodu 9 (SEGV_MTESERR) ile kilitlenir.
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ı, algılandı. "Neden:" MTE tarafından algılanan hataya ilişkin satırda "[MTE]" ifadesi bulunur olduğu gibi yukarıdaki örneğe bakın. Bu örnekte, tespit edilen belirli hata türü "Ücretsiz olduktan sonra kullan" ve "0x7ae92853a0'da 32 baytlık ayırmaya 0 bayt" bize ayırmanın boyutu ve adresi ve erişmeye çalıştığımız ayırmaya göre uzaklık.
MTE kilitlenme raporları da yalnızca algılama aşamasından gelen geri izlemeleri değil, ekstra geri izleri de içerir.
"Ücretsiz Sonrasında Kullan" hatalar "ayıran" işlemini ekler ve "ayıran" bölümleri içine alırsınız. bu belleğin dağıtıldığı andaki (kullanılmadan önce!) yığın izlemelerini ne kadar zaman ayrıldığını gösterir. Bunlar, hangi ileti dizisinin tahsis etme anlamına gelir. İş parçacığı algılama, iş parçacığı ayırma ve ayırma işlemlerinin üçü de iş parçacığı bu basit örnekte aynıdır, ancak daha karmaşık gerçek yaşam örneklerinde ama farklı olduklarını bilmek, bir fikri bulma ve ona ilgili hata oluştu.
"Tampon Taşması" ve "Buffer Underflow" hatalar yalnızca ek bir "ayrılan" değeri sağlar yığın izleme, tanımı gereği henüz ayrılmamıştır (veya "Ücretsiz Sonrasında Kullan"):
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 32-byte allocation at 0x7ae92853a0 [...] backtrace: [...] allocated by thread 13949:.
"Sağ" kelimesinin kullanımına dikkat edin şu anlama gelir: Bu, size başından kaç baytın geçtiğini tahsis edilen 10.000'e ulaştı. alttan gelen bir akışta "left" (sol) söylenir ve bayt miktarının arttığı anlamına gelir.
Birden çok olası neden
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 durum, hata kaynağı için birkaç iyi aday olduğunda ortaya çıkar ve bunu söyleyemeyiz. asıl sorun budur. Bu tür adaylardan en fazla 3 tanesini, yaklaşık olarak olasılıklanlık sırasına göre sıralarız. ve analizi kullanıcıya bırakın.
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 son zamanlarda yapılmış iki ayırma algılandı: geçersiz bellek erişiminin amaçlanan hedefi olduğundan emin olun. Bu durum, ayırmalar yeniden kullanıldığında ortaya çıkabilir kullanılabilir; örneğin, yeni, ücretsiz, yeni, ücretsiz, yeni, ücretsiz, erişim. Önce en yeni tahsis yazdırılır.
Ayrıntılı neden belirleme bulguları
"Neden" bir kilitlenmenin, erişilen işaretçinin orijinal olarak türetildiği bellek tahsisini göstermesi gerekir. Maalesef MTE donanımının, eşleşmeyen etiketi olan bir işaretçiden ayırmaya aktarma yöntemi yoktur. Android, bir SEGV_MTESERR kilitlenmesini açıklamak için aşağıdaki verileri analiz eder:
- Hata adresi (işaretçi etiketi dahil).
- Yığın izlemeler ve bellek etiketleriyle son yığın ayırmaların listesi.
- Yakındaki mevcut (yayındaki) ayırmalar ve bunların bellek etiketleri.
Bellek etiketinin hata adresi etiketiyle eşleştiği hata adresinde yakın zamanda tahsis edilmiş bellek, potansiyel bir "Boşaltıldıktan Sonra Kullan" olabilir pek çok yolu vardır.
Bellek etiketinin hata adresi etiketiyle eşleştiği yakındaki herhangi bir canlı bellek, potansiyel bir "Arabellek Taşması"dır (veya "Tampon Altı") bir neden olabilir.
Zamanda ya da uzayda hataya daha yakın olan paylaştırmaların, uzaktakilere göre daha yüksek olasılıkla yapıldığı kabul edilir.
Ayrılan bellek genellikle yeniden kullanıldığından ve farklı etiket değerlerinin sayısı az olduğundan (16'dan az) birkaç olası aday bulmak olağan dışı değildir ve gerçek nedeni otomatik olarak bulmanın bir yolu yoktur. MTE raporlarında bazen birden çok olası nedenin listelenmesinin nedeni budur.
Uygulama geliştiricinin, en olası nedenden başlayarak olası nedenlere bakması önerilir. Yığın izlemeye göre alakasız nedenleri filtrelemek genellikle kolaydır.
Eşzamansız mod MTE'si
MTE'nin eşzamansız ("eş zamansız") modunda, SIGSEGV kodu 8 (SEGV_MTEAERR) ile kilitlenir.
Bir program geçersiz bellek erişimi gerçekleştirdiğinde SEGV_MTEAERR hataları hemen oluşmaz. Sorun etkinlikten kısa bir süre sonra tespit edilir ve bu noktada program sonlandırılır. Bu nokta genellikle bir sonraki sistem çağrısıdır ancak aynı zamanda bir zamanlayıcı kesintisi de (kısacası, kullanıcı alanından çekirdeğe geçiş) olabilir.
SEGV_MTEAERR hataları bellek adresini korumaz (her zaman "-------" olarak gösterilir). Geri izleme, geçersiz erişimin gerçekleştirildiği zamana değil, koşulun algılandığı ana karşılık gelir (ör. sonraki sistem çağrısında veya başka bir bağlam anahtarında).
Bu, "ana" eşzamansız bir MTE kilitlenmesinde geri izleme genellikle alakasızdır. Bu nedenle, eşzamansız mod hataları için hata ayıklama işlemi, senkronizasyon modundaki hatalardan çok daha zordur. Bunlar en iyi şekilde, belirtilen iş parçacığındaki yakındaki kodda bir bellek hatasının bulunduğunu gösteriyordur. Tombstone dosyasının altındaki günlükler gerçekte ne olduğuna dair ipucu verebilir. Aksi takdirde, önerilen işlem, hatayı senkronizasyon modunda yeniden oluşturmak ve senkronizasyon modunun sağladığı daha iyi teşhisleri kullanmaktır!
İleri düzey konular
Temel olarak bellek etiketlemesi, her yığın tahsisine rastgele bir 4 bit (0..15) etiket değeri atayarak çalışır. Bu değer, ayrılan yığın belleğine karşılık gelen özel bir meta veri bölgesinde depolanır. Malloc() veya new() operatörü gibi işlevlerden döndürülen yığın işaretçisinin en önemli baytına aynı değer atanır.
İşlemde etiket kontrolü etkinleştirildiğinde CPU, her bellek erişimi için işaretçinin en üst baytını bellek etiketiyle otomatik olarak karşılaştırır. Etiketler eşleşmezse CPU, kilitlenmeye yol açan bir hata bildirir.
Olası etiket değerlerinin sayısı sınırlı olduğundan bu yaklaşım olasıdır. Belirli bir işaretçiyle erişilmemesi gereken bellek konumlarının (sınır dışında veya dağıtımdan sonra ("sarkan işaretçi") gibi) farklı bir etiket değeri olabilir ve kilitlenmeye neden olabilir. Tek bir hatanın tespit edilmemesi ihtimali yaklaşık% 7'dir. Etiket değerleri rastgele atandığı için hatanın bir sonraki oluşumunda tespit edilme olasılığı yaklaşık% 93 bağımsızdır.
Etiket değerleri, aşağıda vurgulanan hata 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 ayarlanıp ayarlanmadığını kontrol etmek için kullanılabilir. Ayrıca, raporda listelenenlerin dışında hatanın olası nedenleri olabileceğinden, aynı etiket değerine sahip yakındaki diğer bellek ayırmalarını görmek için kullanılabilir. Bu aracın, geliştiriciler yerine özellikle MTE'nin veya diğer alt düzey sistem bileşenlerinin uygulanması üzerinde çalışan kişiler için yararlı 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
Özel bir "Bellek etiketleri" bölümü de hata adresinin çevresindeki bellek etiketlerini gösteren kilitlenme raporunda 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
Bir mezar taşının, tüm kayıt değerlerinin etrafında bellek içeriklerini gösteren bölümleri de kendi etiket değerlerini gösterir.
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 ..'.}...........