Memori yang tidak diinisialisasi di C dan C++ adalah penyebab umum masalah keandalan, bug keamanan memori, dan kebocoran informasi. Untuk menghindari masalah ini, Android melakukan inisialisasi sebanyak mungkin memori.
Memori ruang pengguna yang diinisialisasi nol
Mulai Android 12, memori stack adalah nol yang diinisialisasi
di semua kode native platform (termasuk JNI) dan memori heap adalah nol
yang diinisialisasi di semua proses native platform (seperti netd)
tetapi tidak di zygote atau di aplikasi.
Aplikasi pihak pertama dan pihak ketiga yang di-build dengan NDK sangat
direkomendasikan untuk menggunakan flag compiler -ftrivial-auto-var-init=zero untuk melakukan inisialisasi nol pada variabel lokal
stack-nya. Compiler mengoptimalkan penghapusan nilai nol yang tidak perlu.
Misalnya, saat variabel lokal diinisialisasi secara eksplisit
(seperti, variabel int x = 123; x hanya diinisialisasi satu kali).
Jika program memiliki buffering stack yang besar di hotspot
performa, developer dapat menonaktifkan inisialisasi menggunakan atribut
compiler:
__attribute__((__uninitialized__)) char buf[BUFSIZ];
Aplikasi juga dapat memilih untuk melakukan inisialisasi heap nol menggunakan
atribut manifes android:nativeHeapZeroInitialized.
Atau, inisialisasi nol heap dapat dikontrol saat runtime
dengan:
int mallopt(M_BIONIC_ZERO_INIT, level)
Dengan level 0 atau 1.
Memori kernel yang diinisialisasi nol
Stack dan heap kernel diinisialisasi ke nol untuk kernel GKI, yang sangat direkomendasikan oleh CDD.
Untuk inisialisasi stack, GKI menggunakan
konfigurasi CONFIG_INIT_STACK_ALL_ZERO, yang menghasilkan pembuatan
kernel menggunakan flag compiler -ftrivial-auto-var-init=zero.
Untuk inisialisasi heap, GKI menggunakan
CONFIG_INIT_ON_ALLOC_DEFAULT_ON, yang membuat semua alokasi heap halaman, SLAB,
dan SLUB diinisialisasi nol saat dibuat. Opsi ini
secara efektif mirip dengan meneruskan init_on_alloc=1 sebagai opsi
waktu booting kernel.
Laporan bug
Alat kami menghasilkan laporan bug yang mendalam yang berisi informasi tambahan untuk membantu proses debug. Pelacakan tumpukan alokasi dan dealokasi tambahan membantu lebih memahami siklus proses alokasi tertentu dan mengarah ke bug keamanan memori yang menyebabkan root dengan lebih cepat.
Selama pengembangan, vendor harus memantau keberadaan bug dengan memeriksa
/data/tombstones dan
logcat untuk menemukan error native. Untuk informasi selengkapnya tentang
proses debug kode native Android, lihat informasi di sini.