Travamentos SIGSEGV com código 9 (SEGV_MTSERR) ou código 8 (SEGV_MTEAERR) são falhas de Memory Tagging. Memory Tagging Extension (MTE) é um recurso Armv9 com suporte no Android 12 e posterior. MTE é uma implementação de hardware de memória marcada. Ele fornece proteção de memória refinada para detecção e mitigação de bugs de segurança de memória .
Em C/C++, um ponteiro retornado de uma chamada para malloc() ou operador new() ou funções semelhantes só pode ser usado para acessar a memória dentro dos limites dessa alocação e somente enquanto a alocação estiver ativa (não liberada ou delete-ed). O MTE é usado no Android para detectar violações desta regra, referidas nos relatórios de travamento como problemas de "Buffer Overflow"/"Buffer Underflow" e "Use After Free".
O MTE possui dois modos: síncrono (ou "sincronizado") e assíncrono (ou "assíncrono"). O primeiro funciona mais lentamente, mas fornece diagnósticos mais precisos. O último é executado mais rápido, mas só pode fornecer detalhes aproximados. Abordaremos ambos separadamente, pois os diagnósticos são ligeiramente diferentes.
Modo síncrono MTE
No modo síncrono ("sync") do MTE, o SIGSEGV trava com o código 9 (SEGV_MTSERR).
pid: 13935, tid: 13935, name: sanitizer-statu >>> sanitizer-status <<< uid: 0 tagged_addr_ctrl: 000000000007fff3 signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x800007ae92853a0 Cause: [MTE]: Use After Free, 0 bytes into a 32-byte allocation at 0x7ae92853a0 x0 0000007cd94227cc x1 0000007cd94227cc x2 ffffffffffffffd0 x3 0000007fe81919c0 x4 0000007fe8191a10 x5 0000000000000004 x6 0000005400000051 x7 0000008700000021 x8 0800007ae92853a0 x9 0000000000000000 x10 0000007ae9285000 x11 0000000000000030 x12 000000000000000d x13 0000007cd941c858 x14 0000000000000054 x15 0000000000000000 x16 0000007cd940c0c8 x17 0000007cd93a1030 x18 0000007cdcac6000 x19 0000007fe8191c78 x20 0000005800eee5c4 x21 0000007fe8191c90 x22 0000000000000002 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007fe8191b70 lr 0000005800eee0bc sp 0000007fe8191b60 pc 0000005800eee0c0 pst 0000000060001000 backtrace: #00 pc 00000000000010c0 /system/bin/sanitizer-status (test_crash_malloc_uaf()+40) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #01 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #02 pc 00000000000019cc /system/bin/sanitizer-status (main+1032) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #03 pc 00000000000487d8 /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+96) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) deallocated by thread 13935: #00 pc 000000000004643c /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::quarantineOrDeallocateChunk(scudo::Options, void*, scudo::Chunk::UnpackedHeader*, unsigned long)+688) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #01 pc 00000000000421e4 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::deallocate(void*, scudo::Chunk::Origin, unsigned long, unsigned long)+212) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #02 pc 00000000000010b8 /system/bin/sanitizer-status (test_crash_malloc_uaf()+32) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #03 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) allocated by thread 13935: #00 pc 0000000000042020 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::allocate(unsigned long, scudo::Chunk::Origin, unsigned long, bool)+1300) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #01 pc 0000000000042394 /apex/com.android.runtime/lib64/bionic/libc.so (scudo_malloc+36) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #02 pc 000000000003cc9c /apex/com.android.runtime/lib64/bionic/libc.so (malloc+36) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #03 pc 00000000000010ac /system/bin/sanitizer-status (test_crash_malloc_uaf()+20) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #04 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30)
Todos os relatórios de travamento do MTE contêm o despejo de registro usual e o backtrace para o ponto em que o problema foi detectado. A linha "Causa:" para um erro detectado pelo MTE conterá "[MTE]" como no exemplo acima, juntamente com mais detalhes. Neste caso, o tipo específico de erro detectado foi "Use after free" e "0 bytes into a 32-byte alocation at 0x7ae92853a0" nos informa o tamanho e o endereço da alocação e o deslocamento na alocação que tentou acessar.
Os relatórios de travamento do MTE também incluem backtraces extras, não apenas aquele do ponto de detecção.
Os erros "Use After Free" adicionam as seções "desalocado por" e "alocado por" ao despejo de memória, mostrando os rastreamentos de pilha no momento em que esta memória foi desalocada (antes de ser usada!) e o tempo em que foi alocada anteriormente. Eles também informam qual thread fez a alocação/desalocação. Todos os três threads de detecção, thread de alocação e thread de desalocação são os mesmos neste exemplo simples, mas em casos mais complexos do mundo real isso não é necessariamente verdade, e saber que eles diferem pode ser uma pista importante para encontrar uma simultaneidade -bug relacionado.
Os erros "Buffer Overflow" e "Buffer Underflow" fornecem apenas uma faixa de pilha "alocada por" adicional, pois, por definição, eles ainda não foram desalocados (ou apareceriam como "Use After Free"):
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 32-byte allocation at 0x7ae92853a0 [...] backtrace: [...] allocated by thread 13949:
Observe o uso da palavra "certo" aqui: isso significa que estamos informando quantos bytes após o final da alocação o acesso incorreto estava; um underflow diria "esquerda" e seria um número de bytes antes do início da alocação.
Múltiplas causas potenciais
Às vezes, os relatórios SEGV_MTSERR contêm a seguinte linha:
Note: multiple potential causes for this crash were detected, listing them in decreasing order of likelihood.
Isso acontece quando existem vários bons candidatos para a origem do erro e não podemos dizer qual é a causa real. Imprimimos até 3 desses candidatos em ordem aproximada de probabilidade e deixamos a análise por conta do usuário.
signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x400007b43063db5
backtrace:
[stack...]
Note: multiple potential causes for this crash were detected, listing them in decreasing order of probability.
Cause: [MTE]: Use After Free, 5 bytes into a 10-byte allocation at 0x7b43063db0
deallocated by thread 6663:
[stack...]
allocated by thread 6663:
[stack...]
Cause: [MTE]: Use After Free, 5 bytes into a 6-byte allocation at 0x7b43063db0
deallocated by thread 6663:
[stack...]
allocated by thread 6663:
[stack...]No exemplo acima, detectamos duas alocações recentes no mesmo endereço de memória que poderiam ter sido o alvo pretendido do acesso inválido à memória. Isso pode acontecer quando as alocações reutilizam memória livre - por exemplo, se você tiver a sequência como novo, livre, novo, livre, novo, livre, acesso. A alocação mais recente é impressa primeiro.
Heurística detalhada de determinação de causa
A "Causa" de uma falha deve mostrar a alocação de memória da qual o ponteiro acessado foi originalmente derivado. Infelizmente, o hardware MTE não tem como traduzir de um ponteiro com uma tag incompatível para uma alocação. Para explicar uma falha SEGV_MTSERR, o Android analisa os seguintes dados:
- O endereço da falha (incluindo a tag do ponteiro).
- Uma lista de alocações de heap recentes com rastreamentos de pilha e tags de memória.
- Alocações atuais (ao vivo) próximas e suas tags de memória.
Qualquer memória desalocada recentemente no endereço de falha onde a tag de memória corresponde à tag de endereço de falha é uma causa potencial de "Usar após liberar".
Qualquer memória ativa próxima em que o tag de memória corresponda ao tag de endereço de falha é uma causa potencial de "estouro de buffer" (ou "fluxo insuficiente de buffer").
As alocações mais próximas da falha - seja no tempo ou no espaço - são consideradas mais prováveis do que as mais distantes.
Como a memória desalocada é frequentemente reutilizada e o número de valores de tags diferentes é pequeno (menos de 16), não é incomum encontrar vários candidatos prováveis e não há como encontrar automaticamente a verdadeira causa. Esta é a razão pela qual, às vezes, os relatórios MTE listam várias causas potenciais.
É recomendável que o desenvolvedor do aplicativo analise as possíveis causas, começando pela mais provável. Geralmente é fácil filtrar causas não relacionadas com base no rastreamento de pilha.
Modo assíncrono MTE
No modo assíncrono ("assíncrono") do MTE, o SIGSEGV falha com o código 8 (SEGV_MTEAERR).
As falhas SEGV_MTEAERR não acontecem imediatamente quando um programa realiza um acesso inválido à memória. O problema é detectado logo após o evento e, em vez disso, o programa é encerrado nesse ponto. Este ponto é normalmente a próxima chamada do sistema, mas também pode ser uma interrupção do timer - em resumo, qualquer transição do espaço do usuário para o kernel.
As falhas SEGV_MTEAERR não preservam o endereço de memória (é sempre mostrado como "-------"). O backtrace corresponde ao momento em que a condição foi detectada (ou seja, na próxima chamada do sistema ou outra troca de contexto), e não quando o acesso inválido foi realizado.
Isso significa que o backtrace "principal" em uma falha MTE assíncrona geralmente não é relevante . As falhas do modo assíncrono são, portanto, muito mais difíceis de depurar do que as falhas do modo de sincronização. Eles são melhor compreendidos como mostrando a existência de um bug de memória no código próximo no thread fornecido. Os logs na parte inferior do arquivo tombstone podem fornecer uma dica do que realmente aconteceu. Caso contrário, o curso de ação recomendado é reproduzir o erro no modo de sincronização e usar os melhores diagnósticos que o modo de sincronização fornece!
tópicos avançados
Sob o capô, a marcação de memória funciona atribuindo um valor de tag aleatório de 4 bits (0..15) a cada alocação de heap. Esse valor é armazenado em uma região especial de metadados que corresponde à memória heap alocada. O mesmo valor é atribuído ao byte mais significativo do ponteiro de heap retornado de funções como malloc() ou operator new().
Quando a verificação de tags é habilitada no processo, a UCP compara automaticamente o byte superior do ponteiro com o tag de memória para cada acesso à memória. Se as tags não coincidirem, a CPU sinaliza um erro que leva a uma falha.
Devido ao número limitado de possíveis valores de tag, essa abordagem é probabilística. Qualquer local de memória que não deva ser acessado com um determinado ponteiro - como fora dos limites ou após desalocação ("ponteiro pendente") - provavelmente terá um valor de tag diferente e causará uma falha. Há uma chance de aproximadamente 7% de não detectar nenhuma ocorrência única de um bug. Como os valores das tags são atribuídos aleatoriamente, há uma chance independente de aproximadamente 93% de detectar o bug na próxima vez que ele ocorrer.
Os valores dos tags podem ser vistos no campo de endereço da falha, bem como no dump do registrador, conforme destacado abaixo. Esta seção pode ser usada para verificar se os tags estão configurados de maneira sã, bem como para ver outras alocações de memória próximas com o mesmo valor de tag, pois podem ser causas potenciais do erro além das listadas no relatório. Esperamos que isso seja útil principalmente para as pessoas que trabalham na implementação do próprio MTE ou de outros componentes de sistema de baixo nível, e não para desenvolvedores.
signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x0800007ae92853a0 Cause: [MTE]: Use After Free, 0 bytes into a 32-byte allocation at 0x7ae92853a0 x0 0000007cd94227cc x1 0000007cd94227cc x2 ffffffffffffffd0 x3 0000007fe81919c0 x4 0000007fe8191a10 x5 0000000000000004 x6 0000005400000051 x7 0000008700000021 x8 0800007ae92853a0 x9 0000000000000000 x10 0000007ae9285000 x11 0000000000000030 x12 000000000000000d x13 0000007cd941c858 x14 0000000000000054 x15 0000000000000000 x16 0000007cd940c0c8 x17 0000007cd93a1030 x18 0000007cdcac6000 x19 0000007fe8191c78 x20 0000005800eee5c4 x21 0000007fe8191c90 x22 0000000000000002 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007fe8191b70 lr 0000005800eee0bc sp 0000007fe8191b60 pc 0000005800eee0c0 pst 0000000060001000
Uma seção especial "Etiquetas de memória" também aparece no relatório de travamento que mostra as etiquetas de memória ao redor do endereço da falha. No exemplo abaixo, a tag de ponteiro "4" não corresponde à tag de memória "a".
Memory tags around the fault address (0x0400007b43063db5), one tag per 16 bytes: 0x7b43063500: 0 f 0 2 0 f 0 a 0 7 0 8 0 7 0 e 0x7b43063600: 0 9 0 8 0 5 0 e 0 f 0 c 0 f 0 4 0x7b43063700: 0 b 0 c 0 b 0 2 0 1 0 4 0 7 0 8 0x7b43063800: 0 b 0 c 0 3 0 a 0 3 0 6 0 b 0 a 0x7b43063900: 0 3 0 4 0 f 0 c 0 3 0 e 0 0 0 c 0x7b43063a00: 0 3 0 2 0 1 0 8 0 9 0 4 0 3 0 4 0x7b43063b00: 0 5 0 2 0 5 0 a 0 d 0 6 0 d 0 2 0x7b43063c00: 0 3 0 e 0 f 0 a 0 0 0 0 0 0 0 4 =>0x7b43063d00: 0 0 0 a 0 0 0 e 0 d 0 [a] 0 f 0 e 0x7b43063e00: 0 7 0 c 0 9 0 a 0 d 0 2 0 0 0 c 0x7b43063f00: 0 0 0 6 0 b 0 8 0 3 0 0 0 5 0 e 0x7b43064000: 0 d 0 2 0 7 0 a 0 7 0 a 0 d 0 8 0x7b43064100: 0 b 0 2 0 b 0 4 0 1 0 6 0 d 0 4 0x7b43064200: 0 1 0 6 0 f 0 2 0 f 0 6 0 5 0 c 0x7b43064300: 0 1 0 4 0 d 0 6 0 f 0 e 0 1 0 8 0x7b43064400: 0 f 0 4 0 3 0 2 0 1 0 2 0 5 0 6
As seções de uma lápide que mostram o conteúdo da memória em torno de todos os valores de registro também exibem seus valores de tag.
memory near x10 ([anon:scudo:primary]): 0000007b4304a000 7e82000000008101 000003e9ce8b53a0 .......~.S...... 0700007b4304a010 0000200000006001 0000000000000000 .`... .......... 0000007b4304a020 7c03000000010101 000003e97c61071e .......|..a|.... 0200007b4304a030 0c00007b4304a270 0000007ddc4fedf8 p..C{.....O.}... 0000007b4304a040 84e6000000008101 000003e906f7a9da ................ 0300007b4304a050 ffffffff00000042 0000000000000000 B............... 0000007b4304a060 8667000000010101 000003e9ea858f9e ......g......... 0400007b4304a070 0000000100000001 0000000200000002 ................ 0000007b4304a080 f5f8000000010101 000003e98a13108b ................ 0300007b4304a090 0000007dd327c420 0600007b4304a2b0 .'.}......C{... 0000007b4304a0a0 88ca000000010101 000003e93e5e5ac5 .........Z^>.... 0a00007b4304a0b0 0000007dcc4bc500 0300007b7304cb10 ..K.}......s{... 0000007b4304a0c0 0f9c000000010101 000003e9e1602280 ........."`..... 0900007b4304a0d0 0000007dd327c780 0700007b7304e2d0 ..'.}......s{... 0000007b4304a0e0 0d1d000000008101 000003e906083603 .........6...... 0a00007b4304a0f0 0000007dd327c3b8 0000000000000000 ..'.}...........