AddressSanitizer

AddressSanitizer (ASan), तेज़ी से काम करने वाला एक कंपाइलर-आधारित टूल है. इसका इस्तेमाल, नेटिव कोड में मौजूद मेमोरी गड़बड़ियों का पता लगाने के लिए किया जाता है.

ASan इनका पता लगाता है:

  • स्टैक और हेप बफ़र ओवरफ़्लो/अंडरफ़्लो
  • फ़्री होने के बाद हीप का इस्तेमाल
  • स्कोप के बाहर स्टैक का इस्तेमाल करना
  • डबल फ़्री/वाइल्ड फ़्री

ASan, 32-बिट और 64-बिट ARM के साथ-साथ x86 और x86-64 पर काम करता है. ASan के सीपीयू पर होने वाला ओवरहेड करीब दो गुना होता है. कोड साइज़ का ओवरहेड 50% से दो गुना के बीच होता है. साथ ही, मेमोरी पर होने वाला ओवरहेड ज़्यादा होता है. यह आपके ऐलोकेशन पैटर्न पर निर्भर करता है, लेकिन यह दो गुना होता है.

AArch64 पर Android 10 और AOSP की नई रिलीज़ वाली शाखा, हार्डवेयर की मदद से काम करने वाले AddressSanitizer (HWASan) के साथ काम करती है. यह एक ऐसा टूल है जो रैम का कम इस्तेमाल करता है और ज़्यादा बग का पता लगाता है. HWASan, ASan से पता लगाई गई गड़बड़ियों के अलावा, रिटर्न के बाद स्टैक के इस्तेमाल का पता लगाता है.

HWASan में सीपीयू और कोड साइज़ का ओवरहेड एक जैसा है, लेकिन रैम का ओवरहेड बहुत कम (15%) है. HWASan, नॉन-डेटरमिनिस्टिक है. टैग की सिर्फ़ 256 संभावित वैल्यू होती हैं. इसलिए, किसी भी बग को छूटने की संभावना 0.4% होती है. HWASan में, ASan के सीमित साइज़ वाले रेड ज़ोन नहीं होते, ताकि ओवरफ़्लो का पता लगाया जा सके. साथ ही, इसमें सीमित क्षमता वाले क्वॉरंटीन भी नहीं होते, ताकि इस्तेमाल के बाद मेमोरी को फिर से इस्तेमाल करने से रोका जा सके. इसलिए, HWASan के लिए यह मायने नहीं रखता कि ओवरफ़्लो कितना बड़ा है या मेमोरी को कब डिएलोकेट किया गया था. इससे HWASan, ASan से बेहतर बनता है. HWASan के डिज़ाइन या Android पर HWASan के इस्तेमाल के बारे में ज़्यादा पढ़ा जा सकता है.

ASan, हेप ओवरफ़्लो के साथ-साथ स्टैक/ग्लोबल ओवरफ़्लो का पता लगाता है. साथ ही, यह कम से कम मेमोरी ओवरहेड के साथ तेज़ी से काम करता है.

इस दस्तावेज़ में, ASan की मदद से Android के कुछ हिस्सों या पूरे को बनाने और चलाने का तरीका बताया गया है. अगर ASan की मदद से SDK/NDK ऐप्लिकेशन बनाया जा रहा है, तो इसके बजाय Address Sanitizer देखें.

ASan की मदद से, अलग-अलग एक्सीक्यूटेबल को साफ़ करना

रन किए जा सकने वाले प्रोग्राम के लिए, बिल्कुल नए नियम में LOCAL_SANITIZE:=address या sanitize: { address: true } जोड़ें. मौजूदा उदाहरणों के लिए कोड खोजा जा सकता है या अन्य उपलब्ध सैनिटाइज़र ढूंढे जा सकते हैं.

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

ASan की मदद से, शेयर की गई लाइब्रेरी को सुरक्षित करना

ASan के काम करने के तरीके की वजह से, ASan की मदद से बनाई गई लाइब्रेरी का इस्तेमाल, सिर्फ़ ASan की मदद से बनाई गई किसी प्रोग्राम के साथ किया जा सकता है.

शेयर की गई ऐसी लाइब्रेरी को सैनिटाइज़ करने के लिए जिसका इस्तेमाल कई एक्सीक्यूटेबल में किया जाता है, आपको लाइब्रेरी की दो कॉपी की ज़रूरत होती है. हालांकि, इनमें से सभी लाइब्रेरी ASan के साथ नहीं बनाई जाती हैं. ऐसा करने का सुझाया गया तरीका यह है कि जिस मॉड्यूल के लिए यह करना है उसके लिए Android.mk में ये जोड़ें:

LOCAL_SANITIZE:=address
LOCAL_MODULE_RELATIVE_PATH := asan

इससे लाइब्रेरी, /system/lib के बजाय /system/lib/asan में दिखती है. इसके बाद, अपने एक्सीक्यूटेबल को इनके साथ चलाएं:

LD_LIBRARY_PATH=/system/lib/asan

सिस्टम डेमन के लिए, /init.rc या /init.$device$.rc के सही सेक्शन में ये जोड़ें.

setenv LD_LIBRARY_PATH /system/lib/asan

पुष्टि करें कि प्रोसेस, /proc/$PID/maps को पढ़कर /system/lib/asan की लाइब्रेरी का इस्तेमाल कर रही है. अगर ऐसा नहीं है, तो आपको SELinux को बंद करना पड़ सकता है:

adb root
adb shell setenforce 0
# restart the process with adb shell kill $PID
# if it is a system service, or may be adb shell stop; adb shell start.

बेहतर स्टैक ट्रेस

ASan, प्रोग्राम में मेमोरी के हर ऐलोकेशन और डिऐलोकेशन इवेंट के लिए, स्टैक ट्रैस रिकॉर्ड करने के लिए, फ़्रेम-पॉइंटर पर आधारित तेज़ अनवाइंडर का इस्तेमाल करता है. Android का ज़्यादातर हिस्सा, फ़्रेम पॉइंटर के बिना बनाया गया है. इस वजह से, आपको अक्सर एक या दो काम के फ़्रेम ही मिलते हैं. इसे ठीक करने के लिए, लाइब्रेरी को ASan (सुझाया गया!) या इनमें से किसी एक के साथ फिर से बनाएं:

LOCAL_CFLAGS:=-fno-omit-frame-pointer
LOCAL_ARM_MODE:=arm

इसके अलावा, प्रोसेस के एनवायरमेंट में ASAN_OPTIONS=fast_unwind_on_malloc=0 सेट करें. लोड के हिसाब से, बाद वाला तरीका सीपीयू पर बहुत ज़्यादा असर डाल सकता है.

सिंबलाइज़ेशन

शुरुआत में, ASan रिपोर्ट में बाइनरी और शेयर की गई लाइब्रेरी में ऑफ़सेट के रेफ़रंस होते हैं. सोर्स फ़ाइल और लाइन की जानकारी पाने के दो तरीके हैं:

  • पक्का करें कि llvm-symbolizer बाइनरी, /system/bin में मौजूद हो. llvm-symbolizer को third_party/llvm/tools/llvm-symbolizer में मौजूद सोर्स से बनाया गया है.
  • external/compiler-rt/lib/asan/scripts/symbolize.py स्क्रिप्ट की मदद से रिपोर्ट को फ़िल्टर करें.

होस्ट पर सिंबल वाली लाइब्रेरी उपलब्ध होने की वजह से, दूसरे तरीके से ज़्यादा डेटा (यानी file:line जगहें) मिल सकता है.

ऐप्लिकेशन में ASan

ASan, Java कोड में नहीं देख सकता. हालांकि, यह JNI लाइब्रेरी में मौजूद गड़बड़ियों का पता लगा सकता है. इसके लिए, आपको ASan की मदद से, एक्सीक्यूटेबल बनाना होगा, जो इस मामले में /system/bin/app_process(32|64) है. इससे, डिवाइस पर एक साथ सभी ऐप्लिकेशन में ASan चालू हो जाता है. यह डिवाइस पर ज़्यादा लोड डालता है. हालांकि, 2 जीबी रैम वाला डिवाइस इसे हैंडल कर सकता है.

frameworks/base/cmds/app_process में app_process के बिल्ड नियम में LOCAL_SANITIZE:=address जोड़ें. फ़िलहाल, उसी फ़ाइल में app_process__asan टारगेट को अनदेखा करें (अगर यह पढ़ते समय यह अब भी वहां मौजूद है).

class main वाली इंडेंट की गई लाइनों के ब्लॉक में ये लाइनें जोड़ने के लिए, सही system/core/rootdir/init.zygote(32|64).rc फ़ाइल के service zygote सेक्शन में बदलाव करें. इन लाइनों को भी उतनी ही इंडेंट करें जितनी इंडेंट की गई लाइनों में class main है:

    setenv LD_LIBRARY_PATH /system/lib/asan:/system/lib
    setenv ASAN_OPTIONS allow_user_segv_handler=true

बिल्ड, adb सिंक, फ़ास्टबूट फ़्लैश बूट, और रीबूट.

wrap प्रॉपर्टी का इस्तेमाल करना

पिछले सेक्शन में बताए गए तरीके से, सिस्टम के हर ऐप्लिकेशन में ASan को शामिल किया जाता है. असल में, Zygote प्रोसेस के हर डिससेंडेंट में इसे शामिल किया जाता है. ASan की मदद से, सिर्फ़ एक या कई ऐप्लिकेशन चलाए जा सकते हैं. इसके लिए, ऐप्लिकेशन के स्टार्टअप में थोड़ी देरी हो सकती है और मेमोरी का इस्तेमाल ज़्यादा हो सकता है.

ऐसा करने के लिए, अपने ऐप्लिकेशन को wrap. प्रॉपर्टी से शुरू करें. यहां दिए गए उदाहरण में, ASan के तहत Gmail ऐप्लिकेशन को चलाया गया है:

adb root
adb shell setenforce 0  # disable SELinux
adb shell setprop wrap.com.google.android.gm "asanwrapper"

इस संदर्भ में, asanwrapper /system/bin/app_process को /system/bin/asan/app_process में फिर से लिखता है, जिसे ASan के साथ बनाया गया है. यह डाइनैमिक लाइब्रेरी के खोज पाथ की शुरुआत में भी /system/lib/asan जोड़ता है. इस तरह, asanwrapper के साथ काम करते समय, /system/lib/asan की ASan-इंस्ट्रूमेंट की गई लाइब्रेरी को /system/lib की सामान्य लाइब्रेरी के बजाय प्राथमिकता दी जाती है.

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

SANITIZE_TARGET

Android 7.0 और इसके बाद के वर्शन में, पूरे Android प्लैटफ़ॉर्म को एक साथ ASan के साथ बनाने की सुविधा शामिल है. (अगर Android 9 से ज़्यादा वर्शन की रिलीज़ बनाई जा रही है, तो HWASan एक बेहतर विकल्प है.)

उसी बिल्ड ट्री में ये कमांड चलाएं.

make -j42
SANITIZE_TARGET=address make -j42

इस मोड में, userdata.img में अतिरिक्त लाइब्रेरी होती हैं और इन्हें डिवाइस पर भी फ़्लैश करना ज़रूरी होता है. यह कमांड लाइन इस्तेमाल करें:

fastboot flash userdata && fastboot flashall

इससे शेयर की गई लाइब्रेरी के दो सेट बनते हैं: /system/lib में सामान्य (पहला make invocation) और /data/asan/lib में ASan-instrumented (दूसरा make invocation). दूसरे बिल्ड के एक्सीक्यूटेबल, पहले बिल्ड के एक्सीक्यूटेबल को ओवरराइट कर देते हैं. ASan से इंस्ट्रूमेंट किए गए, रन किए जा सकने वाले प्रोग्राम को लाइब्रेरी का एक अलग सर्च पाथ मिलता है. इसमें PT_INTERP में /system/bin/linker_asan का इस्तेमाल करके, /system/lib से पहले /data/asan/lib शामिल होता है.

$SANITIZE_TARGET वैल्यू बदलने पर, बिल्ड सिस्टम इंटरमीडिएट ऑब्जेक्ट डायरेक्ट्री को मिटा देता है. इससे /system/lib में इंस्टॉल की गई बाइनरी को सुरक्षित रखते हुए, सभी टारगेट को फिर से बनाया जाता है.

कुछ टारगेट, ASan की मदद से नहीं बनाए जा सकते:

  • स्टैटिक तरीके से लिंक किए गए एक्सीक्यूटेबल
  • LOCAL_CLANG:=false टारगेट
  • LOCAL_SANITIZE:=false को SANITIZE_TARGET=address के लिए ASan नहीं किया गया है

इस तरह के एक्सीक्यूटेबल, SANITIZE_TARGET बिल्ड में शामिल नहीं किए जाते. साथ ही, पहले make अनुरोध का वर्शन /system/bin में ही छोड़ दिया जाता है.

इस तरह की लाइब्रेरी, ASan के बिना बनाई जाती हैं. इनमें उन स्टैटिक लाइब्रेरी का कुछ ASan कोड शामिल हो सकता है जिन पर ये निर्भर हैं.

सहायक दस्तावेज़