GPUThor: ataque Rowhammer contorna a proteção ECC das GPU Nvidia

Investigadores da Universidade de Toronto revelaram, no final de agosto, uma nova técnica de ataque batizada GPUThor, capaz de contornar a proteção ECC (código de correção de erros) integrada nas GPU da Nvidia. O método, baseado no princípio do Rowhammer, foi validado em GPU de estação de trabalho com arquitetura Ampere e memória GDDR6 — as RTX A4000, A4500, A5000 e A6000 —, modelos amplamente usados em infraestruturas de IA e de nuvem. A equipa notificou a Nvidia a 29 de abril, e a empresa publicou recomendações de mitigação a 25 de agosto, após cerca de quatro meses de divulgação coordenada.

Porque é que o ECC é indispensável numa GPU de IA

Um chip de memória sob carga intensa pode sofrer, de forma aleatória, uma «inversão de bit»: um bit guardado como 0 muda acidentalmente para 1, ou vice-versa, por efeito de raios cósmicos, interferência elétrica ou defeitos de fabrico. No uso quotidiano, uma inversão isolada passa muitas vezes despercebida. Mas no treino ou na inferência de um modelo de IA, pode corromper diretamente pesos, gradientes ou valores de ativação — desviando silenciosamente um treino ou produzindo, em inferência, uma resposta errada mas plausível, sem qualquer aviso. É exatamente para isso que existe o ECC: ao guardar um código de verificação adicional junto de cada bloco de memória, o sistema corrige automaticamente erros de um bit e deteta erros de dois bits, um esquema conhecido como SECDED. É essa garantia que permite aos fornecedores de nuvem partilhar com confiança uma mesma GPU física entre vários clientes.

Como o GPUThor derruba a proteção ECC

O GPUThor martela a memória segundo um padrão deliberadamente não uniforme, explorando ainda dois comportamentos da GPU que a Nvidia nunca tinha documentado: a forma como o chip agrupa (coalesce) pedidos repetidos de acesso à memória, e com que frequência o mecanismo Target Row Refresh (TRR) da memória GDDR6 é efetivamente acionado. Ao manter-se mesmo abaixo do limiar de deteção do TRR, o GPUThor consegue martelar continuamente uma linha de memória alvo, provocando inversões de bit nas linhas vizinhas.

• Nas GPU testadas sem ECC ativado, o GPUThor provocou entre 72 mil e 377 mil inversões de bit por gigabyte de memória — até 23.597 vezes mais do que o ataque anterior da equipa, o GPUHammer.
• Mesmo com o ECC ativado, o GPUThor gerou 387 erros de dois bits (que o ECC deteta mas não corrige) e dois erros de três bits, que ultrapassam a capacidade de correção do ECC e provocaram corrupção de dados.
• Encontrar uma inversão de bit explorável leva agora, em média, cerca de 1,1 minutos, contra 21,9 horas com o GPUHammer.
• Um ataque sustentado a uma RTX A6000 com ECC ativado pode forçar a GPU a reiniciar a cada duas horas, interrompendo todas as tarefas em curso; repetido, pode levar a placa a assinalar-se como necessitando de substituição.

Para além da negação de serviço, os investigadores demonstraram um cenário mais grave: ao corromper as tabelas de páginas da GPU, um programa CUDA sem privilégios especiais pode obter acesso arbitrário à memória e abrir uma shell root na máquina anfitriã — transformando uma simples tarefa de computação em GPU no controlo total do servidor. As GPU de centro de dados da geração Ampere, como a A100, resistem melhor à negação de serviço mas continuam vulneráveis à escalada de privilégios; mesmo as GPU Blackwell com proteção RAS Repair apenas tornam o ataque mais demorado, sem o impedir. Os investigadores alertam que futuras GPU com GDDR7 ou HBM3e, com ECC integrado na própria memória, podem continuar vulneráveis em cenários de inversões de múltiplos bits.

Quem está realmente exposto

O GPUThor visa os clusters de GPU de centros de dados que sustentam o treino e a inferência de IA, em particular as instâncias de GPU em nuvem multi-inquilino — o modelo predefinido da maioria das ofertas de GPU em nuvem pública, em que vários clientes partilham a mesma placa física. Um atacante que alugue apenas uma pequena fatia de tempo de computação poderia perturbar, ou mesmo corromper, o treino ou a inferência de outro cliente alojado no mesmo hardware — um risco invisível a partir da camada de aplicação. As recomendações da Nvidia centram-se no isolamento e na monitorização: ativar o SYS-ECC e o isolamento IOMMU/DMA, monitorizar continuamente a telemetria de erros da GPU e restringir a partilha de cargas CUDA não fiáveis no mesmo hardware.

O que isto muda para as empresas portuguesas

Empresas portuguesas que treinam ou executam modelos de IA alugando instâncias de GPU a fornecedores como AWS, Microsoft Azure, Google Cloud ou operadores locais mais pequenos dependem, na prática, de uma GPU física raramente dedicada — quase sempre partilhada com outros clientes. O GPUThor é um lembrete de que essa suposição de isolamento precisa de ser verificada, não presumida. Antes de tratar uma instância de GPU em nuvem como um ambiente de confiança e isolado, as equipas de segurança e infraestrutura devem confirmar junto do fornecedor se o SYS-ECC e o isolamento IOMMU/DMA recomendados pela Nvidia estão de facto ativados, pedir visibilidade sobre a telemetria de erros da GPU e incluir o isolamento multi-inquilino nas auditorias de segurança a fornecedores exigidas pelo RGPD sempre que dados pessoais são processados nesse hardware — não como mais uma linha numa ficha técnica, mas como uma pergunta real sobre como uma placa partilhada é protegida.