WarpGuard: Protected-Site Control-Flow Integrity for CUDA SASS Binaries

Resumo Técnico: WARPGUARD

Problema
Pesquisas recentes de exploração demonstram que bugs de memória de GPU (ex: estouros de buffer) podem escalar para corrupção de controle de fluxo no lado do dispositivo. Atacantes podem corromper continuações de retorno, ponteiros de função, entradas de tabelas de despacho ou alvos de desvio, que são subsequentemente consumidos por instruções da GPU para redirecionar a execução. Embora a Integridade de Controle de Fluxo (CFI) seja o padrão de defesa para CPUs, aplicar CFI a binários CUDA implantados é desafiador. Kernels de produção são frequentemente distribuídos como fatbinaries ou cubins, onde a fronteira de segurança relevante é o código SASS (Streaming ASSembly) executado, não o código fonte ou a representação intermediária PTX (Parallel Thread Execution).

O nível SASS introduz complexidades ausentes na CFI de CPU:

• Transformações de Redução (Lowering): Chamadas de nível de fonte podem ser inlineadas, estados de retorno podem ser mantidos em registradores em vez de sofrerem spill para a memória, e alvos indiretos podem ser otimizados.
• Execução SIMT: Uma única instrução estática pode executar de forma diferente entre as lanes de um warp (warp-uniform vs. lane-local), exigindo verificações granulares.
• Lacunas de Evidência: Nem todos os sites de controle de fluxo em um binário possuem evidência suficiente para derivar uma política sólida. Tratar sites não suportados como "permitidos" cria brechas de segurança, enquanto tratá-los como "protegidos" sem evidência é tecnicamente incorreto.

Ferramentas de segurança de GPU existentes focam em segurança de memória ou injeção de código, mas não impõem CFI na fronteira SASS executada com contabilidade explícita para sites que não podem ser protegidos.

Metodologia: WARPGUARD
O WARPGUARD é o primeiro sistema de CFI projetado especificamente para binários de dispositivo CUDA operando sobre o SASS executado. Ele impõe uma política de "site protegido", o que significa que ele apenas verifica transferências de controle de fluxo onde existe evidência binária suficiente para derivar uma política sólida.

1. Recuperação e Classificação de Sites:
   O WARPGUARD analisa binários SASS para identificar sites de consumo de controle de fluxo (retornos, chamadas indiretas, desvios indiretos). Ele classifica cada site em um de seis resultados:

   • Protegido: Existe evidência suficiente; uma verificação é inserida.
   • Borda Fixa (Fixed-edge): O alvo é estático (ex: chamada direta); nenhuma verificação dinâmica é necessária.
   • Não Suportado: A evidência é ausente ou ambígua; o site é excluído da proteção.
   • Sem Superfície (No-surface): Não existe transferência dinâmica (ex: código totalmente inlineado).
   • Fallback/Excluído por Perfil: A análise falhou ou o modo está desativado.
     Crucialmente, o WARPGUARD não permite silenciosamente sites não suportados; eles são explicitamente contabilizados fora do denominador protegido.

2. CFI de Borda Posterior (Retornos):
   Para retornos protegidos, o WARPGUARD autentica o estado de continuação antes que a instrução RET libere o controle.

   • Mecanismo: Em uma chamada protegida, o sistema registra uma continuação de retorno esperada, ID de callsite, profundidade e um token com chave (MAC) em um estado privado de backend confiável.
   • Verificação: No site de retorno, o sistema lê a continuação observada, verifica o token contra o estado confiável e o compara com o valor esperado.
   • Segurança: Metadados de sombra graváveis não são autoritativos; apenas o token com chave do host/runtime confiável autoriza a transferência. Se a verificação falhar, o sistema falha fechado (trava) antes que a transferência inválida ocorra.

3. CFI de Borda Anterior (Chamadas/Desvios Indiretos):
   Para transferências indiretas protegidas, o WARPGUARD valida o alvo dinâmico contra um conjunto de alvos recuperado por site.

   • Recuperação: Conjuntos de alvos são derivados de metadados binários, realocações de constantes e análise de tabelas de despacho ou funções que tomam endereço.
   • Verificação: Antes que uma transferência indireta seja liberada, o alvo observado é verificado contra o conjunto permitido para aquele site específico.
   • Granularidade: As verificações são conservadoras e locais à lane por padrão para lidar com divergência SIMT, garantindo que uma lane corrompida não possa se esconder dentro de um agregado uniforme de warp.

4. Backends de Implementação:
   O WARPGUARD é implementado via três backends distintos para separar preocupações:

   • WG-NVBit: Um backend de referência amplo usando NVBit para instrumentação dinâmica e avaliação de ataque.
   • WG-ST: Um timing lane de trampolim estático para execução sem callbacks em superfícies específicas de sm_89, usado para comparar o overhead sem o piso de callback do NVBit.
   • WG-PC: Um backend de cache de patch que aplica patches SASS revisados e baseados em manifesto para superfícies sm_89, permitindo prevenção sem callbacks.

Principais Contribuições

• Formulação de CFI de Site Protegido: O artigo formula a CFI de binário CUDA como uma imposição de "verificação-antes-da-liberação" em sites de consumo SASS recuperados. Ele contabiliza explicitamente bordas fixas, sites não suportados e exclusões de perfil, separando-os da cobertura protegida.
• Mecanismo e Implementação: O WARPGUARD vincula a política ao SASS recuperado, autentica o estado de borda posterior usando tokens com chave, valida alvos de borda anterior por site e mantém a telemetria separada da lógica de autorização.
• Avaliação com Denominadores Separados: O sistema é avaliado em 77 artefatos CUDA, classificando 51.621 sites de controle de fluxo SASS e registrando 52,2 milhões de verificações dinâmicas. A avaliação distingue entre a superfície recuperada, a imposição protegida e as superfícies residuais não suportadas.

Resultados

• Cobertura: O WARPGUARD classificou com sucesso 51.621 sites, incluindo 1.343 retornos e 154 entradas de conjunto de alvos de borda anterior suportadas. Identificou 15 entradas de borda anterior não suportadas e 10 entradas de fallback, garantindo que estas não fossem incorretamente tratadas como protegidas.
• Bloqueio de Ataques: Em ataques representativos de corrupção de borda posterior e anterior, a execução nativa atingiu o comportamento selecionado pelo atacante, enquanto a imposição do WARPGUARD falhou fechado antes de liberar a transferência inválida. Isso se manteve para:
  • Sequestros de retorno e cadeias de gadgets.
  • Ataques de divergência SIMT (retornos de lane divergente).
  • Corrupção de alvo de borda anterior (tabelas de despacho, ponteiros de função).
  • Tampering de metadados (tokens, telemetria).
• Evidência do Mundo Real: Casos de código público (ex: PPL-CUDA-SMC, PNNL SV-Sim, callbacks de cuFFT, GooFit) confirmaram que os mesmos padrões de consumo SASS existem em sistemas CUDA reais. O WARPGUARD recuperou e protegeu esses sites com sucesso.
• Desempenho:
  • WG-NVBit: Como esperado para instrumentação dinâmica, o overhead foi alto (799–927% para cargas de trabalho >50ms), dominado pelos custos de despacho de helper e callbacks.
  • WG-ST/WG-PC: Em superfícies sm_89 correspondentes, os backends sem callback removeram o piso de tempo do NVBit. O WG-PC mostrou que a prevenção sem callback é viável para manifestos revisados, embora exija validação rigorosa de manifesto.

Significância e Alegações
O artigo afirma que o WARPGUARD é, até onde os autores sabem, o primeiro sistema de CFI avaliado para binários de dispositivo CUDA operando diretamente no SASS executado. Sua significância reside em:

1. Mudança da Fronteira: Movendo a imposição de CFI do nível de fonte/PTX para o SASS efetivamente executado, capturando os fatos reais de controle de fluxo (inlining, spills, máscaras SIMT).
2. Contabilidade Explícita: Recusando-se a tratar sites desconhecidos ou não suportados como seguros, evitando assim políticas de "permitir-qualquer-um" que comprometeriam a segurança.
3. Imposição Auditável: Fornecendo um mecanismo para separar o overhead de instrumentação dinâmica da lógica central de CFI e para distinguir entre sites protegidos e superfícies de ataque residuais.

Os autores observam modestamente que o WARPGUARD não fornece segurança de memória, integridade de código ou proteção contra comprometimento do lado do host. Ele é complementar a ferramentas de segurança de memória, focando especificamente no ponto onde o estado corrompido é consumido como fluxo de controle. O sistema depende de um host/runtime confiável para o gerenciamento de chaves; se o estado privado de backend for exposto à GPU, as garantias de segurança degradam-se.