Memori Inisialisasi Nol

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 nol diinisialisasi di semua kode asli platform (termasuk JNI) dan memori tumpukan nol diinisialisasi 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 semua zeroing yang tidak perlu. Misalnya, ketika variabel lokal diinisialisasi secara eksplisit (seperti, 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 . Atau, inisialisasi heap zero dapat dikontrol saat runtime dengan:

int mallopt(M_BIONIC_ZERO_INIT, level)

Dimana level 0 atau 1.

Nol memori kernel yang diinisialisasi

Stack 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 pembangunan 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 melewatkan init_on_alloc=1 sebagai opsi waktu boot kernel.

Laporan bug

Alat kami menghasilkan laporan bug berwawasan luas yang berisi informasi tambahan untuk membantu proses debug. Alokasi tambahan dan pelacakan tumpukan dealokasi membantu lebih memahami siklus hidup alokasi yang diberikan dan menyebabkan bug keamanan memori penyebab akar jauh lebih cepat.

Contoh laporan bug yang dihasilkan oleh alat keamanan memori
Gambar 1 : Laporan bug yang dihasilkan oleh alat keamanan memori

Selama pengembangan, vendor harus memantau keberadaan bug dengan memeriksa /data/tombstones dan logcat untuk kerusakan asli. Untuk informasi lebih lanjut tentang men-debug kode asli Android, lihat informasinya di sini .