La mémoire non initialisée en C et C++ est une cause fréquente de problèmes de fiabilité, de bogues de sécurité de la mémoire et de fuites d'informations. Pour éviter ces problèmes, Android initialise autant de mémoire que possible.
Zéro mémoire d'espace utilisateur initialisée
Depuis Android 12, la mémoire de pile est initialisée à zéro dans tout le code natif de la plate-forme (y compris JNI) et la mémoire du tas est initialisée à zéro dans tous les processus natifs de la plate-forme (tels que netd ), mais pas dans le zygote ou dans les applications.
Il est fortement recommandé aux applications propriétaires et tierces créées avec le NDK d'utiliser l'indicateur du compilateur -ftrivial-auto-var-init=zero pour initialiser à zéro leurs variables locales de pile. Le compilateur optimise toute remise à zéro inutile. Par exemple, lorsqu'une variable locale est explicitement initialisée (par exemple, int x = 123; la variable x n'est initialisée qu'une seule fois). Si le programme dispose d'un grand tampon de pile dans un hotspot de performances, le développeur peut désactiver l'initialisation à l'aide d'un attribut du compilateur :
__attribute__((__uninitialized__)) char buf[BUFSIZ]; Les applications peuvent également choisir d’initialiser le tas zéro en utilisant l’attribut manifeste android:nativeHeapZeroInitialized . Alternativement, l'initialisation du tas zéro peut être contrôlée au moment de l'exécution avec :
int mallopt(M_BIONIC_ZERO_INIT, level)Où le niveau est 0 ou 1.
Zéro mémoire de noyau initialisée
La pile et le tas du noyau sont initialisés à zéro pour les noyaux GKI, ce qui est fortement recommandé par le CDD .
Pour l'initialisation de la pile, GKI utilise la configuration CONFIG_INIT_STACK_ALL_ZERO , ce qui entraîne la construction du noyau à l'aide de l'indicateur du compilateur -ftrivial-auto-var-init=zero . Pour l'initialisation du tas, GKI utilise le CONFIG_INIT_ON_ALLOC_DEFAULT_ON , qui rend toutes les allocations de tas de page, SLAB et SLUB initialisées à zéro lors de leur création. Cette option est en fait similaire au passage init_on_alloc=1 comme option de démarrage du noyau.
Rapports de bogues
Nos outils génèrent des rapports de bogues perspicaces contenant des informations supplémentaires pour faciliter le débogage. La trace supplémentaire de la pile d'allocation et de désallocation aide à mieux comprendre le cycle de vie d'une allocation donnée et conduit beaucoup plus rapidement aux bogues de sécurité de la mémoire à l'origine des racines.
Pendant le développement, les fournisseurs doivent surveiller la présence de bogues en vérifiant /data/tombstones et logcat pour les plantages natifs. Pour plus d'informations sur le débogage du code natif Android, consultez les informations ici .