Documentos vazados revelam que o Google planejou e, posteriormente, excluiu um recurso-chave de segurança do Pixel 11 para o GrapheneOS

O GrapheneOS, a versão derivada do Android com privacidade reforçada que vem instalada exclusivamente nos smartphones Pixel do Google há anos, afirma que não pode oferecer suporte adequado à nova série Pixel 11. Após uma semana tentando forçar a portabilidade, a equipe descobriu que o chip Tensor G6 do Pixel 11 não possui suporte de hardware para algo chamado Memory Tagging Extension, ou MTE, um recurso de segurança presente em todos os chips do Pixel desde o Pixel 8, em 2023.

Basicamente, eis o que o MTE faz: a memória do seu celular é uma enorme grade composta por pequenas caixas de armazenamento. Muitas vulnerabilidades funcionam induzindo um aplicativo a ler ou gravar na caixa errada, aquela que ele não deveria acessar. O MTE impede isso colando uma nota adesiva invisível em cada bloco de 16 bytes de memória e em cada ponteiro autorizado a acessá-lo. Se as notas adesivas não corresponderem quando um programa tentar ler ou gravar, o chip aciona os freios, encerrando o processo em vez de permitir silenciosamente que a vulnerabilidade seja explorada. O GrapheneOS utiliza o MTE em todo o seu sistema operacional e argumenta que ele elimina categorias inteiras de tentativas de invasão remota antes mesmo que elas possam começar. A equipe afirma que parece que o Google removeu o MTE do Pixel 11 para economizar dinheiro; o Google não se pronunciou. O GrapheneOS agora está orientando as pessoas a evitarem o Pixel 11 e, em vez disso, adquirirem um Pixel 8, 9 ou 10 caso queiram rodar o GrapheneOS.

Um artigo de pesquisa elaborado por pesquisadores da UT Austin, da UC Berkeley, do Google e da Ampere Computing (arXiv:2601.11786) nos dá uma ideia de quanto custa implementar o MTE em hardware real, o que também nos mostra o quanto uma empresa economiza ao dispensá-lo.

As próprias “notas adesivas” são bastante pequenas: 4 bits para cada 16 bytes de memória, ou cerca de 3,125% de sobrecarga. O manual de regras da ARM não especifica onde os fabricantes de chips devem armazenar essas “notas adesivas”, apenas que elas precisam existir em algum lugar. É por isso que as empresas adotam abordagens diferentes. O próprio projeto de referência da ARM reserva um bloco dedicado de RAM e realiza duas buscas de memória separadas em caso de falha de cache: uma para os dados e outra para a “nota adesiva”. A Ampere, fabricante de chips para servidores, por outro lado, anexa as notas aos bits normalmente utilizados para correção de erros e obtém os dados e a nota juntos em uma única operação. Nenhuma das abordagens é mais correta; a ARM incorporou essa flexibilidade propositalmente.

O custo maior não é os 3,125% extras de memória necessários no chip, mas o trabalho adicional que o chip precisa realizar a cada acesso à memória. Toda vez que seu celular acessa a memória, ele precisa verificar essa pequena marcação, o que requer circuitos de comparação dedicados. Atribuir tags aleatoriamente para que os invasores não possam prevê-las requer um gerador de números aleatórios integrado ao chip, e um gerador rápido com entropia suficiente é difícil de construir sem comprometer a qualidade. Algumas instruções especiais para gravar tags precisam de uma via própria no chip, em vez de reutilizar o caminho normal.

Pense em um núcleo de CPU fora de ordem como uma cozinha com vários cozinheiros trabalhando antecipadamente em diferentes partes de um pedido ao mesmo tempo, não necessariamente na sequência em que o pedido chegou, desde que nada dependa de algo que ainda não esteja pronto. É assim que, normalmente, um núcleo moderno “out-of-order” mantém sua velocidade: ele não fica esperando; trabalha no que puder enquanto as etapas mais lentas se atualizam.

O modo SYNC estrito do MTE atrapalha uma parte dessa cozinha: a gravação na memória. Normalmente, um núcleo pode gravar dados na memória e continuar trabalhando nas próximas instruções enquanto essa gravação é concluída em segundo plano. Mas, no modo SYNC do MTE, cada gravação precisa primeiro ter sua pequena tag verificada e confirmada como válida; e, até que essa verificação seja aprovada, o núcleo não tem permissão para avançar para a próxima gravação. Não é que toda a cozinha pare completamente: o preparo (leituras, cálculos, ramificações etc.) continua fora de ordem sem problemas. É especificamente a etapa de “colocar o prato pronto na mesa” que agora precisa ocorrer uma de cada vez, em ordem, enquanto se aguarda uma verificação de tag a cada vez. Códigos que gravam na memória repetidamente em um loop apertado sentem isso constantemente, e é exatamente por isso que alguns benchmarks ficaram até 6,64 vezes mais lentos. Códigos que, em sua maioria, leem, calculam ou realizam ramificações mal percebem isso, pois a parte do pipeline que ficou mais lenta não é aquela da qual dependem.

Mesmo no modo leve do MTE, o núcleo “Big” padrão ainda apresentou lentidão de até 1,82x, e esse é exatamente o modo que o próprio recurso de Proteção Avançada do Google utiliza atualmente. Enquanto isso, tanto o chip de servidor da Ampere quanto o novo M5 da Apple mal perceberam que o MTE estava ativado, apresentando uma sobrecarga média de apenas 2 a 3%, com uma desaceleração máxima de 10%. Essa diferença comprova que essas lentidões não são uma lei inevitável da física; elas refletem o quão bem (ou mal) os engenheiros de um determinado chip implementaram o recurso. E, conhecendo o Tensor, não esperamos muito dele.

Procure pelos mesmos itens no bootloader do Pixel 11 e você não encontrará nada. Nem um único vestígio. Essa é uma diferença bastante significativa: se o Google tivesse simplesmente desativado o MTE, seria de se esperar encontrar esses nomes de funções e mensagens no código, mesmo que não estivessem em uso. Sua ausência total sugere que o código foi removido por completo, e não apenas desativado. Isso corrobora exatamente o que a GrapheneOS afirmou após desistir de sua adaptação.

Por outro lado, a GrapheneOS está finalizando um acordo com a Motorola para levar o sistema operacional a um celular que não seja da linha Pixel pela primeira vez, enquanto a Qualcomm começou a adicionar suporte a MTE aos seus chips mais recentes, incluindo o Snapdragon 8 Elite Gen 5.

O NotebookCheck apurou que a Motorola está trabalhando em um smartphone emblemático com o codinome interno “Wukong”, desenvolvido em torno do próximo chip emblemático da Qualcomm, o Snapdragon 8 Elite Extreme Gen 6 (SM8975), que deve ser totalmente revelado no Snapdragon Summit em 22 de setembro. Até o momento, este é o único dispositivo da Motorola planejado com base nesse chip. Se o “Wukong” acabar sendo o smartphone de lançamento do GrapheneOS com a Motorola, ele será o primeiro a combinar suporte adequado a MTE, um chip topo de linha da Qualcomm e suporte ao GrapheneOS — algo que atualmente não é possível obter em um Pixel 11, independentemente do valor gasto.

É importante fazer a ressalva de praxe: nesta fase inicial de desenvolvimento, as especificações e até mesmo o codinome “Wukong” provêm de material interno e ainda podem sofrer alterações antes que qualquer informação seja oficializada. A Motorola ainda não confirmou a existência do aparelho.

Para a pessoa comum que compra um Pixel 11, não creio que a perda do MTE seja o desastre que esta matéria pode sugerir.

O MTE é probabilístico, não uma garantia absoluta. Há uma chance de 1 em 16 de que um determinado acesso fora dos limites passe completamente despercebido pela verificação de tag, e uma pesquisa citada no mesmo artigo (TikTag) violou o sigilo das tags em hardware real do Pixel por meio de execução especulativa, o que significa que mesmo a proteção que ele oferece não é, na prática, tão confiável quanto “15/16” sugere. E, fundamentalmente, quase nenhuma das vulnerabilidades com as quais um proprietário comum de celular realmente precisa se preocupar são, em primeiro lugar, bugs de segurança de memória. Phishing, permissões maliciosas de aplicativos, troca de SIM, stalkerware e invasões de contas — nada disso diz respeito ao que o MTE protege. Até mesmo o próprio GrapheneOS admite que a cobertura para aplicativos de terceiros é opcional e raramente utilizada; o Signal não a ativa.

Onde o MTE realmente mostra seu valor é no modelo de ameaça para o qual o próprio GrapheneOS foi projetado: cadeias de explorações “zero-click” caras e que dependem de confiabilidade, do tipo vendido por milhões de dólares e usado quase exclusivamente contra jornalistas, dissidentes e alvos governamentais, não contra o consumidor comum. Esse é um caso de uso real e importante. É apenas um caso de uso restrito. Um celular que trava em vez de ser silenciosamente comprometido é realmente muito importante se o senhor for um alvo de alto risco sob vigilância de um agente estatal. É muito menos relevante se o seu risco real for perder o celular em um bar ou clicar em um link malicioso em uma mensagem de texto. Praticar boas práticas de segurança operacional (OPSEC), usar senhas exclusivas, evitar códigos QR aleatórios e não espalhar suas informações pessoais por todos os sites que as solicitam oferecem, para a maioria das pessoas, uma proteção mais eficaz no mundo real do que qualquer recurso de segurança de memória em nível de silício jamais oferecerá.

Nada disso torna a regressão de silício do Pixel 11 uma questão sem importância. A base de usuários do GrapheneOS é exatamente o público para o qual isso é mais importante, e perder toda uma geração de suporte ao Pixel é um golpe significativo para esse projeto. Mas vale a pena ser honesto: o MTE parece muito mais uma medida de mitigação de alto valor para empresas ou usuários de alto risco que, por acaso, acabou sendo incorporada ao hardware de consumo do que um recurso cuja ausência a pessoa comum que comprar um Pixel 11 venha a notar. E há uma certa ironia na forma como o Google chegou a esse ponto: foi a própria empresa que impulsionou o MTE para o mainstream, incorporando-o ao Tensor antes de quase qualquer outro desenvolvedor no Android, financiando pesquisas sobre o tema e criando um modo de segurança inteiro em torno dele. Agora, seus próprios documentos internos sugerem que incorporou o MTE em seu próximo chip, descreveu-o detalhadamente e, em seguida, discretamente o removeu antes do lançamento. Ninguém superou o Google em engenharia nesse caso. A própria empresa, por meio de sua engenharia, acabou excluindo o recurso.