AddressSanitizer

AddressSanitizer (ASan) adalah alat cepat berbasis kompiler untuk mendeteksi {i>bug memori<i} dalam kode native.

ASan dapat mendeteksi:

  • Stack dan luapan/underflow buffer heap
  • Penggunaan heap setelah tersedia
  • Penggunaan stack di luar cakupan
  • Double free/wild free

ASan dapat dijalankan pada ARM 32 bit dan 64 bit, serta x86 dan x86-64. Overhead CPU ASan kurang lebih 2x, overhead ukuran kodenya antara 50% hingga 2x, dan overhead memori yang besar (bergantung pada pola alokasi Anda, tetapi dalam urutan 2x).

Android 10 dan cabang utama AOSP di AArch64 mendukung Hardware-assist AddressSanitizer (HWASan), alat serupa dengan {i>overhead<i} RAM yang lebih rendah dan berbagai bug yang terdeteksi. HWASan mendeteksi penggunaan stack setelah ditampilkan, selain bug yang terdeteksi oleh ASan.

HWASan memiliki overhead CPU dan ukuran kode yang serupa, tetapi overhead RAM yang jauh lebih kecil (15%). HWASan bersifat non-deterministik. Hanya ada 256 kemungkinan nilai tag, jadi ada nilai datar sebesar 0,4% kemungkinan hilangnya {i>bug<i} apa pun. HWASan tidak memiliki zona merah ukuran terbatas ASan untuk mendeteksi overflow dan karantina kapasitas terbatas untuk mendeteksi use-after-free, jadi tidak masalah bagi HWASan seberapa besar overflow atau berapa lama dibatalkan alokasinya. Hal ini membuat HWASan lebih baik daripada ASan. Anda dapat membaca lebih lanjut tentang desain HWASan atau tentang penggunaan HWASan di Android.

ASan mendeteksi overflow stack/global selain overflow heap, dan cepat dengan overhead memori minimal.

Dokumen ini menjelaskan cara membangun dan menjalankan sebagian/semua Android dengan ASan. Jika Anda membangun aplikasi SDK/NDK dengan ASan, lihat Address Sanitizer sebagai gantinya.

Membersihkan setiap file yang dapat dieksekusi dengan ASan

Tambahkan LOCAL_SANITIZE:=address atau sanitize: { address: true } ke aturan build untuk file yang dapat dieksekusi. Anda dapat menelusuri kode untuk contoh yang ada atau untuk menemukan pembersih lainnya yang tersedia.

Saat bug terdeteksi, ASan akan mencetak laporan panjang ke output standar dan ke logcat, lalu membuat proses error.

Membersihkan library bersama dengan ASan

Karena cara kerja ASan, library yang dibangun dengan ASan hanya dapat digunakan oleh yang dapat dieksekusi yang dibangun dengan ASan.

Untuk membersihkan pustaka bersama yang digunakan dalam banyak {i>executable<i}, tidak semua yang dibuat dengan ASan, Anda memerlukan dua salinan library. Cara yang direkomendasikan untuk melakukannya adalah dengan menambahkan kode berikut ke Android.mk untuk modul yang dimaksud:

LOCAL_SANITIZE:=address
LOCAL_MODULE_RELATIVE_PATH := asan

Tindakan ini akan menempatkan library di /system/lib/asan, bukan /system/lib. Kemudian, jalankan file yang dapat dieksekusi dengan:

LD_LIBRARY_PATH=/system/lib/asan

Untuk daemon sistem, tambahkan hal berikut ke bagian yang sesuai di /init.rc atau /init.$device$.rc.

setenv LD_LIBRARY_PATH /system/lib/asan

Memastikan bahwa proses tersebut menggunakan library dari /system/lib/asan saat ditampilkan dengan membaca /proc/$PID/maps. Jika tidak, Anda mungkin perlu untuk menonaktifkan 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.

Stack trace yang lebih baik

ASan menggunakan unwinder berbasis frame pointer yang cepat untuk merekam stack untuk setiap peristiwa alokasi dan dealokasi memori dalam program. Sebagian besar Android dibuat tanpa pointer frame. Akibatnya, Anda sering kali hanya mendapatkan satu atau dua frame yang bermakna. Untuk memperbaikinya, build ulang library dengan ASan (direkomendasikan), atau dengan:

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

Atau tetapkan ASAN_OPTIONS=fast_unwind_on_malloc=0 di lingkungan proses. Yang terakhir dapat sangat intensif CPU, bergantung pada beban.

Simbolisasi

Awalnya, laporan ASan berisi referensi ke offset dalam biner dan library. Ada dua cara untuk mendapatkan informasi baris dan file sumber:

  • Pastikan biner llvm-symbolizer ada di /system/bin. llvm-symbolizer dibuat dari sumber di third_party/llvm/tools/llvm-symbolizer.
  • Filter laporan melalui skrip external/compiler-rt/lib/asan/scripts/symbolize.py.

Pendekatan kedua dapat memberikan lebih banyak data (yaitu, file:line lokasi) karena ketersediaan library simbol pada {i>host<i}.

ASan dalam aplikasi

ASan tidak dapat melihat kode Java, tetapi dapat mendeteksi bug dalam library JDK. Untuk itu, Anda perlu mem-build file yang dapat dieksekusi dengan ASan, yang dalam hal ini adalah /system/bin/app_process(32|64). Hal ini memungkinkan ASan di semua aplikasi di perangkat secara bersamaan, yang merupakan beban berat, tetapi perangkat dengan RAM 2 GB akan dapat menanganinya.

Tambahkan LOCAL_SANITIZE:=address ke aturan build app_process di frameworks/base/cmds/app_process. Abaikan target app_process__asan dalam file yang sama untuk saat ini (jika target tersebut masih ada pada saat Anda membaca ini).

Edit bagian service zygote dari file system/core/rootdir/init.zygote(32|64).rc yang sesuai untuk menambahkan baris berikut ke blok baris indentasi yang berisi class main, juga diindentasi dengan jumlah yang sama:

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

Build, sinkronisasi adb, booting flash fastboot, dan mulai ulang.

Menggunakan properti wrap

Pendekatan di bagian sebelumnya menempatkan ASan ke dalam setiap aplikasi dalam sistem (sebenarnya, ke dalam setiap keturunan Zygote ). Anda hanya dapat menjalankan satu (atau beberapa) aplikasi dengan ASan, menukar beberapa overhead memori untuk startup aplikasi yang lebih lambat.

Hal ini dapat dilakukan dengan memulai aplikasi Anda dengan properti wrap.. Contoh berikut menjalankan aplikasi Gmail di ASan:

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

Dalam konteks ini, asanwrapper menulis ulang /system/bin/app_process ke /system/bin/asan/app_process, yang dibuat dengan ASan. Tindakan ini juga menambahkan /system/lib/asan di awal jalur penelusuran library dinamis. Dengan cara ini, ASan diinstrumentasikan library dari /system/lib/asan lebih disukai daripada library normal dalam /system/lib saat dijalankan dengan asanwrapper.

Jika bug ditemukan, aplikasi akan mengalami error, dan laporan akan dicetak ke log.

SANITIZE_TARGET

Android 7.0 dan yang lebih tinggi menyertakan dukungan untuk membangun seluruh platform Android dengan ASan sekaligus. (Jika Anda membangun rilis yang lebih tinggi dari Android 9, HWASan adalah pilihan yang lebih baik.)

Jalankan perintah berikut di hierarki build yang sama.

make -j42
SANITIZE_TARGET=address make -j42

Dalam mode ini, userdata.img berisi library tambahan dan juga harus di-flash ke perangkat. Gunakan command line berikut:

fastboot flash userdata && fastboot flashall

Cara ini membangun dua set pustaka bersama: normal di /system/lib (yang pertama melakukan pemanggilan), dan diinstrumentasi oleh ASan dalam /data/asan/lib (yang kedua melakukan pemanggilan). File yang dapat dieksekusi dari build kedua akan menimpa file dari build pertama. File yang dapat dijalankan dengan instrumentasi ASan mendapatkan jalur penelusuran library yang berbeda yang menyertakan /data/asan/lib sebelum /system/lib melalui penggunaan /system/bin/linker_asan di PT_INTERP.

Direktori objek perantara sistem build meng-clone saat Nilai $SANITIZE_TARGET telah diubah. Tindakan ini akan memaksa pembuatan ulang semua target sekaligus mempertahankan biner yang diinstal di /system/lib.

Beberapa target tidak dapat dibuat dengan ASan:

  • File yang dapat dieksekusi yang ditautkan secara statis
  • LOCAL_CLANG:=false target
  • LOCAL_SANITIZE:=false tidak ASan untuk SANITIZE_TARGET=address

File yang dapat dieksekusi seperti ini dilewati di build SANITIZE_TARGET, dan dari pemanggilan make yang pertama, ditinggalkan di /system/bin.

Library seperti ini dibuat tanpa ASan. File ini dapat berisi beberapa kode ASan dari library statis yang menjadi dependensinya.

Dokumentasi pendukung