La mémoire non initialisée en C et C++ est une cause courante de problèmes de fiabilité, de bugs 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.
Mémoire de l'espace utilisateur initialisée à zéro
Depuis Android 12, la mémoire de la 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 zygote ni dans les applications.
Nous vous recommandons vivement d'utiliser l'indicateur de compilation -ftrivial-auto-var-init=zero pour initialiser à zéro les variables locales de la pile des applications propriétaires et tierces créées avec le NDK. Le compilateur élimine toute mise à zéro inutile.
Par exemple, lorsqu'une variable locale est explicitement initialisée (par exemple, la variable x de int x = 123; n'est initialisée qu'une seule fois).
Si le programme dispose d'un tampon de pile volumineux dans un point chaud de performances, le développeur peut désactiver l'initialisation à l'aide d'un attribut de compilateur:
__attribute__((__uninitialized__)) char buf[BUFSIZ];
Les applications peuvent également activer l'initialisation de la pile à zéro à l'aide de l'attribut de fichier manifeste android:nativeHeapZeroInitialized.
Vous pouvez également contrôler l'initialisation à zéro de la pile au moment de l'exécution avec:
int mallopt(M_BIONIC_ZERO_INIT, level)
où le niveau est 0 ou 1.
Mémoire du noyau initialisée à zéro
La pile et la mémoire tampon du noyau sont initialisées à 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 permet de compiler le noyau à l'aide de l'option de compilation -ftrivial-auto-var-init=zero.
Pour l'initialisation du tas, GKI utilise CONFIG_INIT_ON_ALLOC_DEFAULT_ON, ce qui fait que toutes les allocations de tas de pages, de SLAB et de SLUB sont initialisées à zéro lorsqu'elles sont créées. Cette option est semblable à la transmission de init_on_alloc=1 en tant qu'option de démarrage du kernel.
Rapports de bugs
Nos outils génèrent des rapports de bugs détaillés contenant des informations supplémentaires pour faciliter le débogage. La trace de pile d'allocation et de désallocation supplémentaire permet de mieux comprendre le cycle de vie d'une allocation donnée et de trouver beaucoup plus rapidement la cause des bugs de sécurité de la mémoire.
Lors du développement, les fournisseurs doivent surveiller la présence de bugs en vérifiant la présence de plantages natifs dans /data/tombstones et logcat. Pour en savoir plus sur le débogage du code natif Android, consultez cette page.