Arm मेमोरी टैगिंग एक्सटेंशन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यूज़रस्पेस में MTE

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

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

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

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

MTE मोड सेटिंग
एसिंक्रोनस 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 चालू करना:

MTE मोड टारगेट की गई जगहों की सूची टारगेटिंग से बाहर रखी गई जगहों की सूची
एक साथ काम नहीं करने वाली प्रोसेस 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 मोड सेटिंग
एसिंक्रोनस MTE MEMTAG_HEAP_ASYNC_INCLUDE_PATHS
सिंक्रोनस MTE MEMTAG_HEAP_SYNC_INCLUDE_PATHS

या किसी एक्ज़ीक्यूटेबल के लिए, बाहर रखी गई जगह की जानकारी देकर:

MTE मोड सेटिंग
एसिंक्रोनस 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

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

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

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

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

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

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

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

ऐप्लिकेशन के लिए MTE चालू करना

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

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

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

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

ये, ग्लोबल सेटिंग मेन्यू में सिस्टम > ऐडवांस > डेवलपर के विकल्प > ऐप्लिकेशन की कंपैटिबिलिटी में किए गए बदलाव में मौजूद हैं. NATIVE_MEMTAG_ASYNC या NATIVE_MEMTAG_SYNC सेट करने पर, किसी खास ऐप्लिकेशन के लिए MTE चालू हो जाता है. इसके अलावा, इसे am कमांड का इस्तेमाल करके भी सेट किया जा सकता है. इसके लिए, यह तरीका अपनाएं:

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

MTE सिस्टम इमेज बनाना

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

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

SANITIZE_TARGET=memtag_heap SANITIZE_TARGET_DIAG=memtag_heap m

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

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

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

कुछ सीपीयू पर, ASYMM या SYNC मोड में MTE की परफ़ॉर्मेंस, ASYNC मोड की परफ़ॉर्मेंस के जैसी हो सकती है. इससे, उन सीपीयू पर ज़्यादा सख्त जांच चालू करना फ़ायदेमंद हो सकता है. ऐसा तब करें, जब कम सख्त जांच मोड का अनुरोध किया गया हो. इससे, परफ़ॉर्मेंस पर असर डाले बिना, ज़्यादा सख्त जांच से गड़बड़ी का पता लगाने के फ़ायदे हासिल किए जा सकते हैं.

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

SYNC मोड में चलने वाली ASYNC मोड प्रोसेस के टॉम्बस्टोन में, मेमोरी की गड़बड़ी की जगह का सटीक स्टैक ट्रेस होता है. हालांकि, इनमें ऐलोकेशन या डीऐलोकेशन स्टैक ट्रेस शामिल नहीं होता. ये स्टैक ट्रेस सिर्फ़ तब उपलब्ध होते हैं, जब प्रोसेस को 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 से, लीनियर बफ़र ओवरफ़्लो और अंडरफ़्लो वाली गड़बड़ियों का पता लगाया जा सकता है. इसके लिए, आस-पास के ऐलोकेशन को अलग-अलग टैग वैल्यू असाइन की जाती हैं. इस मोड में, यूज़-आफ़्टर-फ़्री वाली गड़बड़ियों का पता लगने की संभावना थोड़ी कम होती है, क्योंकि मेमोरी की हर जगह के लिए, टैग की आधी वैल्यू ही उपलब्ध होती हैं. MTE, एक ही टैग ग्रैन्यूल (16 बाइट अलाइन किया गया चंक) में ओवरफ़्लो का पता नहीं लगा सकता. साथ ही, इस मोड में भी छोटे ओवरफ़्लो का पता नहीं चल पाता. ऐसे ओवरफ़्लो से मेमोरी करप्ट नहीं हो सकती, क्योंकि एक ग्रैन्यूल में मौजूद मेमोरी का इस्तेमाल, कभी भी एक से ज़्यादा ऐलोकेशन के लिए नहीं किया जाता.
  • M_MEMTAG_TUNING_UAF से, टैग को अलग-अलग तरीके से रैंडमाइज़ किया जाता है. इससे, स्पेस (बफ़र ओवरफ़्लो) और टेंपोरल (यूज़-आफ़्टर-फ़्री) वाली गड़बड़ियों का पता लगने की संभावना ~93% होती है.

ऊपर बताए गए एपीआई के अलावा, अनुभवी उपयोगकर्ता इन बातों का ध्यान रख सकते हैं:

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

कर्नल में MTE

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

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

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

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

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

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

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

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

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

हमारा प्लान है कि सिस्टम के उन कॉम्पोनेंट की सूची को बढ़ाया जाए जिनके लिए MTE चालू है. इसके लिए, आने वाले हार्डवेयर डिज़ाइन की परफ़ॉर्मेंस की विशेषताओं को ध्यान में रखा जाएगा.