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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यूज़रस्पेस में एमटीई

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

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

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

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

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

या Android.mk: में

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

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

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

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

अगर किसी नीति के बारे में नहीं बताया गया है, तो एमटीई डिफ़ॉल्ट रूप से बंद रहता है. हालांकि, जिन ऐप्लिकेशन को एमटीई का इस्तेमाल करना है वे 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 को सिंक्रोनस मोड में चालू करें

SANITIZE_TARGET=memtag_heap SANITIZE_TARGET_DIAG=memtag_heap m

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

सीपीयू के लिए खास तौर पर सेट किए गए एमटीई लेवल को कॉन्फ़िगर करें

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

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

int mallopt(M_THREAD_DISABLE_MEM_INIT, level)

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

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-Accelerated 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). इसके बावजूद विकल्प के तौर पर, पहली बार रिपोर्ट की गई गड़बड़ी के बाद टैग की जांच की सुविधा बंद हो जाती है.

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

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

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

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

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

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

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

इन लक्ष्यों को निम्नलिखित मानदंडों के आधार पर चुना गया था:

  • एक खास प्रोसेस (यह एक ऐसी प्रोसेस है जिसमें किसी चीज़ का ऐक्सेस होता है जो Unprivileged_app SELinux डोमेन ऐसा नहीं करते)
  • गैर-भरोसेमंद इनपुट को प्रोसेस करता है (नियम दो में से दो)
  • स्वीकार्य प्रदर्शन धीमा है (धीमी गति उपयोगकर्ता को दिखाई नहीं देती इंतज़ार का समय)

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