Kol Bellek Etiketleme Uzantısı (MTE)

Neden MTE?

Yerel programlama dillerinde belleğin işlenmesiyle ilgili hatalar olan bellekle ilgili güvenlik hataları, yaygın kod sorunlarıdır. Bu durum, güvenlik açıklarına ve kararlılık sorunlarına yol açar.

Armv9, yerel kodunuzdaki boşaltıldıktan sonra kullanım ve arabellek taşması hatalarını yakalamanıza olanak tanıyan bir donanım uzantısı olan Arm Memory Tagging Extension'ı (MTE) tanıttı.

Destek olup olmadığını kontrol etme

Android 13'ten itibaren belirli cihazlarda MTE desteği sunulmaktadır. Cihazınızın MTE etkin olarak çalışıp çalışmadığını kontrol etmek için aşağıdaki komutu çalıştırın:

adb shell grep mte /proc/cpuinfo

Sonuç Features : [...] mte ise cihazınız MTE etkin olarak çalışıyordur.

Bazı cihazlarda MTE varsayılan olarak etkinleştirilmez ancak geliştiricilerin MTE etkin olarak yeniden başlatmasına izin verilir. Bu deneysel yapılandırma, cihazın performansını veya kararlılığını düşürebileceğinden normal kullanım için önerilmez ancak uygulama geliştirme için faydalı olabilir. Bu moda erişmek için Ayarlar uygulamanızda Geliştirici Seçenekleri > Bellek Etiketleme Uzantısı'na gidin. Bu seçenek yoksa cihazınız MTE'nin bu şekilde etkinleştirilmesini desteklemiyor demektir.

MTE desteği olan cihazlar

Aşağıdaki cihazların MTE'yi desteklediği bilinmektedir:

  • Pixel 8 (Shiba)
  • Pixel 8 Pro (Husky)
  • Pixel 8a (Akita)
  • Pixel 9 (Tokay)
  • Pixel 9 Pro (Caiman)
  • Pixel 9 Pro XL (Komodo)
  • Pixel 9 Pro Fold (Comet)
  • Pixel 9a (Tegu)

MTE çalışma modları

MTE iki modu destekler: SYNC ve ASYNC. SYNC modu daha iyi teşhis bilgileri sağlar ve bu nedenle geliştirme amaçlarına daha uygundur. ASYNC modu ise yüksek performansa sahiptir ve yayınlanmış uygulamalarda etkinleştirilebilir.

Eşzamanlı mod (SYNC)

Bu mod, performans yerine hata ayıklanabilirliğe göre optimize edilmiştir ve daha yüksek performans yükü kabul edilebilir olduğunda hassas bir hata algılama aracı olarak kullanılabilir. Etkinleştirildiğinde MTE SYNC, güvenlik azaltma işlevi de görür.

Etiket uyuşmazlığı durumunda işlemci, SIGSEGV (si_code SEGV_MTESERR ile) ile hatalı yükleme veya depolama talimatındaki işlemi sonlandırır ve bellek erişimi ile hatalı adres hakkında tam bilgi verir.

Bu mod, test sırasında HWASan'a göre daha hızlı bir alternatif olarak kullanışlıdır. Kodunuzu yeniden derlemenizi gerektirmez. Ayrıca, uygulamanız savunmasız bir saldırı yüzeyini temsil ettiğinde üretimde de kullanılabilir. Ayrıca, ASYNC modunda (aşağıda açıklanmıştır) bir hata bulunduğunda, yürütmeyi SYNC moduna geçirmek için çalışma zamanı API'leri kullanılarak doğru bir hata raporu alınabilir.

Ayrıca, SYNC modunda çalışırken Android ayırıcı, her ayırma ve serbest bırakma işleminin yığın izlemesini kaydeder ve bunları, boşaltıldıktan sonra kullanım veya arabellek taşması gibi bir bellek hatasının açıklamasını ve ilgili bellek etkinliklerinin yığın izlemelerini içeren daha iyi hata raporları sağlamak için kullanır (daha fazla bilgi için MTE raporlarını anlama başlıklı makaleye bakın). Bu tür raporlar, ASYNC moduna kıyasla daha fazla bağlamsal bilgi sağlar ve hataların izlenip düzeltilmesini kolaylaştırır.

Eşzamansız mod (ASYNC)

Bu mod, hata raporlarının doğruluğundan ziyade performans için optimize edilmiştir ve bellek güvenliği hatalarının düşük ek yükle tespiti için kullanılabilir. Etiket uyuşmazlığı durumunda işlemci, en yakın çekirdek girişine (ör. syscall veya zamanlayıcı kesmesi) kadar yürütmeye devam eder. Burada, hataya neden olan adresi veya bellek erişimini kaydetmeden işlemi SIGSEGV (kod SEGV_MTEAERR) ile sonlandırır.

Bu mod, test sırasında SYNC modu kullanılarak elde edilen ve bellek güvenliği hatalarının yoğunluğunun düşük olduğu bilinen, iyi test edilmiş kod tabanlarında üretimdeki bellek güvenliği açıklarını azaltmak için kullanışlıdır.

MTE'yi etkinleştirme

Tek bir cihaz için

Deneme için, uygulama uyumluluğu değişiklikleri, manifestte herhangi bir değer belirtmeyen (veya "default" belirten) bir uygulama için memtagMode özelliğinin varsayılan değerini ayarlamak üzere kullanılabilir.

Bu ayarları, genel ayar menüsündeki Sistem > Gelişmiş > Geliştirici seçenekleri > Uygulama Uyumluluğuyla İlgili Değişiklikler bölümünde bulabilirsiniz. NATIVE_MEMTAG_ASYNC veya NATIVE_MEMTAG_SYNC ayarı, belirli bir uygulama için MTE'yi etkinleştirir.

Alternatif olarak, bu ayar am komutu kullanılarak aşağıdaki şekilde ayarlanabilir:

  • SYNC modu için: $ adb shell am compat enable NATIVE_MEMTAG_SYNC my.app.name
  • ASYNC modu için: $ adb shell am compat enable NATIVE_MEMTAG_ASYNC my.app.name

Gradle'da

Gradle projenizin tüm hata ayıklama derlemeleri için MTE'yi etkinleştirebilirsiniz. Bunun için

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <application android:memtagMode="sync" tools:replace="android:memtagMode"/>
</manifest>

app/src/debug/AndroidManifest.xml içine. Bu işlem, hata ayıklama derlemeleri için manifest dosyanızdaki memtagMode öğesini senkronizasyonla geçersiz kılar.

Alternatif olarak, özel bir buildType'ın tüm derlemeleri için MTE'yi etkinleştirebilirsiniz. Bunu yapmak için kendi buildType'ınızı oluşturun ve XML'yi app/src/<name of buildType>/AndroidManifest.xml içine yerleştirin.

Herhangi bir uygun cihazdaki APK için

MTE varsayılan olarak devre dışıdır. MTE'yi kullanmak isteyen uygulamalar, android:memtagMode değerini <application> veya <process> etiketinin altına AndroidManifest.xml olarak ayarlayarak bunu yapabilir.

android:memtagMode=(off|default|sync|async)

<application> etiketinde ayarlandığında özellik, uygulama tarafından kullanılan tüm işlemleri etkiler ve <process> etiketi ayarlanarak tek tek işlemler için geçersiz kılınabilir.

Enstrümantasyonla geliştirme

Daha önce açıklandığı gibi MTE'yi etkinleştirmek, yerel yığında bellek bozulması hatalarının algılanmasına yardımcı olur. Yığında bellek bozulmasını tespit etmek için uygulamada MTE'yi etkinleştirmenin yanı sıra kodun enstrümantasyonla yeniden oluşturulması gerekir. Sonuç olarak elde edilen uygulama yalnızca MTE özellikli cihazlarda çalışır.

Uygulamanızın yerel (JNI) kodunu MTE ile oluşturmak için aşağıdakileri yapın:

ndk-build

Application.mk dosyanızda:

APP_CFLAGS := -fsanitize=memtag -fno-omit-frame-pointer -march=armv8-a+memtag
APP_LDFLAGS := -fsanitize=memtag -fsanitize-memtag-mode=sync -march=armv8-a+memtag

CMake

CMakeLists.txt dosyanızdaki her hedef için:

target_compile_options(${TARGET} PUBLIC -fsanitize=memtag -fno-omit-frame-pointer -march=armv8-a+memtag)
target_link_options(${TARGET} PUBLIC -fsanitize=memtag -fsanitize-memtag-mode=sync -march=armv8-a+memtag)

Uygulamanızı çalıştırma

MTE'yi etkinleştirdikten sonra uygulamanızı normal şekilde kullanın ve test edin. Bellek güvenliği sorunu algılanırsa uygulamanız aşağıdaki gibi bir hata mesajıyla kilitlenir (SYNC için SIGSEGV ile SEGV_MTESERR, ASYNC için SEGV_MTEAERR ile SIGSEGV arasındaki farka dikkat edin):

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)
Learn more about MTE reports: https://source.android.com/docs/security/test/memory-safety/mte-report

Daha fazla bilgi için AOSP dokümanlarındaki Understanding MTE reports (MTE raporlarını anlama) başlıklı makaleyi inceleyin. Ayrıca Android Studio ile uygulamanızda hata ayıklayabilirsiniz. Hata ayıklayıcı, geçersiz bellek erişimine neden olan satırda durur.

İleri Düzey Kullanıcılar: Kendi ayırıcınızda MTE'yi kullanma

Normal sistem ayırıcıları aracılığıyla ayrılmayan bellek için MTE'yi kullanmak istiyorsanız ayırıcınızı belleği ve işaretçileri etiketleyecek şekilde değiştirmeniz gerekir.

Ayırıcınızın sayfaları, mmap (veya mprotect) prot işaretinde PROT_MTE kullanılarak ayrılmalıdır.

Etiketler yalnızca 16 baytlık parçalara (granüller olarak da bilinir) atanabildiğinden, etiketlenen tüm ayırmaların 16 baytlık hizalamaya sahip olması gerekir.

Ardından, bir işaretçi döndürmeden önce IRG talimatını kullanarak rastgele bir etiket oluşturmanız ve bunu işaretçide saklamanız gerekir.

Temel belleği etiketlemek için aşağıdaki talimatları uygulayın:

  • STG: 16 baytlık tek bir granülü etiketleme
  • ST2G: 16 baytlık iki granül etiketleyin
  • DC GVA: Önbellek satırını aynı etiketle etiketleme

Alternatif olarak, aşağıdaki talimatlar da belleği sıfırla başlatır:

  • STZG: tek bir 16 baytlık granülü etiketleme ve sıfırla başlatma
  • STZ2G: etiketi ve iki 16 baytlık granülü sıfırla başlatır.
  • DC GZVA: Önbellek satırını aynı etiketle etiketleme ve sıfırla başlatma

Bu talimatların eski CPU'larda desteklenmediğini unutmayın. Bu nedenle, MTE etkinleştirildiğinde bunları koşullu olarak çalıştırmanız gerekir. MTE'nin işleminizde etkin olup olmadığını kontrol edebilirsiniz:

#include <sys/prctl.h>

bool runningWithMte() {
      int mode = prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0);
      return mode != -1 && mode & PR_MTE_TCF_MASK;
}

Referans olarak scudo uygulamasından yararlanabilirsiniz.

Daha fazla bilgi

Daha fazla bilgiyi Arm tarafından yazılan Android OS için MTE Kullanıcı Rehberi'nde bulabilirsiniz.