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

Arm v9 में Arm मेमोरी टैगिंग एक्सटेंशन (MTE) की सुविधा जोड़ी गई है. यह टैग की गई मेमोरी को हार्डवेयर के ज़रिए लागू करने का तरीका है.

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

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

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

एमटीई के तीन ऑपरेटिंग मोड होते हैं:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MTE मोड सेटिंग
एसिंक्रोनस एमटीई 
  sanitize: {
  memtag_heap: true,
  }
सिंक्रोनस एमटीई 
  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
सिंक्रोनस एमटीई MEMTAG_HEAP_SYNC_INCLUDE_PATHS

या किसी एक्ज़ीक्यूटेबल के बाहर रखे जाने वाले पाथ की जानकारी देकर:

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

उदाहरण, (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) अगर एनवायरमेंट वैरिएबल और सिस्टम प्रॉपर्टी, दोनों तय की गई हैं, तो वैरिएबल को प्राथमिकता दी जाती है.

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

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

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

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

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

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

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

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

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

SANITIZE_TARGET=memtag_heap SANITIZE_TARGET_DIAG=memtag_heap m

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

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

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

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

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 - आस-पास के ऐलोकेशन को अलग-अलग टैग वैल्यू असाइन करके, लीनियर बफ़र ओवरफ़्लो और अंडरफ़्लो बग का पता लगाने की सुविधा देता है. इस मोड में, इस्तेमाल के बाद मुक्त होने वाले बग का पता लगाने की संभावना थोड़ी कम होती है. इसकी वजह यह है कि हर मेमोरी लोकेशन के लिए, सिर्फ़ आधी संभावित टैग वैल्यू उपलब्ध होती हैं. कृपया ध्यान रखें कि MTE, एक ही टैग ग्रैनल (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 के साथ कर्नेल को कॉन्फ़िगर करें. ये कॉन्फ़िगरेशन, GKI केर्नेल पर डिफ़ॉल्ट रूप से चालू होते हैं. ये Android 12-5.10 से शुरू होते हैं.
इसे बूट के समय कंट्रोल किया जा सकता है. इसके लिए, कमांड लाइन के इन आर्ग्युमेंट का इस्तेमाल करें:

  • 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 मोड का इस्तेमाल करें. यह प्रोसेस में मेमोरी से जुड़ी सुरक्षा से जुड़ी गड़बड़ियों का पता लगाने के लिए, कम ओवरहेड वाला टूल उपलब्ध कराता है. साथ ही, ज़्यादा सुरक्षा भी देता है. गड़बड़ी का पता चलने के बाद, डेवलपर 'सिंक मोड' पर स्विच करने के लिए, रनटाइम एपीआई का इस्तेमाल कर सकता है. साथ ही, उपयोगकर्ताओं के सैंपल सेट से सटीक स्टैक ट्रेस पा सकता है.

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

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

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

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

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

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

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

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