Memori yang tidak diinisialisasi dalam C dan C++ adalah penyebab umum masalah keandalan, {i>bug<i} keamanan memori dan kebocoran informasi. Untuk menghindari masalah tersebut, Android menginisialisasi memori sebanyak mungkin.
Tidak ada memori userspace yang diinisialisasi
Sejak Android 12, memori stack diinisialisasi nol
di semua kode native platform (termasuk JNI) dan memori heap adalah nol
diinisialisasi di semua proses native platform (seperti netd)
tetapi tidak di zygote atau dalam aplikasi.
Aplikasi pihak pertama dan ketiga yang dibangun dengan NDK sangat
sebaiknya gunakan flag compiler -ftrivial-auto-var-init=zero untuk menginisialisasi nol lokal stack-nya
variabel. Compiler mengoptimalkan setiap zeroing yang tidak perlu.
Misalnya, saat variabel lokal secara eksplisit diinisialisasi
(misalnya, variabel int x = 123; x hanya diinisialisasi sekali).
Jika program memiliki buffer stack besar dalam performa
hotspot, developer dapat menonaktifkan inisialisasi menggunakan compiler
:
__attribute__((__uninitialized__)) char buf[BUFSIZ];
Aplikasi juga bisa memilih untuk menggunakan inisialisasi nol heap dengan menggunakan
Atribut manifes android:nativeHeapZeroInitialized.
Atau, inisialisasi nol heap dapat dikontrol saat runtime
dengan:
int mallopt(M_BIONIC_ZERO_INIT, level)
Di mana levelnya 0 atau 1.
Tidak ada memori kernel yang diinisialisasi
Tumpukan dan heap kernel adalah nol yang diinisialisasi untuk kernel GKI, yang sangat direkomendasikan oleh CDD.
Untuk inisialisasi stack, GKI menggunakan
CONFIG_INIT_STACK_ALL_ZERO, yang menghasilkan
{i>kernel<i} menggunakan penanda compiler -ftrivial-auto-var-init=zero.
Untuk inisialisasi heap, GKI menggunakan
CONFIG_INIT_ON_ALLOC_DEFAULT_ON, yang membuat semua halaman menjadi heap, SLAB
dan alokasi SLUB diinisialisasi nol saat dibuat. Opsi ini
efektif mirip dengan meneruskan init_on_alloc=1 sebagai kernel
opsi boot-time.
Laporan bug
Alat kami menghasilkan laporan bug bermanfaat yang berisi informasi tambahan untuk membantu proses debug. Alokasi tambahan dan dealokasi stack trace membantu lebih memahami siklus hidup dari alokasi tertentu dan mengarah pada {i>bug<i} keamanan memori yang menyebabkan {i>root <i}jauh lebih cepat.
Selama pengembangan, vendor harus memantau keberadaan {i>bug<i} dengan memeriksa
/data/tombstones dan
logcat untuk masalah pada native code. Untuk mengetahui informasi
selengkapnya tentang
untuk men-debug kode native Android, lihat informasinya di sini.