Memória não inicializada em C e C++ é uma causa comum de problemas de confiabilidade, bugs de segurança de memória e vazamentos de informações. Para evitar esses problemas, o Android inicializa o máximo de memória possível.
Memória de espaço do usuário inicializada zero
Desde o Android 12, a memória da pilha é zero.
em todo o código nativo da plataforma (incluindo JNI) e a memória heap for zero
inicializado em todos os processos nativos da plataforma (como netd).
mas não na zygote ou em apps.
Apps próprios e de terceiros criados com o NDK são altamente
recomendado usar a flag do compilador -ftrivial-auto-var-init=zero para inicializar a pilha no local correspondente
variáveis. O compilador otimiza qualquer zeramento desnecessário.
Por exemplo, quando uma variável local é explicitamente inicializada
Por exemplo, a variável x int x = 123; é inicializada apenas uma vez.
Se o programa tiver um buffer de pilha grande em um ambiente
ponto de acesso, o desenvolvedor pode desativar a inicialização usando um compilador
:
__attribute__((__uninitialized__)) char buf[BUFSIZ];
Os aplicativos também podem optar pela inicialização com zero de heap usando o
atributo de manifesto android:nativeHeapZeroInitialized.
Como alternativa, a inicialização zero do heap pode ser controlada no tempo de execução
por:
int mallopt(M_BIONIC_ZERO_INIT, level)
Quando o nível é 0 ou 1.
Memória do kernel inicializada zero
A pilha e a pilha do kernel são inicializadas em zero para kernels de GKI, o que é altamente recomendadas pelo CDD.
Para a inicialização de pilhas, o GKI usa o
CONFIG_INIT_STACK_ALL_ZERO, o que resulta na criação da
usando a flag de compilador -ftrivial-auto-var-init=zero.
Para a inicialização de heap, o GKI usa o
CONFIG_INIT_ON_ALLOC_DEFAULT_ON, que torna o heap de todas as páginas, SLAB
e alocações SLUB inicializadas de maneira zero quando são criadas. Essa opção é
É semelhante a transmitir init_on_alloc=1 como um kernel.
opção de tempo de inicialização.
Relatórios de bugs
Nossas ferramentas geram relatórios detalhados de bugs com mais informações para ajudar na depuração. O stack trace de alocação e desalocação adicional ajudam a entender melhor o ciclo de vida de uma determinada alocação e levar a bugs de segurança de memória raiz muito mais rápidos.
Durante o desenvolvimento, os fornecedores devem monitorar a presença de bugs verificando
/data/tombstones e
logcat para falhas nativas. Para mais informações sobre
depurar código nativo do Android, consulte as informações aqui.