Android, मेमोरी से जुड़ी गड़बड़ियों को डीबग करने के लिए कई टूल इस्तेमाल करता है. इनमें से हर विकल्प के कुछ फ़ायदे और कुछ नुकसान हैं. इसलिए, अपने इस्तेमाल के उदाहरण के हिसाब से यह तय करने के लिए नीचे पढ़ें कि कौनसा विकल्प सबसे सही है. इस दस्तावेज़ में, उपलब्ध टूल के बारे में खास जानकारी दी गई है, ताकि आप यह तय कर सकें कि किन टूल की जांच करनी है. हालांकि, इसमें ज़्यादा जानकारी नहीं दी गई है. इसलिए, ज़्यादा जानकारी के लिए, टूल के बारे में खास दस्तावेज़ पढ़ें.
खास जानकारी
- जब भी हो सके, मेमोरी सेफ़ भाषा का इस्तेमाल करें, ताकि मेमोरी से जुड़ी गड़बड़ियां न हों
- आरओपी/जेओपी अटैक को कम करने के लिए, हमेशा पीएसी/बीटीआई का इस्तेमाल करें
- प्रोडक्शन में मेमोरी से जुड़ी गड़बड़ियों का पता लगाने के लिए, हमेशा GWP-ASan का इस्तेमाल करें
- टेस्टिंग के दौरान मेमोरी से जुड़ी गड़बड़ियों का पता लगाने के लिए, HWASan का इस्तेमाल करना
- MTE की सुविधा वाले डिवाइस, आम तौर पर उपलब्ध नहीं होते. जब तक यह बदलाव नहीं होता, तब तक यह मददगार नहीं होगा
- टेस्टिंग के दौरान, ASan का इस्तेमाल सिर्फ़ आखिरी विकल्प के तौर पर करें
यादें सुरक्षित रखने वाली भाषाएं
मेमोरी सेफ़ लैंग्वेज का इस्तेमाल करके ही, मेमोरी से जुड़ी गड़बड़ियों से पूरी तरह से बचा जा सकता है और उन्हें कम किया जा सकता है. इस पेज पर मौजूद अन्य टूल की मदद से, मेमोरी से जुड़ी समस्याओं वाले कोड को ज़्यादा सुरक्षित और भरोसेमंद बनाया जा सकता है. हालांकि, मेमोरी सेफ़ लैंग्वेज का इस्तेमाल करने पर, इस तरह की सभी समस्याएं खत्म हो जाती हैं.
Android के लिए, मेमोरी सेफ़ लैंग्वेज के तौर पर आधिकारिक तौर पर Java और Kotlin का इस्तेमाल किया जा सकता है. ज़्यादातर Android ऐप्लिकेशन, इनमें से किसी एक भाषा में आसानी से डेवलप किए जा सकते हैं.
हालांकि, कुछ ऐप्लिकेशन डेवलपर Rust में लिखे गए कोड को शिप कर रहे हैं. अगर आपने यह पेज पढ़ा है, तो हो सकता है कि आपके पास नेटिव कोड (पोर्टेबिलिटी, परफ़ॉर्मेंस या दोनों) की ज़रूरत हो. Android पर मेमोरी सेफ़ नेटिव कोड के लिए, Rust सबसे अच्छा विकल्प है. ऐसा करने पर, हो सकता है कि NDK टीम आपकी समस्याओं को हल करने में आपकी मदद न कर पाए. हालांकि, हम उन समस्याओं के बारे में जानना चाहते हैं!
पीएसी/बीटीआई
पॉइंटर की पुष्टि और शाखा के टारगेट की पहचान, जिसे PAC/BTI भी कहा जाता है, ये प्रोडक्शन में इस्तेमाल के लिए सही टूल हैं. ये अलग-अलग टेक्नोलॉजी हैं, लेकिन इन्हें एक ही कंपाइलर फ़्लैग से कंट्रोल किया जाता है. इसलिए, इन्हें हमेशा एक साथ इस्तेमाल किया जाता है.
ये सुविधाएं, उन डिवाइसों के साथ भी काम करती हैं जिन पर ये काम नहीं करतीं. ऐसा इसलिए है, क्योंकि इस्तेमाल किए गए नए निर्देश, पुराने डिवाइसों पर काम नहीं करते. इसके लिए, यह भी ज़रूरी है कि आपके डिवाइस में ओएस का नया वर्शन और नया कर्नेल हो.
/proc/cpuinfo में paca और bti को खोजने से पता चलता है कि आपके पास ज़रूरत के मुताबिक नया हार्डवेयर और नया कर्नेल है या नहीं. Android 12 (एपीआई 31) में, उपयोगकर्ता के लिए ज़रूरी जगह का ऐक्सेस देने की सुविधा मौजूद है.
फ़ायदे:
- इसे सभी बिल्ड में चालू किया जा सकता है. इससे पुराने डिवाइसों या कर्नल में कोई समस्या नहीं होती. हालांकि, पक्का करें कि आपने इसकी जांच ऐसे डिवाइस/कर्नल/ओएस के कॉम्बिनेशन पर की हो जो इस सुविधा के साथ काम करता हो!
नुकसान:
- यह सुविधा सिर्फ़ 64-बिट ऐप्लिकेशन के लिए उपलब्ध है
- जिन डिवाइसों पर यह सुविधा काम नहीं करती उन पर गड़बड़ियों को कम नहीं करता
- कोड साइज़ में 1% का ओवरहेड
GWP-Asan
GWP-ASan का इस्तेमाल, फ़ील्ड में मेमोरी से जुड़ी गड़बड़ियों का पता लगाने के लिए किया जा सकता है. हालांकि, सैंपलिंग रेट बहुत कम है, इसलिए इससे गड़बड़ियों को कम करने में काफ़ी मदद नहीं मिलती.
फ़ायदे:
- सीपीयू या मेमोरी का ज़्यादा इस्तेमाल न होना
- डिप्लॉय करना आसान: इसके लिए, नेटिव कोड को फिर से बनाने की ज़रूरत नहीं होती
- 32-बिट ऐप्लिकेशन के लिए काम करता है
नुकसान:
- कम सैंपलिंग रेट के लिए, गड़बड़ियों का पता लगाने के लिए ज़्यादा उपयोगकर्ताओं की ज़रूरत होती है
- सिर्फ़ ढेर की गड़बड़ियों का पता लगाता है, स्टैक की गड़बड़ियों का नहीं
HWASan
हार्डवेयर पते को साफ़ करने वाला टूल, जिसे HWASan भी कहा जाता है, टेस्टिंग के दौरान मेमोरी से जुड़ी गड़बड़ियों का पता लगाने के लिए सबसे सही है. यह ऑटोमेटेड टेस्टिंग के साथ इस्तेमाल करने पर सबसे ज़्यादा फ़ायदेमंद होता है. खास तौर पर, अगर फ़ज़ टेस्ट चलाए जा रहे हैं, तो ऐसा किया जा सकता है. हालांकि, आपके ऐप्लिकेशन की परफ़ॉर्मेंस की ज़रूरतों के हिसाब से, इसे हाई-एंड फ़ोन पर भी इस्तेमाल किया जा सकता है.
फ़ायदे:
- फ़ॉल्स पॉज़िटिव नहीं
- गड़बड़ियों की ऐसी अन्य क्लास का पता लगाता है जिन्हें ASan नहीं ढूंढ सकता (रिटर्न के बाद स्टैक का इस्तेमाल)
- एमटीई के मुकाबले फ़ॉल्स निगेटिव की दर कम है (256 में से 1 बनाम 16 में से 1)
- ASan की तुलना में कम मेमोरी खर्च करता है, जो इसका सबसे करीबी विकल्प है
नुकसान:
- सीपीयू (~100%), कोड साइज़ (~50%), और मेमोरी (10% - 35%) का ज़्यादा इस्तेमाल
- एपीआई 34 और NDK r26 तक, HWASan के साथ काम करने वाली इमेज को फ़्लैश करना ज़रूरी है
- सिर्फ़ 64-बिट ऐप्लिकेशन पर काम करता है
MTE
मेमोरी टैगिंग एक्सटेंशन, जिसे MTE भी कहा जाता है, HWASan का कम लागत वाला विकल्प है. डीबग करने और टेस्ट करने की सुविधाओं के अलावा, इसका इस्तेमाल प्रोडक्शन में मेमोरी में हुए नुकसान का पता लगाने और उसे कम करने के लिए किया जा सकता है. अगर आपके पास एमटीई बिल्ड की जांच करने के लिए हार्डवेयर है, तो आपको इसे चालू करना चाहिए.
फ़ायदे:
- कई ऐप्लिकेशन के लिए प्रोडक्शन में इस्तेमाल करने के लिए, ओवरहेड कम होना चाहिए
- फ़ॉल्स पॉज़िटिव नहीं
- हेप गड़बड़ियों का पता लगाने के लिए, कोड को फिर से बनाने की ज़रूरत नहीं होती (हालांकि, स्टैक गड़बड़ियों का पता लगाने के लिए ऐसा करना ज़रूरी है)
नुकसान:
- साल 2024 में, व्यावसायिक तौर पर उपलब्ध ऐसे कोई डिवाइस नहीं है जिसमें एमटीई की सुविधा डिफ़ॉल्ट रूप से चालू हो. हालांकि, Arm के दस्तावेज़ में बताया गया है कि Pixel 8/Pixel 8 Pro पर जांच के लिए, एमटीई की सुविधा को कैसे चालू करें.
- 16 में से 1 में खतरे को कम आंकना बनाम HWASan की 256 में से 1
- यह सुविधा सिर्फ़ 64-बिट ऐप्लिकेशन के लिए उपलब्ध है
- एमटीई की सुविधा वाले और एमटीई की सुविधा वाले डिवाइसों, दोनों को टारगेट करने के लिए अलग-अलग लाइब्रेरी बनानी पड़ती हैं
ASan
पते को सुरक्षित करने वाला टूल, जिसे ASan भी कहा जाता है, सबसे पुराना और सबसे ज़्यादा उपलब्ध टूल है. यह जांच करने और समस्याओं को डीबग करने के दौरान, मेमोरी से जुड़ी गड़बड़ियों का पता लगाने में मददगार होता है. ये गड़बड़ियां सिर्फ़ उन पुराने डिवाइसों पर होती हैं जहां कोई भी अन्य टूल उपलब्ध नहीं होता. जब भी हो सके, HWASan का इस्तेमाल करें.
फ़ायदे:
- ज़्यादा से ज़्यादा लोगों के लिए उपलब्ध हो. यह KitKat जैसे पुराने डिवाइसों पर भी काम कर सकता है
- सही तरीके से इस्तेमाल करने पर, न तो कोई फ़ॉल्स पॉज़िटिव नतीजा मिलता है और न ही कोई फ़ॉल्स नेगेटिव नतीजा
नुकसान:
- सही तरीके से बनाने और पैकेज करने में मुश्किल आना
- सभी विकल्पों में सबसे ज़्यादा ओवरहेड: ~100% सीपीयू, ~50% कोड साइज़, ~100% मेमोरी का इस्तेमाल
- अब काम नहीं करता
- ऐसे बग हैं जिनके बारे में पता है और जिन्हें ठीक नहीं किया जाएगा