आर्म मेमोरी टैगिंग एक्सटेंशन (एमटीई)

ध्यान दें: इस दस्तावेज़ में, MTE के तहत चल रहे Android ऐप्लिकेशन के बारे में बताया गया है. Android प्लैटफ़ॉर्म के डेवलपमेंट के लिए, MTE का इस्तेमाल करने के बारे में जानकारी पाने के लिए, AOSP दस्तावेज़ देखें.

अहम जानकारी: MTE, मेमोरी डीबग करने और समस्या को कम करने के लिए उपलब्ध कई टूल में से एक है. सभी टूल के बारे में खास जानकारी पाने के लिए, मेमोरी से जुड़ी गड़बड़ी को डीबग करना और कम करना लेख पढ़ें.

एमटीई क्यों?

कोड से जुड़ी आम समस्याएं, मेमोरी सेफ़्टी बग होती हैं. ये नेटिव प्रोग्रामिंग लैंग्वेज में मेमोरी को हैंडल करने से जुड़ी गड़बड़ियां होती हैं. इनकी वजह से, सुरक्षा से जुड़ी समस्याओं के साथ-साथ ऐप्लिकेशन के काम करने में भी समस्याएं आ सकती हैं.

Armv9 में Arm मेमोरी टैगिंग एक्सटेंशन (एमटीई) को पेश किया गया है. यह एक हार्डवेयर एक्सटेंशन है, जिसकी मदद से अपने नेटिव कोड में, फ़्री की गई मेमोरी को इस्तेमाल करने और बफ़र ओवरफ़्लो की गड़बड़ियों का पता लगाया जा सकता है.

सहायता देखें

Android 13 से, चुनिंदा डिवाइसों पर एमटीई की सुविधा काम करती है. यह देखने के लिए कि आपका डिवाइस, MTE की सुविधा चालू करके चल रहा है या नहीं, यह कमांड चलाएं:

adb shell grep mte /proc/cpuinfo

अगर नतीजा Features : [...] mte है, तो इसका मतलब है कि आपका डिवाइस MTE के साथ काम कर रहा है.

कुछ डिवाइसों पर एमटीई डिफ़ॉल्ट रूप से चालू नहीं होता. हालांकि, डेवलपर एमटीई चालू करके डिवाइस को रीबूट कर सकते हैं. यह एक्सपेरिमेंटल कॉन्फ़िगरेशन है. इसका सुझाव सामान्य इस्तेमाल के लिए नहीं दिया जाता, क्योंकि इससे डिवाइस की परफ़ॉर्मेंस या स्थिरता पर असर पड़ सकता है. हालांकि, यह ऐप्लिकेशन डेवलपमेंट के लिए काम का हो सकता है. इस मोड को ऐक्सेस करने के लिए, अपने Settings ऐप्लिकेशन में डेवलपर के विकल्प > मेमोरी टैगिंग एक्सटेंशन पर जाएं. अगर यह विकल्प मौजूद नहीं है, तो इसका मतलब है कि आपके डिवाइस पर इस तरह से एमटीई चालू नहीं किया जा सकता.

MTE की सुविधा वाले डिवाइस

इन डिवाइसों पर एमटीई काम करता है:

• Pixel 8 (Shiba)
• Pixel 8 Pro (हस्की)
• Pixel 8a (Akita)
• Pixel 9 (Tokay)
• Pixel 9 Pro (Caiman)
• Pixel 9 Pro XL (Komodo)
• Pixel 9 Pro Fold (Comet)
• Pixel 9a (Tegu)

MTE के ऑपरेटिंग मोड

MTE के दो मोड हैं: सिंक और असिंक. सिंक मोड, गड़बड़ी की बेहतर जानकारी देता है. इसलिए, यह डेवलपमेंट के मकसद से ज़्यादा सही है. वहीं, असिंक्रोनस मोड की परफ़ॉर्मेंस बेहतर होती है. इसलिए, इसे रिलीज़ किए गए ऐप्लिकेशन के लिए चालू किया जा सकता है.

सिंक्रोनस मोड (SYNC)

इस मोड को परफ़ॉर्मेंस के बजाय, डीबग करने के लिए ऑप्टिमाइज़ किया गया है. साथ ही, ज़्यादा परफ़ॉर्मेंस ओवरहेड के मामले में, इसका इस्तेमाल बग का सटीक पता लगाने वाले टूल के तौर पर किया जा सकता है. चालू होने पर, एमटीई सिंक, सुरक्षा को कम करने वाले उपाय के तौर पर भी काम करता है.

टैग मैच न होने पर, प्रोसेसर उस लोड या स्टोर निर्देश पर प्रोसेस को बंद कर देता है जिसमें गड़बड़ी हुई है. इसके लिए, वह SIGSEGV (si_code SEGV_MTESERR के साथ) का इस्तेमाल करता है. साथ ही, मेमोरी ऐक्सेस और गड़बड़ी वाले पते के बारे में पूरी जानकारी देता है.

यह मोड, टेस्टिंग के दौरान HWASan के तेज़ विकल्प के तौर पर काम आता है. इसके लिए, आपको अपने कोड को फिर से कंपाइल करने की ज़रूरत नहीं होती. इसके अलावा, यह प्रोडक्शन में भी काम आता है, जब आपका ऐप्लिकेशन अटैक के लिए संवेदनशील हो. इसके अलावा, जब ASYNC मोड (इसके बारे में नीचे बताया गया है) में कोई गड़बड़ी मिलती है, तो रनटाइम एपीआई का इस्तेमाल करके, गड़बड़ी की सटीक रिपोर्ट हासिल की जा सकती है. इसके लिए, एपीआई को सिंक मोड में स्विच करके, प्रोसेस को पूरा करना होगा.

इसके अलावा, सिंक मोड में चलने पर, Android एलोकेटर हर एलोकेशन और डिएलोकेशन का स्टैक ट्रेस रिकॉर्ड करता है. साथ ही, इनका इस्तेमाल करके गड़बड़ी की बेहतर रिपोर्ट उपलब्ध कराता है. इन रिपोर्ट में, मेमोरी से जुड़ी गड़बड़ी की जानकारी शामिल होती है. जैसे, फ़्री की गई मेमोरी को इस्तेमाल करने की गड़बड़ी या बफ़र ओवरफ़्लो. साथ ही, इनमें काम के मेमोरी इवेंट के स्टैक ट्रेस भी शामिल होते हैं. ज़्यादा जानकारी के लिए, MTE रिपोर्ट को समझना लेख पढ़ें. ऐसी रिपोर्ट से, संदर्भ के हिसाब से ज़्यादा जानकारी मिलती है. साथ ही, इनसे गड़बड़ियों को ट्रैक करना और ठीक करना, एसिंक्रोनस मोड की तुलना में आसान हो जाता है.

एसिंक्रोनस मोड (ASYNC)

यह मोड, गड़बड़ी की रिपोर्ट की सटीक जानकारी देने के बजाय, परफ़ॉर्मेंस के लिए ऑप्टिमाइज़ किया गया है. इसका इस्तेमाल, मेमोरी से जुड़ी सुरक्षा से जुड़ी गड़बड़ियों का पता लगाने के लिए किया जा सकता है. टैग मैच न होने पर, प्रोसेसर तब तक प्रोग्राम को चलाता रहता है, जब तक कि वह नज़दीकी कर्नेल एंट्री (जैसे, सिस्टम कॉल या टाइमर इंटरप्ट) तक नहीं पहुंच जाता. वहां पहुंचने के बाद, वह गड़बड़ी वाले पते या मेमोरी ऐक्सेस को रिकॉर्ड किए बिना, SIGSEGV (कोड SEGV_MTEAERR) के साथ प्रोसेस को बंद कर देता है.

यह मोड, अच्छी तरह से टेस्ट किए गए कोडबेस पर, प्रोडक्शन में मेमोरी से जुड़ी सुरक्षा से जुड़ी कमजोरियों को कम करने के लिए मददगार होता है. ऐसा इसलिए होता है, क्योंकि मेमोरी से जुड़ी सुरक्षा से जुड़े बग की संख्या कम होती है. यह संख्या कम करने के लिए, टेस्टिंग के दौरान सिंक मोड का इस्तेमाल किया जाता है.

एमटीई चालू करना

किसी एक डिवाइस के लिए

एक्सपेरिमेंट के लिए, ऐप्लिकेशन के साथ काम करने के लिए किए गए बदलावों का इस्तेमाल, किसी ऐसे ऐप्लिकेशन के लिए memtagMode एट्रिब्यूट की डिफ़ॉल्ट वैल्यू सेट करने के लिए किया जा सकता है जो मेनिफ़ेस्ट में कोई वैल्यू नहीं बताता है (या "default" बताता है).

ये बदलाव, ग्लोबल सेटिंग मेन्यू में सिस्टम > बेहतर > डेवलपर के लिए सेटिंग और टूल > ऐप्लिकेशन के साथ काम करने की सुविधा में हुए बदलाव में देखे जा सकते हैं. NATIVE_MEMTAG_ASYNC या NATIVE_MEMTAG_SYNC सेट करने पर, किसी खास ऐप्लिकेशन के लिए एमटीई चालू हो जाता है.

इसके अलावा, am कमांड का इस्तेमाल करके भी इसे सेट किया जा सकता है. इसके लिए, यह तरीका अपनाएं:

• सिंक मोड के लिए: $ adb shell am compat enable NATIVE_MEMTAG_SYNC my.app.name
• एसिंक मोड के लिए: $ adb shell am compat enable NATIVE_MEMTAG_ASYNC my.app.name

Gradle में

अपने Gradle प्रोजेक्ट के सभी डीबग बिल्ड के लिए एमटीई को चालू किया जा सकता है. इसके लिए,

<?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 इससे, डीबग बिल्ड के लिए सिंक करने की सुविधा, आपके मेनिफ़ेस्ट के memtagMode को बदल देगी.

इसके अलावा, कस्टम buildType के सभी बिल्ड के लिए एमटीई को चालू किया जा सकता है. ऐसा करने के लिए, अपना buildType बनाएं और एक्सएमएल को app/src/<name of buildType>/AndroidManifest.xml में डालें.

किसी भी डिवाइस पर APK के लिए

एमटीई की सुविधा डिफ़ॉल्ट रूप से बंद रहती है. MTE का इस्तेमाल करने वाले ऐप्लिकेशन, AndroidManifest.xml में <application> या <process> टैग के नीचे android:memtagMode सेट करके ऐसा कर सकते हैं.

चेतावनी: Play Store पर अपलोड करने से पहले, एमटीई की सुविधा वाले ऐप्लिकेशन की जांच, एमटीई के साथ काम करने वाले डिवाइस पर अच्छी तरह से कर लें. ऐसा न करने पर, सिर्फ़ MTE की सुविधा वाले डिवाइसों पर गंभीर गड़बड़ियां मिल सकती हैं. इससे ऐप्लिकेशन के इस्तेमाल पर असर पड़ सकता है.

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

<application> टैग पर सेट होने पर, एट्रिब्यूट का असर ऐप्लिकेशन की इस्तेमाल की जाने वाली सभी प्रोसेस पर पड़ता है. साथ ही, <process> टैग सेट करके, अलग-अलग प्रोसेस के लिए इसे बदला जा सकता है.

इंस्ट्रूमेंटेशन की मदद से बनाए गए ऐप्लिकेशन

अहम जानकारी: MTE इंस्ट्रूमेंटेशन की मदद से बनाए गए ऐप्लिकेशन, सिर्फ़ डीबग करने के लिए हैं.

ध्यान दें: MTE स्टैक टैगिंग की सुविधा, Android 14 QPR3 से उपलब्ध है.

MTE को चालू करने से, नेटिव हेप में मेमोरी में होने वाली गड़बड़ियों का पता चलता है. स्टैक में मेमोरी के खराब होने का पता लगाने के लिए, ऐप्लिकेशन के लिए एमटीई चालू करने के साथ-साथ, कोड को इंस्ट्रूमेंटेशन के साथ फिर से बनाना होगा. इससे तैयार किया गया ऐप्लिकेशन, सिर्फ़ MTE की सुविधा वाले डिवाइसों पर चलेगा.

अहम जानकारी: पक्का करें कि कोड बनाने के लिए, अप-टू-डेट NDK का इस्तेमाल किया जा रहा हो.

MTE की मदद से अपने ऐप्लिकेशन का नेटिव (JNI) कोड बनाने के लिए, यह तरीका अपनाएं:

ndk-build

अपनी Application.mk फ़ाइल में:

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 में मौजूद हर टारगेट के लिए:

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)

अपना ऐप्लिकेशन चलाएं

एमटीई चालू करने के बाद, अपने ऐप्लिकेशन का सामान्य तरीके से इस्तेमाल करें और उसकी जांच करें. अगर मेमोरी से जुड़ी सुरक्षा से जुड़ी कोई समस्या का पता चलता है, तो आपका ऐप्लिकेशन इस तरह के टॉम्बस्टोन के साथ क्रैश हो जाता है (ध्यान दें कि सिंक करने के लिए SIGSEGV के साथ SEGV_MTESERR या असाइन किए गए सिंक के लिए SEGV_MTEAERR का इस्तेमाल किया गया है):

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

ज़्यादा जानकारी के लिए, AOSP दस्तावेज़ में MTE रिपोर्ट को समझना देखें. Android Studio की मदद से अपने ऐप्लिकेशन को डीबग भी किया जा सकता है. डीबगर उस लाइन पर रुक जाता है जिसकी वजह से मेमोरी का अमान्य ऐक्सेस हो रहा है.

बेहतर उपयोगकर्ता: अपने एलोकेटर में एमटीई का इस्तेमाल करना

ध्यान दें: अगर आपको नहीं पता कि कस्टम ऐलोकेटर का इस्तेमाल किया जा रहा है, तो इस सेक्शन को छोड़ा जा सकता है.

सामान्य सिस्टम एलोकेटर के ज़रिए एलोकेट नहीं की गई मेमोरी के लिए MTE का इस्तेमाल करने के लिए, आपको मेमोरी और पॉइंटर को टैग करने के लिए अपने एलोकेटर में बदलाव करना होगा.

आपके एलोकेटर के लिए पेजों को mmap (या mprotect) के prot फ़्लैग में PROT_MTE का इस्तेमाल करके, एलोकेट किया जाना चाहिए.

टैग किए गए सभी ऐलोकेशन को 16-बाइट के हिसाब से अलाइन किया जाना चाहिए, क्योंकि टैग सिर्फ़ 16-बाइट वाले चंक (जिन्हें ग्रैनल भी कहा जाता है) के लिए असाइन किए जा सकते हैं.

इसके बाद, पॉइंटर दिखाने से पहले, आपको IRG निर्देश का इस्तेमाल करके, कोई रैंडम टैग जनरेट करना होगा और उसे पॉइंटर में सेव करना होगा.

मौजूदा मेमोरी को टैग करने के लिए, इन निर्देशों का पालन करें:

• STG: 16 बाइट के एक ग्रैनल को टैग करना
• ST2G: दो 16-बाइट ग्रैनल टैग करें
• DC GVA: एक ही टैग के साथ कैशलाइन को टैग करना

इसके अलावा, यहां दिए गए निर्देशों से भी मेमोरी को शून्य पर सेट किया जा सकता है:

• STZG: 16 बाइट के एक ग्रैनल को टैग करना और शून्य से शुरू करना
• STZ2G: दो 16-बाइट ग्रैनल को टैग करना और शून्य से शुरू करना
• DC GZVA: एक ही टैग का इस्तेमाल करके, कैशलाइन को टैग करना और शून्य से शुरू करना

ध्यान दें कि ये निर्देश पुराने सीपीयू पर काम नहीं करते. इसलिए, MTE चालू होने पर, आपको इन्हें शर्त के साथ चलाना होगा. यह देखा जा सकता है कि आपकी प्रोसेस के लिए, एमटीई चालू है या नहीं:

#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;
}

scudo को लागू करने से जुड़ी जानकारी, आपको रेफ़रंस के तौर पर मददगार हो सकती है.

ज़्यादा जानें

ज़्यादा जानकारी के लिए, Arm की लिखी Android OS के लिए एमटीई उपयोगकर्ता गाइड पढ़ें.