Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

जीडब्ल्यूपी-असैन

GWP-ASan, नेटिव मेमोरी ऐलोकेटर की एक सुविधा है. इससे, use-after-free और heap-buffer-overflow बग का पता लगाने में मदद मिलती है. इसका अनौपचारिक नाम एक रिकर्सिव एक्रनिम है,"GWP-ASan Will Provide Allocation SANity". HWASan या Malloc Debug के उलट, GWP-ASan को सोर्स या फिर से कंपाइल करने की ज़रूरत नहीं होती. इसका मतलब है कि यह पहले से बने हुए सोर्स के साथ काम करता है. साथ ही, यह 32-बिट और 64-बिट, दोनों प्रोसेस पर काम करता है. हालांकि, 32-बिट वाले क्रैश में डीबग करने की कम जानकारी होती है. इस विषय में उन कार्रवाइयों के बारे में बताया गया है जो आपको अपने ऐप्लिकेशन में इस सुविधा को चालू करने के लिए करनी होंगी. GWP-ASan, Android 11 (एपीआई लेवल 30) या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन पर उपलब्ध है.

खास जानकारी

GWP-ASan, प्रोसेस के स्टार्टअप (या जब ज़ाइगोट फ़ोर्क होता है) पर, रैंडम तरीके से चुने गए कुछ सिस्टम ऐप्लिकेशन और प्लैटफ़ॉर्म के एक्ज़ीक्यूटेबल पर चालू होता है. अपने ऐप्लिकेशन में GWP-ASan को चालू करें, ताकि आपको मेमोरी से जुड़ी गड़बड़ियों का पता लगाने में मदद मिल सके. साथ ही, अपने ऐप्लिकेशन को ARM Memory Tagging Extension (MTE) के साथ काम करने के लिए तैयार करें. एलोकेशन सैंपलिंग के तरीके, क्वेरी ऑफ़ डेथ के ख़िलाफ़ भी भरोसेमंद होते हैं.

चालू होने के बाद, GWP-ASan हीप ऐलोकेशन के रैंडम तरीके से चुने गए सबसेट को इंटरसेप्ट करता है. साथ ही, उन्हें एक खास जगह पर रखता है, जो हीप मेमोरी के खराब होने से जुड़े ऐसे बग का पता लगाती है जिनका पता लगाना मुश्किल होता है. अगर उपयोगकर्ताओं की संख्या काफ़ी ज़्यादा है, तो इस कम सैंपलिंग रेट से भी हीप मेमोरी की सुरक्षा से जुड़ी ऐसी गड़बड़ियों का पता लगाया जा सकता है जो सामान्य टेस्टिंग से नहीं मिलतीं. उदाहरण के लिए, GWP-ASan को Chrome ब्राउज़र में कई गड़बड़ियां मिली हैं. इनमें से कई गड़बड़ियां अब भी प्रतिबंधित व्यू में हैं.

GWP-ASan, उन सभी ऐलोकेशन के बारे में अतिरिक्त जानकारी इकट्ठा करता है जिन्हें वह इंटरसेप्ट करता है. यह जानकारी तब उपलब्ध होती है, जब GWP-ASan को मेमोरी की सुरक्षा से जुड़े उल्लंघन का पता चलता है. साथ ही, यह जानकारी नेटिव क्रैश रिपोर्ट में अपने-आप शामिल हो जाती है. इससे डीबग करने में काफ़ी मदद मिल सकती है. ज़्यादा जानकारी के लिए, उदाहरण देखें.

GWP-ASan को इस तरह से डिज़ाइन किया गया है कि सीपीयू पर ज़्यादा लोड न पड़े. GWP-ASan को चालू करने पर, रैम का थोड़ा सा हिस्सा इस्तेमाल होता है. यह ओवरहेड, Android सिस्टम तय करता है. फ़िलहाल, यह हर प्रोसेस के लिए करीब 70 किबीबाइट (केआईबी) है.

अपने ऐप्लिकेशन को ऑप्ट-इन करना

ऐप्लिकेशन मेनिफ़ेस्ट में android:gwpAsanMode टैग का इस्तेमाल करके, ऐप्लिकेशन हर प्रोसेस के लेवल पर GWP-ASan को चालू कर सकते हैं. ये विकल्प इस्तेमाल किए जा सकते हैं:

हमेशा बंद (android:gwpAsanMode="never"): यह सेटिंग आपके ऐप्लिकेशन में GWP-ASan को पूरी तरह से बंद कर देती है. साथ ही, यह नॉन-सिस्टम ऐप्लिकेशन के लिए डिफ़ॉल्ट सेटिंग होती है.
डिफ़ॉल्ट (android:gwpAsanMode="default" या तय नहीं किया गया): Android 13 (एपीआई लेवल 33) और इससे पहले के वर्शन - GWP-ASan बंद है. Android 14 (एपीआई लेवल 34) और इसके बाद के वर्शन - Recoverable GWP-ASan चालू है.
हमेशा चालू (android:gwpAsanMode="always"): यह सेटिंग आपके ऐप्लिकेशन में GWP-ASan को चालू करती है. इसमें ये शामिल हैं:
1. ऑपरेटिंग सिस्टम, GWP-ASan की कार्रवाइयों के लिए रैम का एक तय हिस्सा रिज़र्व रखता है. यह हिस्सा, हर प्रोसेस के लिए करीब ~70KiB होता है. (अगर आपके ऐप्लिकेशन पर मेमोरी के ज़्यादा इस्तेमाल से कोई खास असर नहीं पड़ता है, तो GWP-ASan को चालू करें.)
2. GWP-ASan, हीप ऐलोकेशन के किसी सबसेट को रैंडम तरीके से चुनता है और उसे एक खास जगह पर रखता है. इससे मेमोरी की सुरक्षा से जुड़े उल्लंघनों का पता लगाया जा सकता है.
3. जब खास मेमोरी रीजन में मेमोरी की सुरक्षा से जुड़े किसी नियम का उल्लंघन होता है, तो GWP-ASan प्रोसेस को बंद कर देता है.
4. GWP-ASan, क्रैश रिपोर्ट में गड़बड़ी के बारे में अतिरिक्त जानकारी देता है.

अपने ऐप्लिकेशन के लिए, GWP-ASan को दुनिया भर में चालू करने के लिए, अपनी AndroidManifest.xml फ़ाइल में यह कोड जोड़ें:

<application android:gwpAsanMode="always">
  ...
</application>

इसके अलावा, GWP-ASan को आपके ऐप्लिकेशन के कुछ सबप्रोसेस के लिए, साफ़ तौर पर चालू या बंद किया जा सकता है. उन प्रोसेस का इस्तेमाल करके, गतिविधियों और सेवाओं को टारगेट किया जा सकता है जिन्हें GWP-ASan में साफ़ तौर पर शामिल किया गया है या उससे बाहर रखा गया है. उदाहरण के लिए, यह देखें:

<application>
  <processes>
    <!-- Create the (empty) application process -->
    <process />

    <!-- Create subprocesses with GWP-ASan both explicitly enabled and disabled. -->
    <process android:process=":gwp_asan_enabled"
               android:gwpAsanMode="always" />
    <process android:process=":gwp_asan_disabled"
               android:gwpAsanMode="never" />
  </processes>

  <!-- Target services and activities to be run on either the GWP-ASan enabled or disabled processes. -->
  <activity android:name="android.gwpasan.GwpAsanEnabledActivity"
            android:process=":gwp_asan_enabled" />
  <activity android:name="android.gwpasan.GwpAsanDisabledActivity"
            android:process=":gwp_asan_disabled" />
  <service android:name="android.gwpasan.GwpAsanEnabledService"
           android:process=":gwp_asan_enabled" />
  <service android:name="android.gwpasan.GwpAsanDisabledService"
           android:process=":gwp_asan_disabled" />
</application>

ठीक किया जा सकने वाला GWP-ASan

Android 14 (एपीआई लेवल 34) और इसके बाद के वर्शन, Recoverable GWP-ASan के साथ काम करते हैं. इससे डेवलपर को प्रोडक्शन में, heap-buffer-overflow और heap-use-after-free बग ढूंढने में मदद मिलती है. इससे उपयोगकर्ता अनुभव पर भी कोई असर नहीं पड़ता. जब android:gwpAsanMode को AndroidManifest.xml में तय नहीं किया जाता है, तो ऐप्लिकेशन, रिकवर किए जा सकने वाले GWP-ASan का इस्तेमाल करता है.

Recoverable GWP-ASan और बेस GWP-ASan में ये अंतर हैं:

Recoverable GWP-ASan, ऐप्लिकेशन के हर बार लॉन्च होने पर चालू नहीं होता. यह सिर्फ़ 1% बार ही चालू होता है.
जब heap-use-after-free या heap-buffer-overflow बग का पता चलता है, तो यह बग, ऐप्लिकेशन के क्रैश होने की रिपोर्ट (टॉम्बस्टोन) में दिखता है. यह क्रैश रिपोर्ट, ActivityManager#getHistoricalProcessExitReasons एपीआई के ज़रिए उपलब्ध है. यह ओरिजनल GWP-ASan की तरह ही है.
Recoverable GWP-ASan, क्रैश रिपोर्ट को डंप करने के बाद बंद नहीं होता. यह मेमोरी करप्शन होने देता है और ऐप्लिकेशन चलता रहता है. हालांकि, प्रोसेस सामान्य रूप से जारी रह सकती है, लेकिन ऐप्लिकेशन के काम करने के तरीके के बारे में अब जानकारी नहीं दी जाती. मेमोरी करप्शन की वजह से, आने वाले समय में ऐप्लिकेशन कभी भी क्रैश हो सकता है. इसके अलावा, ऐसा भी हो सकता है कि ऐप्लिकेशन बिना किसी समस्या के काम करता रहे.
क्रैश रिपोर्ट डंप होने के बाद, रिकवर किए जा सकने वाले GWP-ASan को बंद कर दिया जाता है. इसलिए, ऐप्लिकेशन को हर बार लॉन्च करने पर, उसे रिकवर की जा सकने वाली सिर्फ़ एक GWP-ASan रिपोर्ट मिल सकती है.
अगर ऐप्लिकेशन में कस्टम सिग्नल हैंडलर इंस्टॉल किया गया है, तो उसे SIGSEGV सिग्नल के लिए कभी कॉल नहीं किया जाता. यह सिग्नल, GWP-ASan की ऐसी गड़बड़ी के बारे में बताता है जिसे ठीक किया जा सकता है.

Recoverable GWP-ASan के क्रैश होने से, असली उपयोगकर्ता के डिवाइसों पर मेमोरी के खराब होने के असल मामलों का पता चलता है. इसलिए, हमारा सुझाव है कि Recoverable GWP-ASan से पहचानी गई गड़बड़ियों को प्राथमिकता के आधार पर ठीक करें.

डेवलपर सहायता

इन सेक्शन में, GWP-ASan का इस्तेमाल करते समय होने वाली समस्याओं और उन्हें ठीक करने के तरीके के बारे में बताया गया है.

एलोकेशन/डीएलोकेशन ट्रेस मौजूद नहीं हैं

अगर आपको किसी ऐसे नेटिव क्रैश का विश्लेषण करना है जिसमें ऐलोकेशन/डीऐलोकेशन फ़्रेम मौजूद नहीं हैं, तो हो सकता है कि आपके ऐप्लिकेशन में फ़्रेम पॉइंटर मौजूद न हों. GWP-ASan, परफ़ॉर्मेंस को बेहतर बनाने के लिए फ़्रेम पॉइंटर का इस्तेमाल करता है. इससे मेमोरी के ऐलोकेशन और डीऐलोकेशन के ट्रेस रिकॉर्ड किए जाते हैं. अगर फ़्रेम पॉइंटर मौजूद नहीं हैं, तो GWP-ASan स्टैक ट्रेस को अनवाइंड नहीं कर पाता.

फ़्रेम पॉइंटर, arm64 डिवाइसों के लिए डिफ़ॉल्ट रूप से चालू होते हैं. वहीं, arm32 डिवाइसों के लिए डिफ़ॉल्ट रूप से बंद होते हैं. ऐप्लिकेशन के पास libc का कंट्रोल नहीं होता. इसलिए, आम तौर पर GWP-ASan के लिए 32-बिट वाले एक्ज़ीक्यूटेबल या ऐप्लिकेशन के लिए, ऐलोकेशन/डीऐलोकेशन ट्रेस इकट्ठा करना मुमकिन नहीं होता. 64-बिट वाले ऐप्लिकेशन को यह पक्का करना चाहिए कि वे -fomit-frame-pointer के साथ न बनाए गए हों, ताकि GWP-ASan, ऐलोकेशन और डीऐलोकेशन स्टैक ट्रेस इकट्ठा कर सके.

सुरक्षा से जुड़े उल्लंघनों को दोहराना

GWP-ASan को इस तरह से डिज़ाइन किया गया है कि यह उपयोगकर्ता के डिवाइसों पर, हीप मेमोरी की सुरक्षा से जुड़े उल्लंघनों का पता लगा सके. GWP-ASan, क्रैश के बारे में ज़्यादा से ज़्यादा जानकारी देता है. जैसे, उल्लंघन का ऐक्सेस ट्रेस, गड़बड़ी की वजह बताने वाली स्ट्रिंग, और ऐलोकेशन/डीऐलोकेशन ट्रेस. हालांकि, इसके बाद भी यह पता लगाना मुश्किल हो सकता है कि उल्लंघन कैसे हुआ. माफ़ करें, गड़बड़ी का पता लगाने की प्रोसेस, संभावना पर आधारित होती है. इसलिए, GWP-ASan की रिपोर्ट को किसी स्थानीय डिवाइस पर फिर से जनरेट करना अक्सर मुश्किल होता है.

ऐसे मामलों में, अगर गड़बड़ी का असर 64-बिट वाले डिवाइसों पर पड़ता है, तो आपको HWAddressSanitizer (HWASan) का इस्तेमाल करना चाहिए. HWASan, स्टैक, हीप, और ग्लोबल पर मेमोरी की सुरक्षा से जुड़े उल्लंघनों का पता लगाता है. HWASan के साथ अपना ऐप्लिकेशन चलाने पर, आपको वही नतीजा मिल सकता है जो GWP-ASan से मिलता है.

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

उदाहरण

इस उदाहरण में दिए गए नेटिव कोड में, हीप यूज़-आफ़्टर-फ़्री गड़बड़ी है:

#include <jni.h>
#include <string>
#include <string_view>

jstring native_get_string(JNIEnv* env) {
   std::string s = "Hellooooooooooooooo ";
   std::string_view sv = s + "World\n";

   // BUG: Use-after-free. `sv` holds a dangling reference to the ephemeral
   // string created by `s + "World\n"`. Accessing the data here is a
   // use-after-free.
   return env->NewStringUTF(sv.data());
}

extern "C" JNIEXPORT jstring JNICALL
Java_android11_test_gwpasan_MainActivity_nativeGetString(
    JNIEnv* env, jobject /* this */) {
  // Repeat the buggy code a few thousand times. GWP-ASan has a small chance
  // of detecting the use-after-free every time it happens. A single user who
  // triggers the use-after-free thousands of times will catch the bug once.
  // Alternatively, if a few thousand users each trigger the bug a single time,
  // you'll also get one report (this is the assumed model).
  jstring return_string;
  for (unsigned i = 0; i < 0x10000; ++i) {
    return_string = native_get_string(env);
  }

  return reinterpret_cast<jstring>(env->NewGlobalRef(return_string));
}

ऊपर दिए गए उदाहरण वाले कोड का इस्तेमाल करके टेस्ट रन करने पर, GWP-ASan ने गड़बड़ी का पता लगाया और नीचे दी गई क्रैश रिपोर्ट को ट्रिगर किया. GWP-ASan ने रिपोर्ट को अपने-आप बेहतर बना दिया है. इसके लिए, उसने क्रैश के टाइप, ऐलोकेशन मेटाडेटा, और उससे जुड़े ऐलोकेशन और डीऐलोकेशन स्टैक ट्रेस के बारे में जानकारी दी है.

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/sargo/sargo:10/RPP3.200320.009/6360804:userdebug/dev-keys'
Revision: 'PVT1.0'
ABI: 'arm64'
Timestamp: 2020-04-06 18:27:08-0700
pid: 16227, tid: 16227, name: 11.test.gwpasan  >>> android11.test.gwpasan <<<
uid: 10238
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x736ad4afe0
Cause: [GWP-ASan]: Use After Free on a 32-byte allocation at 0x736ad4afe0

backtrace:
      #00 pc 000000000037a090  /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::CheckNonHeapValue(char, art::(anonymous namespace)::JniValueType)+448)
      #01 pc 0000000000378440  /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::CheckPossibleHeapValue(art::ScopedObjectAccess&, char, art::(anonymous namespace)::JniValueType)+204)
      #02 pc 0000000000377bec  /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::Check(art::ScopedObjectAccess&, bool, char const*, art::(anonymous namespace)::JniValueType*)+612)
      #03 pc 000000000036dcf4  /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::CheckJNI::NewStringUTF(_JNIEnv*, char const*)+708)
      #04 pc 000000000000eda4  /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (_JNIEnv::NewStringUTF(char const*)+40)
      #05 pc 000000000000eab8  /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (native_get_string(_JNIEnv*)+144)
      #06 pc 000000000000edf8  /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (Java_android11_test_gwpasan_MainActivity_nativeGetString+44)
      ...

deallocated by thread 16227:
      #00 pc 0000000000048970  /apex/com.android.runtime/lib64/bionic/libc.so (gwp_asan::AllocationMetadata::CallSiteInfo::RecordBacktrace(unsigned long (*)(unsigned long*, unsigned long))+80)
      #01 pc 0000000000048f30  /apex/com.android.runtime/lib64/bionic/libc.so (gwp_asan::GuardedPoolAllocator::deallocate(void*)+184)
      #02 pc 000000000000f130  /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (std::__ndk1::_DeallocateCaller::__do_call(void*)+20)
      ...
      #08 pc 000000000000ed6c  /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >::~basic_string()+100)
      #09 pc 000000000000ea90  /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (native_get_string(_JNIEnv*)+104)
      #10 pc 000000000000edf8  /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (Java_android11_test_gwpasan_MainActivity_nativeGetString+44)
      ...

allocated by thread 16227:
      #00 pc 0000000000048970  /apex/com.android.runtime/lib64/bionic/libc.so (gwp_asan::AllocationMetadata::CallSiteInfo::RecordBacktrace(unsigned long (*)(unsigned long*, unsigned long))+80)
      #01 pc 0000000000048e4c  /apex/com.android.runtime/lib64/bionic/libc.so (gwp_asan::GuardedPoolAllocator::allocate(unsigned long)+368)
      #02 pc 000000000003b258  /apex/com.android.runtime/lib64/bionic/libc.so (gwp_asan_malloc(unsigned long)+132)
      #03 pc 000000000003bbec  /apex/com.android.runtime/lib64/bionic/libc.so (malloc+76)
      #04 pc 0000000000010414  /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (operator new(unsigned long)+24)
      ...
      #10 pc 000000000000ea6c  /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (native_get_string(_JNIEnv*)+68)
      #11 pc 000000000000edf8  /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (Java_android11_test_gwpasan_MainActivity_nativeGetString+44)
      ...

ज़्यादा जानकारी

GWP-ASan को लागू करने के बारे में ज़्यादा जानने के लिए, LLVM दस्तावेज़ देखें. Android नेटिव क्रैश की रिपोर्ट के बारे में ज़्यादा जानने के लिए, नेटिव क्रैश का विश्लेषण करना लेख पढ़ें.