Memori yang tidak diinisialisasi dalam C dan C++ adalah penyebab umum masalah keandalan, bug keamanan memori, dan kebocoran informasi. Untuk menghindari masalah ini, Android menginisialisasi memori sebanyak mungkin.
Nol memori ruang pengguna yang diinisialisasi
Sejak Android 12, memori tumpukan diinisialisasi nol di semua kode asli platform (termasuk JNI) dan memori tumpukan diinisialisasi nol di semua proses asli platform (seperti netd ) tetapi tidak di zygote atau di aplikasi.
Aplikasi pihak pertama dan ketiga yang dibuat dengan NDK sangat disarankan untuk menggunakan flag compiler -ftrivial-auto-var-init=zero untuk menginisialisasi nol variabel lokal tumpukannya. Kompiler mengoptimalkan segala zeroing yang tidak diperlukan. Misalnya, ketika variabel lokal diinisialisasi secara eksplisit (misalnya, int x = 123; variabel x diinisialisasi hanya sekali). Jika program memiliki buffer tumpukan besar di hotspot kinerja, pengembang dapat menonaktifkan inisialisasi menggunakan atribut kompiler:
__attribute__((__uninitialized__)) char buf[BUFSIZ]; Aplikasi juga dapat ikut serta dalam inisialisasi heap zero dengan menggunakan atribut manifes android:nativeHeapZeroInitialized . Alternatifnya, inisialisasi heap zero dapat dikontrol saat runtime dengan:
int mallopt(M_BIONIC_ZERO_INIT, level)Dimana levelnya 0 atau 1.
Nol memori kernel yang diinisialisasi
Tumpukan dan heap kernel diinisialisasi nol untuk kernel GKI, yang sangat direkomendasikan oleh CDD .
Untuk inisialisasi tumpukan, 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, SLAB, dan SLUB halaman diinisialisasi nol saat dibuat. Opsi ini secara efektif mirip dengan meneruskan init_on_alloc=1 sebagai opsi waktu boot kernel.
Laporan bug
Alat kami menghasilkan laporan bug mendalam yang berisi informasi tambahan untuk membantu proses debug. Pelacakan tumpukan alokasi dan dealokasi tambahan membantu lebih memahami siklus hidup alokasi tertentu dan menyebabkan bug keamanan memori penyebab utama lebih cepat.
Selama pengembangan, vendor harus memantau keberadaan bug dengan memeriksa /data/tombstones dan logcat untuk melihat error asli. Untuk informasi lebih lanjut tentang debugging kode asli Android, lihat informasinya di sini .