मेमोरी टैगिंग एक्सटेंशन को चालू करना

Arm v9 में, Arm Memory Tagging Extension (MTE) की सुविधा दी गई है. यह टैग की गई मेमोरी का हार्डवेयर इंप्लीमेंटेशन है.

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

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

एमटीई के ऑपरेटिंग मोड

एमटीई के तीन मोड होते हैं:

  • सिंक्रोनस मोड (SYNC)
  • एसिंक्रोनस मोड (ASYNC)
  • एसिमेट्रिक मोड (ASYMM)

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

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

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

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

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

इस मोड को, गड़बड़ी की रिपोर्ट की सटीक जानकारी के बजाय परफ़ॉर्मेंस के लिए ऑप्टिमाइज़ किया गया है. इसका इस्तेमाल, मेमोरी सेफ़्टी से जुड़ी गड़बड़ियों का पता लगाने के लिए किया जा सकता है.
टैग के मेल न खाने पर, प्रोसेसर तब तक एक्ज़ीक्यूट करता रहता है, जब तक कि उसे सबसे नज़दीकी कर्नल एंट्री (उदाहरण के लिए, syscall या टाइमर इंटरप्ट) न मिल जाए. इसके बाद, वह SIGSEGV (कोड SEGV_MTEAERR) के साथ प्रोसेस को बंद कर देता है. हालांकि, वह गड़बड़ी वाले पते या मेमोरी ऐक्सेस को रिकॉर्ड नहीं करता.
हमारा सुझाव है कि इस मोड का इस्तेमाल प्रोडक्शन में, अच्छी तरह से टेस्ट किए गए कोडबेस पर करें. इससे मेमोरी सेफ़्टी से जुड़ी गड़बड़ियों की संख्या कम होती है. ऐसा टेस्टिंग के दौरान SYNC मोड का इस्तेमाल करके किया जाता है.

एसिमेट्रिक मोड (ASYMM)

Arm v8.7-A में एक अतिरिक्त सुविधा उपलब्ध है. एसिमेट्रिक एमटीई मोड, मेमोरी रीड पर सिंक्रोनस जांच और मेमोरी राइट पर एसिंक्रोनस जांच करता है. इसकी परफ़ॉर्मेंस, एसिंक्रोनस मोड की तरह ही होती है. ज़्यादातर मामलों में, यह मोड ASYNC मोड से बेहतर होता है. हमारा सुझाव है कि जब भी यह मोड उपलब्ध हो, तब इसका इस्तेमाल ASYNC मोड के बजाय करें.

इस वजह से, नीचे बताए गए किसी भी एपीआई में असिमेट्रिक मोड का ज़िक्र नहीं किया गया है. इसके बजाय, ओएस को इस तरह कॉन्फ़िगर किया जा सकता है कि जब भी एसिंक्रोनस मोड का अनुरोध किया जाए, तो वह हमेशा असिमेट्रिक मोड का इस्तेमाल करे. ज़्यादा जानकारी के लिए, कृपया "सीपीयू के हिसाब से, पसंदीदा एमटीई लेवल कॉन्फ़िगर करना" सेक्शन देखें.

उपयोगकर्ता स्पेस में MTE

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

बिल्ड सिस्टम का इस्तेमाल करके एमटीई चालू करना

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

1. किसी प्रोजेक्ट के लिए, Android.bp (उदाहरण) में एमटीई चालू करने का तरीका:

MTE मोड सेटिंग
एसिंक्रोनस एमटीई 
  sanitize: {
  memtag_heap: true,
  }
सिंक्रोनस MTE 
  sanitize: {
  memtag_heap: true,
  diag: {
  memtag_heap: true,
  },
  }

या Android.mk: में

MTE मोड सेटिंग
Asynchronous MTE LOCAL_SANITIZE := memtag_heap
Synchronous MTE LOCAL_SANITIZE := memtag_heap
LOCAL_SANITIZE_DIAG := memtag_heap

2. प्रॉडक्ट वैरिएबल का इस्तेमाल करके, सोर्स ट्री में मौजूद किसी सबडायरेक्ट्री पर एमटीई चालू करना:

MTE मोड शामिल की गई सूची बाहर रखने के लिए इस्तेमाल की जाने वाली सूची
async PRODUCT_MEMTAG_HEAP_ASYNC_INCLUDE_PATHS MEMTAG_HEAP_ASYNC_INCLUDE_PATHS PRODUCT_MEMTAG_HEAP_EXCLUDE_PATHS MEMTAG_HEAP_EXCLUDE_PATHS
सिंक करें PRODUCT_MEMTAG_HEAP_SYNC_INCLUDE_PATHS MEMTAG_HEAP_SYNC_INCLUDE_PATHS

या

MTE मोड सेटिंग
एसिंक्रोनस एमटीई MEMTAG_HEAP_ASYNC_INCLUDE_PATHS
सिंक्रोनस MTE MEMTAG_HEAP_SYNC_INCLUDE_PATHS

या किसी एक्ज़ीक्यूटेबल का एक्सक्लूड पाथ तय करके:

MTE मोड सेटिंग
एसिंक्रोनस एमटीई PRODUCT_MEMTAG_HEAP_EXCLUDE_PATHS MEMTAG_HEAP_EXCLUDE_PATHS
सिंक्रोनस MTE

उदाहरण के लिए, (PRODUCT_CFI_INCLUDE_PATHS की तरह ही इस्तेमाल किया जाता है)

  PRODUCT_MEMTAG_HEAP_SYNC_INCLUDE_PATHS=vendor/$(vendor)
  PRODUCT_MEMTAG_HEAP_EXCLUDE_PATHS=vendor/$(vendor)/projectA \
                                    vendor/$(vendor)/projectB

सिस्टम प्रॉपर्टी का इस्तेमाल करके एमटीई चालू करना

ऊपर दी गई बिल्ड सेटिंग को रनटाइम में बदला जा सकता है. इसके लिए, आपको यह सिस्टम प्रॉपर्टी सेट करनी होगी:

arm64.memtag.process.<basename> = (off|sync|async)

यहाँ basename, एक्ज़ीक्यूटेबल के बेस नेम के लिए इस्तेमाल किया गया है.

उदाहरण के लिए, एसिंक्रोनस एमटीई का इस्तेमाल करने के लिए, /system/bin/ping या /data/local/tmp/ping को सेट करने के लिए, adb shell setprop arm64.memtag.process.ping async का इस्तेमाल करें.

एनवायरमेंट वैरिएबल का इस्तेमाल करके एमटीई चालू करना

नेटिव प्रोसेस (ऐप्लिकेशन के अलावा) के लिए, बिल्ड सेटिंग को बदलने का एक और तरीका है. इसके लिए, एनवायरमेंट वैरिएबल को इस तरह से तय करें: MEMTAG_OPTIONS=(off|sync|async) अगर एनवायरमेंट वैरिएबल और सिस्टम प्रॉपर्टी, दोनों को तय किया गया है, तो वैरिएबल को प्राथमिकता दी जाएगी.

ऐप्लिकेशन के लिए एमटीई चालू करना

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

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

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

एक्सपेरिमेंट के लिए, कंपैटिबिलिटी में बदलाव का इस्तेमाल किया जा सकता है. इससे ऐसे ऐप्लिकेशन के लिए memtagMode एट्रिब्यूट की डिफ़ॉल्ट वैल्यू सेट की जा सकती है जो मेनिफ़ेस्ट में कोई वैल्यू नहीं देता है या default वैल्यू देता है.
इन्हें ग्लोबल सेटिंग मेन्यू में System > Advanced > Developer options > App Compatibility Changes में जाकर देखा जा सकता है. NATIVE_MEMTAG_ASYNC या NATIVE_MEMTAG_SYNC सेटिंग से, किसी ऐप्लिकेशन के लिए MTE चालू किया जा सकता है.
इसके अलावा, इसे am कमांड का इस्तेमाल करके भी सेट किया जा सकता है. इसके लिए, यह तरीका अपनाएं:

$ adb shell am compat enable NATIVE_MEMTAG_[A]SYNC my.app.name

एमटीई सिस्टम इमेज बनाना

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

हमारा सुझाव है कि डेवलपमेंट के दौरान, सभी नेटिव बाइनरी पर सिंक्रोनस मोड में MTE चालू करें

SANITIZE_TARGET=memtag_heap SANITIZE_TARGET_DIAG=memtag_heap m

बिल्ड सिस्टम में मौजूद किसी भी वैरिएबल की तरह, SANITIZE_TARGET को एनवायरमेंट वैरिएबल या make सेटिंग के तौर पर इस्तेमाल किया जा सकता है. उदाहरण के लिए, product.mk फ़ाइल में.
कृपया ध्यान दें कि इससे सभी नेटिव प्रोसेस के लिए MTE चालू हो जाता है. हालांकि, यह उन ऐप्लिकेशन के लिए चालू नहीं होता है जिन्हें zygote64 से फ़ोर्क किया गया है. इन ऐप्लिकेशन के लिए MTE को ऊपर दिए गए निर्देशों का पालन करके चालू किया जा सकता है.

सीपीयू के हिसाब से, पसंदीदा एमटीई लेवल कॉन्फ़िगर करना

कुछ सीपीयू पर, ASYMM या SYNC मोड में MTE की परफ़ॉर्मेंस, ASYNC मोड की परफ़ॉर्मेंस के बराबर हो सकती है. इससे, कम सख्त जांच मोड का अनुरोध किए जाने पर, उन सीपीयू पर ज़्यादा सख्त जांच चालू करना फ़ायदेमंद हो जाता है. ऐसा इसलिए, ताकि परफ़ॉर्मेंस पर असर डाले बिना, ज़्यादा सख्त जांच से गड़बड़ी का पता लगाने के फ़ायदे मिल सकें.
डिफ़ॉल्ट रूप से, ASYNC मोड में चलने के लिए कॉन्फ़िगर की गई प्रोसेस, सभी सीपीयू पर ASYNC मोड में चलेंगी. कुछ सीपीयू पर SYNC मोड में इन प्रोसेस को चलाने के लिए, कर्नल को कॉन्फ़िगर करना ज़रूरी है. इसके लिए, बूट होने के समय sysfs एंट्री /sys/devices/system/cpu/cpu<N>/mte_tcf_preferred में वैल्यू सिंक करनी होगी. इसके लिए, init स्क्रिप्ट का इस्तेमाल किया जा सकता है. उदाहरण के लिए, अगर आपको सीपीयू 0-1 को एसिंक्रोनस मोड में प्रोसेस चलाने के लिए सिंक्रोनस मोड में कॉन्फ़िगर करना है और सीपीयू 2-3 को एसिमेट्रिक मोड में इस्तेमाल करना है, तो वेंडर की init स्क्रिप्ट के init क्लॉज़ में यह जोड़ा जा सकता है: 

  write /sys/devices/system/cpu/cpu0/mte_tcf_preferred sync
  write /sys/devices/system/cpu/cpu1/mte_tcf_preferred sync
  write /sys/devices/system/cpu/cpu2/mte_tcf_preferred asymm
  write /sys/devices/system/cpu/cpu3/mte_tcf_preferred asymm

सिंक मोड में चल रही एसिंक्रोनस प्रोसेस के टॉम्बस्टोन में, मेमोरी से जुड़ी गड़बड़ी की जगह का सटीक स्टैक ट्रेस शामिल होगा. हालांकि, इनमें स्टैक ट्रेस के लिए जगह नहीं होगी. ये स्टैक ट्रेस सिर्फ़ तब उपलब्ध होते हैं, जब प्रोसेस को SYNC मोड में चलाने के लिए कॉन्फ़िगर किया गया हो.

int mallopt(M_THREAD_DISABLE_MEM_INIT, level)

यहां level की वैल्यू 0 या 1 है.
यह malloc में मेमोरी के इनिशियलाइज़ेशन को बंद कर देता है. साथ ही, मेमोरी टैग में बदलाव करने से बचता है जब तक कि सही तरीके से काम करने के लिए ऐसा करना ज़रूरी न हो.

int mallopt(M_MEMTAG_TUNING, level)

जहां level है:

  • M_MEMTAG_TUNING_BUFFER_OVERFLOW
  • M_MEMTAG_TUNING_UAF

यह कुकी, टैग असाइन करने की रणनीति चुनती है.

  • डिफ़ॉल्ट सेटिंग M_MEMTAG_TUNING_BUFFER_OVERFLOW है.
  • M_MEMTAG_TUNING_BUFFER_OVERFLOW - यह लीनियर बफ़र ओवरफ़्लो और अंडरफ़्लो बग का पता लगाने की सुविधा चालू करता है. इसके लिए, यह आस-पास के असाइनमेंट को अलग-अलग टैग वैल्यू असाइन करता है. इस मोड में, यूज़-आफ़्टर-फ़्री बग का पता चलने की संभावना थोड़ी कम होती है. ऐसा इसलिए, क्योंकि हर मेमोरी लोकेशन के लिए, टैग की सिर्फ़ आधी संभावित वैल्यू उपलब्ध होती हैं. कृपया ध्यान रखें कि एमटीई, एक ही टैग ग्रैन्यूल (16-बाइट अलाइन किया गया हिस्सा) में ओवरफ़्लो का पता नहीं लगा सकता. साथ ही, इस मोड में भी छोटे ओवरफ़्लो का पता नहीं लगा सकता. इस तरह के ओवरफ़्लो से मेमोरी करप्ट नहीं होती, क्योंकि एक ग्रेन्यूल के अंदर की मेमोरी का इस्तेमाल कभी भी कई बार नहीं किया जाता.
  • M_MEMTAG_TUNING_UAF - यह टैग को अलग-अलग तरीके से रैंडमाइज़ करता है, ताकि स्पेस (बफ़र ओवरफ़्लो) और समय (फ़्री के बाद इस्तेमाल) से जुड़ी गड़बड़ियों का पता लगाने की संभावना ~93% तक बढ़ जाए.

ऊपर बताए गए एपीआई के अलावा, अनुभवी उपयोगकर्ताओं को इनके बारे में भी पता होना चाहिए:

  • PSTATE.TCO हार्डवेयर रजिस्टर सेट करने से, टैग की जांच को कुछ समय के लिए रोका जा सकता है (उदाहरण). उदाहरण के लिए, जब टैग किए गए कॉन्टेंट की किसी रेंज को कॉपी किया जा रहा हो या हॉट लूप में परफ़ॉर्मेंस से जुड़ी समस्या को ठीक किया जा रहा हो.
  • M_HEAP_TAGGING_LEVEL_SYNC का इस्तेमाल करते समय, सिस्टम क्रैश हैंडलर ज़्यादा जानकारी देता है. जैसे, स्टैक ट्रेस को असाइन और असाइन नहीं किया गया. इस सुविधा के लिए, टैग बिट का ऐक्सेस ज़रूरी है. इसे सिग्नल हैंडलर सेट करते समय, SA_EXPOSE_TAGBITS फ़्लैग पास करके चालू किया जाता है. हमारा सुझाव है कि ऐसा हर प्रोग्राम करे जो अपना सिग्नल हैंडलर सेट करता है और सिस्टम को क्रैश होने की जानकारी देता है.

कर्नेल में एमटीई

कर्नेल के लिए, MTE-ऐक्सलरेटेड KASAN को चालू करने के लिए, कर्नेल को CONFIG_KASAN=y, CONFIG_KASAN_HW_TAGS=y के साथ कॉन्फ़िगर करें. ये कॉन्फ़िगरेशन, Android 12-5.10 से शुरू होने वाले GKI कर्नल पर डिफ़ॉल्ट रूप से चालू होते हैं.
इसे बूट टाइम पर कंट्रोल किया जा सकता है. इसके लिए, कमांड लाइन के इन आर्ग्युमेंट का इस्तेमाल करें:

  • kasan=[on|off] - KASAN को चालू या बंद करें (डिफ़ॉल्ट: on)
  • kasan.mode=[sync|async] - सिंक्रोनस और एसिंक्रोनस मोड में से कोई एक चुनें (डिफ़ॉल्ट: sync)
  • kasan.stacktrace=[on|off] - स्टैक ट्रेस इकट्ठा करना है या नहीं (डिफ़ॉल्ट: on)
    • स्टैक ट्रेस इकट्ठा करने के लिए भी stack_depot_disable=off की ज़रूरत होती है.
  • kasan.fault=[report|panic] - सिर्फ़ रिपोर्ट प्रिंट करनी है या कर्नल को भी पैनिक करना है (डिफ़ॉल्ट: report). इस विकल्प के बावजूद, पहली गड़बड़ी की रिपोर्ट मिलने के बाद टैग की जांच बंद हो जाती है.

हमारा सुझाव है कि ब्रिंग-अप, डेवलपमेंट, और टेस्टिंग के दौरान SYNC मोड का इस्तेमाल करें. यह विकल्प, एनवायरमेंट वैरिएबल या बिल्ड सिस्टम का इस्तेमाल करने वाली सभी प्रोसेस के लिए, ग्लोबल लेवल पर चालू होना चाहिए. इस मोड में, डेवलपमेंट प्रोसेस के शुरुआती चरण में ही गड़बड़ियों का पता चल जाता है. साथ ही, कोडबेस को जल्दी स्थिर किया जा सकता है. इसके अलावा, प्रोडक्शन के बाद गड़बड़ियों का पता लगाने में लगने वाले खर्च से भी बचा जा सकता है.

हमारा सुझाव है कि प्रोडक्शन में ASYNC मोड का इस्तेमाल करें. यह एक ऐसा टूल है जो किसी प्रोसेस में मेमोरी सेफ़्टी से जुड़ी गड़बड़ियों का पता लगाने के लिए कम ओवरहेड देता है. साथ ही, यह सुरक्षा को और बेहतर बनाता है. बग का पता चलने के बाद, डेवलपर रनटाइम एपीआई का इस्तेमाल करके SYNC मोड पर स्विच कर सकता है. साथ ही, उपयोगकर्ताओं के सैंपल किए गए सेट से सटीक स्टैक ट्रेस पा सकता है.

हमारा सुझाव देते हैं कि SoC के लिए, सीपीयू के हिसाब से पसंदीदा एमटीई लेवल कॉन्फ़िगर करें. आम तौर पर, एसिम मोड की परफ़ॉर्मेंस की विशेषताएं ASYNC मोड जैसी ही होती हैं. साथ ही, यह लगभग हमेशा ASYNC मोड से बेहतर होता है. छोटे इन-ऑर्डर कोर, अक्सर तीनों मोड में एक जैसी परफ़ॉर्मेंस दिखाती हैं. इन्हें SYNC को प्राथमिकता देने के लिए कॉन्फ़िगर किया जा सकता है.

डेवलपर को क्रैश की मौजूदगी की जांच करनी चाहिए. इसके लिए, उन्हें /data/tombstones और logcat की जांच करनी चाहिए. इसके अलावा, वे वेंडर DropboxManager पाइपलाइन की निगरानी करके, असली उपयोगकर्ताओं के लिए मौजूद गड़बड़ियों का पता लगा सकते हैं. Android के नेटिव कोड को डीबग करने के बारे में ज़्यादा जानने के लिए, यहां दी गई जानकारी देखें.

एमटीई की सुविधा वाले प्लैटफ़ॉर्म कॉम्पोनेंट

Android 12 में, सुरक्षा के लिए ज़रूरी कई सिस्टम कॉम्पोनेंट, MTE ASYNC का इस्तेमाल करते हैं. इससे, उन्हें असली उपयोगकर्ता के क्रैश का पता लगाने में मदद मिलती है. साथ ही, यह सुरक्षा की एक अतिरिक्त लेयर के तौर पर काम करता है. ये कॉम्पोनेंट हैं:

  • नेटवर्किंग डेमॉन और यूटिलिटी (netd को छोड़कर)
  • ब्लूटूथ, SecureElement, NFC HAL, और सिस्टम ऐप्लिकेशन
  • statsd डीमन
  • system_server
  • zygote64 (ताकि ऐप्लिकेशन, MTE का इस्तेमाल करने के लिए ऑप्ट-इन कर सकें)

इन टारगेट को इन शर्तों के आधार पर चुना गया था:

  • ऐसी प्रोसेस जिसे खास अधिकार मिले हों. इसे ऐसी प्रोसेस के तौर पर परिभाषित किया जाता है जिसके पास ऐसी चीज़ का ऐक्सेस हो जिसका ऐक्सेस unprivileged_app SELinux डोमेन के पास नहीं है
  • भरोसेमंद नहीं माने जाने वाले इनपुट को प्रोसेस करता है (दो का नियम)
  • परफ़ॉर्मेंस में गिरावट स्वीकार्य है (गिरावट की वजह से, उपयोगकर्ता को दिखने वाला इंतज़ार का समय नहीं बढ़ता)

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