एमटीई क्यों?
मेमोरी की सुरक्षा से जुड़ी गड़बड़ियां, नेटिव प्रोग्रामिंग में मेमोरी को मैनेज करने में होने वाली गड़बड़ियां होती हैं भाषाएं, कोड से जुड़ी सामान्य समस्याएं हैं. इनसे सुरक्षा में जोखिम के साथ-साथ, स्थायित्व से जुड़ी समस्याएं हो सकती हैं.
Armv9 ने आर्म मेमोरी टैगिंग एक्सटेंशन (एमटीई) को लॉन्च किया. यह एक हार्डवेयर है ऐसा एक्सटेंशन जिसकी मदद से, आपका नेटिव कोड.
सहायता देखें
Android 13 और इसके बाद के वर्शन में, कुछ चुनिंदा डिवाइसों पर MTE का इस्तेमाल किया जा सकता है. यह देखने के लिए कि आपके डिवाइस में एमटीई चालू है या नहीं, नीचे दी गई क्वेरी को चलाएं आदेश:
adb shell grep mte /proc/cpuinfo
अगर नतीजा Features : [...] mte
है, तो आपका डिवाइस एमटीई के साथ काम कर रहा है
चालू किया गया.
कुछ डिवाइस डिफ़ॉल्ट रूप से एमटीई चालू नहीं करते. हालांकि, डेवलपर को फिर से चालू करने की अनुमति मिलती है. एमटीई चालू है. यह एक प्रयोग के तौर पर शुरू किया गया कॉन्फ़िगरेशन है. साथ ही, इसके लिए हम इसका सुझाव नहीं देते सामान्य इस्तेमाल के लिए किया जाता है, क्योंकि इससे डिवाइस की परफ़ॉर्मेंस या स्थिरता में कमी आ सकती है. हालांकि, और ऐप डेवलपमेंट में मदद करते हैं. इस मोड को ऐक्सेस करने के लिए, यहां जाएं डेवलपर के लिए सेटिंग और टूल > आपके Settings ऐप्लिकेशन में मौजूद मेमोरी टैगिंग एक्सटेंशन. अगर यह यह विकल्प मौजूद नहीं है, इसलिए आपके डिवाइस पर इस तरह से एमटीई को चालू नहीं किया जा सकता.
एमटीई के ऑपरेटिंग मोड
MTE के साथ दो मोड इस्तेमाल किए जा सकते हैं: SYNC और ASYNC. सिंक मोड, गड़बड़ी की बेहतर जानकारी देता है यह सुविधा, ASYNC मोड के साथ-साथ डेवलपमेंट के लिए भी बेहतर विकल्प है की परफ़ॉर्मेंस अच्छी है. इसलिए, इसे रिलीज़ किए गए ऐप्लिकेशन पर चालू किया जा सकता है.
सिंक्रोनस मोड (सिंक)
इस मोड को परफ़ॉर्मेंस के हिसाब से डीबग करने के लिए ऑप्टिमाइज़ किया गया है. साथ ही, ज़्यादा परफ़ॉर्मेंस का ओवरहेड होने पर, गड़बड़ी का पता लगाने वाले टूल के तौर पर इस्तेमाल किया जा सकता है स्वीकार किए जाते हैं. MTE सिंक को चालू करने पर, वह सुरक्षा से जुड़े जोखिमों को कम करने के लिए भी काम करता है.
टैग के मेल न खाने पर, प्रोसेसर आपत्तिजनक लोड होने पर प्रोसेस को खत्म कर देता है या SIGSEGV के साथ स्टोर का निर्देश (si_code SEGV_MTESERR के साथ) और पूरी जानकारी मेमोरी के ऐक्सेस और गड़बड़ी के पते के बारे में.
यह मोड, टेस्टिंग के दौरान HWASan की तुलना में ज़्यादा तेज़ विकल्प के तौर पर काम आता है इसके लिए, आपको अपने ऐप्लिकेशन को प्रोडक्शन में या कोड को फिर से कंपाइल करने की ज़रूरत नहीं होती. ऐसा तब होता है, जब ऐप्लिकेशन जो खतरनाक हमले की सतह को दिखाता है. इसके अलावा, जब ASYNC मोड (नीचे बताया गया है) को रनटाइम API का इस्तेमाल करके गड़बड़ी की सटीक रिपोर्ट मिल सकती है. सिंक मोड पर लागू किया जाता है.
इसके अलावा, सिंक मोड में चलाते समय, Android ऐलोकेटर हर ऐलोकेशन और डीललोकेशन का स्टैक ट्रेस और उनका इस्तेमाल बेहतर तरीके से करने के लिए किया जाता है गड़बड़ी की रिपोर्ट, जिनमें मेमोरी की गड़बड़ी के बारे में जानकारी शामिल होती है, जैसे का इस्तेमाल-आफ़्टर-फ़्री या बफ़र-ओवरफ़्लो और काम की मेमोरी के स्टैक ट्रेस इवेंट के बारे में ज़्यादा जानकारी पाने के लिए, एमटीई रिपोर्ट को समझना लेख पढ़ें. इस तरह रिपोर्ट में काम की ज़्यादा जानकारी मिलती है. साथ ही, इनसे गड़बड़ियों का पता लगाना और उन्हें को ASYNC मोड से ठीक नहीं किया जाता.
एसिंक्रोनस मोड (ASYNC)
इस मोड को गड़बड़ी की रिपोर्ट के सटीक होने के बजाय परफ़ॉर्मेंस के लिए ऑप्टिमाइज़ किया गया है. साथ ही, इसे इसका इस्तेमाल मेमोरी की सुरक्षा से जुड़ी गड़बड़ियों का पता लगाने के लिए किया जाता है. मेल न खाने वाले टैग पर, प्रोसेसर सबसे नज़दीकी कर्नेल एंट्री (जैसे कि syscall) तक एक्ज़ीक्यूशन जारी रखता है या टाइमर रुकावट), जहां यह SIGSEGV (कोड) के साथ प्रोसेस को खत्म कर देता है SEGV_MTEAERR) गलत पता या मेमोरी ऐक्सेस को रिकॉर्ड किए बिना.
यह मोड, इन मामलों में मेमोरी-सुरक्षा से जुड़े जोखिम की आशंकाओं को कम करने में मदद करता है अच्छी तरह से जांचे गए कोडबेस पर प्रोडक्शन होता है, जहां मेमोरी सुरक्षा बग की सघनता होती है आम तौर पर, यह समस्या कम होती है. ऐसा टेस्टिंग के दौरान सिंक मोड का इस्तेमाल करने पर होता है.
एमटीई चालू करें
एक डिवाइस के लिए
एक्सपेरिमेंट के लिए, ऐप्लिकेशन के साथ काम करने से जुड़े बदलावों का इस्तेमाल, डिफ़ॉल्ट सेटिंग को सेट करने के लिए किया जा सकता है
उस ऐप्लिकेशन के लिए memtagMode
एट्रिब्यूट का मान जो तय नहीं करता है
मेनिफ़ेस्ट में कोई भी मान (या "default"
तय करता है).
इन्हें सिस्टम > बेहतर > डेवलपर के लिए सेटिंग और टूल > ऐप्स
ग्लोबल सेटिंग मेन्यू में, इसके साथ काम करने के तरीके में किए गए बदलाव NATIVE_MEMTAG_ASYNC
सेट किया जा रहा है
या NATIVE_MEMTAG_SYNC
, किसी खास ऐप्लिकेशन के लिए एमटीई को चालू करता है.
इसके अलावा, इसे am
कमांड का इस्तेमाल करके सेट किया जा सकता है. इसके लिए, यह तरीका अपनाएं:
- सिंक मोड के लिए:
$ adb shell am compat enable NATIVE_MEMTAG_SYNC my.app.name
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है - ASYNC मोड के लिए:
$ 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
.
इसके अलावा, कस्टम बिल्ड टाइप के सभी बिल्ड के लिए एमटीई को चालू किया जा सकता है. ऐसा करें
इसलिए, अपना बिल्डटाइप बनाएं और
एक्सएमएल को app/src/<name of buildType>/AndroidManifest.xml
में बदलें.
किसी भी सक्षम डिवाइस पर APK के लिए
एमटीई डिफ़ॉल्ट रूप से बंद होता है. जिन ऐप्लिकेशन को एमटीई का इस्तेमाल करना है वे ये काम कर सकते हैं:
ऐसा करने के लिए, android:memtagMode
को <application>
या <process>
के तहत सेट करें
टैग को AndroidManifest.xml
में टैग करें.
android:memtagMode=(off|default|sync|async)
अगर इस एट्रिब्यूट को <application>
टैग पर सेट किया जाता है, तो इसका असर इस्तेमाल की गई सभी प्रोसेस पर पड़ता है
लागू किया जा सकता है. साथ ही, इसे अलग-अलग प्रोसेस में बदला जा सकता है
<process>
टैग.
इंस्ट्रुमेंटेशन की मदद से बनाएं
जैसा कि पहले बताया गया है, MTE को चालू करने से, नेटिव हीप है. स्टैक पर मेमोरी खराब होने का पता लगाने के लिए, चालू करने के अलावा ऐप्लिकेशन के लिए एमटीई, इंस्ट्रुमेंटेशन के साथ कोड को फिर से बनाने की ज़रूरत है. कॉन्टेंट बनाने ऐसा करने पर, ऐप्लिकेशन सिर्फ़ MTE की सुविधा वाले डिवाइसों पर चलेगा.
एमटीई की मदद से अपने ऐप्लिकेशन का नेटिव (जेएनआई) कोड बनाने के लिए, यह तरीका अपनाएं:
एनडीके-बिल्ड
आपकी 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
सीमेक
आपकी 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)
अपना ऐप्लिकेशन चलाएं
एमटीई चालू होने के बाद, अपने ऐप्लिकेशन को सामान्य तौर पर इस्तेमाल और टेस्ट करें. अगर आपको याददाश्त की सुरक्षा से जुड़ी कोई समस्या है
का पता चला है, तो आपका ऐप्लिकेशन इसके जैसा दिखने वाले टूंबस्टोन से क्रैश हो जाता है (नोट
'सिंक करें' के लिए SEGV_MTESERR
या ASYNC के लिए SEGV_MTEAERR
के साथ SIGSEGV
):
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
ज़्यादा जानकारी के लिए, एओएसपी दस्तावेज़ में एमटीई रिपोर्ट को समझना लेख पढ़ें. आपने लोगों तक पहुंचाया मुफ़्त में Android Studio से आपके ऐप्लिकेशन को डीबग भी कर सकता है और डीबगर अमान्य मेमोरी ऐक्सेस की वजह बनने वाली लाइन.
ऐडवांस लेवल वाले उपयोगकर्ता: अपने ऐलोकेटर में MTE का इस्तेमाल करना
अगर आपको सामान्य सिस्टम ऐलोकेटर के ज़रिए असाइन नहीं की गई मेमोरी के लिए एमटीई का इस्तेमाल करना है, तो मेमोरी और पॉइंटर को टैग करने के लिए, आपके ऐलोकेटर को बदलने की ज़रूरत होगी.
आपके आवंटनकर्ता के पेज, इसमें PROT_MTE
का इस्तेमाल करके
mmap
(या mprotect
) का prot
फ़्लैग.
टैग किए गए सभी एलोकेशन को 16-बाइट अलाइन होना चाहिए, क्योंकि टैग सिर्फ़ असाइन किए जा सकते हैं 16-बाइट वाले हिस्से के लिए (जिसे ग्रैन्यूल भी कहा जाता है).
इसके बाद, पॉइंटर लौटाने से पहले, आपको IRG
निर्देश का इस्तेमाल करके,
कोई भी टैग जनरेट करके उसे पॉइंटर में स्टोर करें.
दी गई 'यादें' को टैग करने के लिए, इन निर्देशों का पालन करें:
STG
: 16-बाइट वाला एक दाना टैग करेंST2G
: 16-बाइट वाले दो ग्रेन्युल टैग करेंDC GVA
: उसी टैग वाली कैशलाइन टैग करें
इसके अलावा, इन निर्देशों का पालन करने पर भी, मेमोरी को ज़ीरो से शुरू किया जाएगा:
STZG
: 16-बाइट वाले ग्रेन्युल को टैग करें और ज़ीरो-इनीशियलीशियल करेंSTZ2G
: 16-बाइट वाले दो ग्रेन्युल को टैग करें और ज़ीरो-इनीशियलाइज़ करेंDC GZVA
: एक ही टैग के साथ टैग करें और कैशलाइन को शून्य से शुरू करें
ध्यान दें कि ये निर्देश पुराने सीपीयू पर काम नहीं करते, इसलिए आपको: एमटीई चालू होने पर, शर्तों के साथ इसे चलाएं. यह पता लगाया जा सकता है कि एमटीई चालू किया गया है:
#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 लागू करने की सुविधा से मदद मिल सकती है.
ज़्यादा जानें
ज़्यादा जानकारी के लिए, आर्म की लिखी गई Android OS के लिए MTE उपयोगकर्ता गाइड देखें.