Dynamic Rowhammer Threshold Management:Temperature-Aware Threshold Degradation for In-DRAM Defenses

Resumo Técnico: Gerenciamento Dinâmico de Limiar de Rowhammer

Declaração do Problema
A vulnerabilidade Rowhammer, caracterizada pelo Limiar de Rowhammer ($T_{RHD}$)—o número mínimo de ativações de linha necessárias para induzir uma inversão de bit—intensificou-se a cada geração de DRAM, caindo de ~139K em 2014 para menos de 4.8K em DDR4 moderna e visando sub-1K para DDR5. As defesas atuais in-DRAM (Target Row Refresh [TRR], Per-Row Activation Counting [PRAC] e SALT-C) mitigam isso rastreando ativações e atualizando vítimas quando um limiar fixo é excedido.

No entanto, essas defesas são parametrizadas no momento da fabricação usando um valor estático de $T_{RHD}$, o que cria uma vulnerabilidade crítica de "obsolescência de limiar" porque o verdadeiro $T_{RHD}$ varia significamente com as condições operacionais em tempo de execução, particularmente a temperatura. Dados agregados do SpyHammer [6] indicam uma dependência quase linear da Taxa de Erro de Bit (BER) em relação à temperatura (50–95°C), resultando em uma amplitude de até 3,3× na BER dentro do módulo. Além disso, o VRD [7] demonstra que os limiares flutuam estocasticamente ao longo do tempo. Consequentemente, uma defesa calibrada para um ambiente nominal de 65°C pode submitigar silenciosamente quando o sistema opera em temperaturas mais altas (ex: 85°C), criando uma janela explorável onde o limiar configurado é muito permissivo para as condições físicas reais.

Metodologia
Os autores propõem o Gerenciamento Dinâmico de Limiar de Rowhammer, uma camada de tempo de execução agnóstica à defesa que adapta retroativamente as defesas baseadas em contadores existentes. Em vez de um novo mecanismo de defesa, esta camada refonteia dinamicamente o parâmetro de limiar para cada defesa uma vez por época (padrão 10 ms) com base na temperatura observada.

A metodologia consiste em três componentes:

1. Modelo de $T_{RHD}$ Dinâmico: O limiar efetivo ($T_{RHDeff}$) é calculado como:
   $$T_{RHDeff}(t) = T_{RHDinit} \cdot f_{temp}(T) \cdot g$$
   • Fator de Temperatura ($f_{temp}$): Derivado de uma regressão linear dos dados do SpyHammer [6], modelando a degradação do $T_{RHD}$ conforme a temperatura aumenta. O modelo lida com variações específicas de fornecedores (ex: o sinal invertido da Samsung) via uma tabela de consulta baseada no ID do Fabricante (MID).
   • Guarda ($g$): Um fator de redução multiplicativo (empiricamente definido como 0.9) para contabilizar as variações temporais estocásticas (VRD [7]) e a dispersão por linha não capturada pelo modelo de média populacional de temperatura.
2. Procedimento de Atualização por Época: O controlador amostra a temperatura de sensores do lado do SPD (DDR4) ou sensores do SPD-Hub (DDR5), calcula o $T_{RHDeff}$ e projeta este valor na variável de limiar específica da defesa ativa.
3. Projeção de Limiar: A camada mapeia o $T_{RHDeff}$ calculado para o contrato de segurança específico de cada defesa:
   • SALT-C: Recalcula o parâmetro de Ativação por Minuto (APM) para garantir que as ativações máximas ($MaxACT$) permaneçam abaixo do limiar físico degradado.
   • PRAC: Ajusta o limiar de alerta por linha ($ATH_{PRAC}$) subtraindo o orçamento de graça do ABO de $T_{RHDeff}$.
   • TRR: Ajusta o limiar de rastreamento de profundidade fixa para $T_{RHDeff}/2$.

Crucialmente, a camada apenas torna o limiar mais rigoroso (nunca o relaxa), preservando os argumentos de correção das defesas subjacentes.

Principais Contribuições

1. Uma Camada de Tempo de Execução Agnóstica à Defesa: Um mecanismo que desacopla o parâmetro de limiar da constante estática de fabricação, permitindo que ele se adapte às condições térmicas de tempo de execução sem modificar a lógica central da defesa.
2. Estrutura de Avaliação Unificada: Uma avaliação através de três distintas arquiteturas de defesa (SALT-C, PRAC, TRR) usando um "oráculo desacoplado". Este oráculo escala o $T_{RHD}$ físico por DIMM por um fator estocástico $\delta \sim N(1, \sigma)$ para quebrar a auticonsistência do modelo, garantindo que a avaliação teste a capacidade da defesa de lidar com a variância do mundo real, em vez de apenas as suposições internas do modelo.
3. Análise de Viabilidade de Hardware: O artigo delineia dois caminhos de implantação: uma implementação no lado do host exigindo atualizações no padrão JEDEC (expondo registros de limiar por banco) e uma implementação on-die usando sensores térmicos internos e tabelas ROM existentes, evitando novos registros graváveis pelo host.

Resultados
A avaliação foi conduzida usando o DRAMSim3 com um traço de Rowhammer de dois lados (600K ativações) ao longo de 7M de ciclos.

• PRAC: A configuração nominal-estática (calibrada a 65°C) sofreu 72 violações a 85°C. A camada Dinâmica reduziu isso para 0 violações em $\sigma=0$. Mesmo com variância estocástica ($\sigma=0.10$), a camada Dinâmica com uma guarda ($g=0.9$) reduziu as violações de 38.4 (em $g=1.0$) para 9.6.
• SALT-C: A configuração nominal-estática teve 10 violações a 85°C. A camada Dinâmica reduziu isso para 2 violações (atribuídas a transientes de primeira época), que foram eliminadas para 0 usando uma política de bootstrap que sementiza o limiar com base na temperatura inicial. A operação dinâmica incorreu em um custo de latência de 5.1% a 85°C em comparação com a nominal-estática, mas foi 3.6% mais barata que uma configuração estática de pior caso (calibrada para 85°C) a 65°C.
• TRR: A camada atuou principalmente como uma ferramenta de diagnóstico para o TRR. Com uma profundidade de rastreador pequena ($K=4$), o TRR sofreu de limites de capacidade (evicções) em vez de obsolescência de limiar, resultando em altas contagens de violação independentemente da calibração. A camada só se tornou eficaz quando a profundidade do rastreador foi aumentada ($K \ge 16$).
• Overhead: O custo computacional é insignificante (<1 ns para cálculo). O custo dominante é a largura de banda de memória necessária para escrever novos limiares nos registros por banco, estimado em ~260 ns por época de 10 ms (0.003% da largura de banda do DRAM).

Significância e Alegações
O artigo alega que o Gerenciamento Dinâmico de Limiar de Rowhammer fecha a lacuna de "obsolescência térmica" que torna as defesas estáticas vulneráveis em ambientes operacionais quentes. Demonstra que uma fina camada de tempo de execução pode corrigir retroativamente a parametrização de defesas existentes sem exigir um redesenho fundamental da arquitetura de DRAM ou dos algoritmos de defesa em si.

Os autores declaram explicitamente as limitações:

• Os resultados são baseados em simulação; a caracterização on-silicon de $HC_{first}$ (contagem de ativação para o primeiro bit flip) vs. temperatura é necessária para a implantação.
• O modelo de temperatura linear é derivado de dados DDR4 e pode não se generalizar para DDR5 sem novo ajuste devido a mudanças de processo.
• A abordagem assume que a temperatura observada reflete a temperatura real da célula, deixando-a vulnerável a ataques de manipulação térmica ou spoofing de sensor, embora uma implementação de sensor on-die mitigue isso.
• A camada não aborda defesas que não sejam baseadas em contadores (ex: row-swap) ou padrões de ataque específicos como Blacksmith ou ZenHammer, embora se espere que seja ortogonal a eles.

Em última análise, o trabalho posiciona-se não como uma nova defesa, mas como uma necessária camada de gerenciamento de tempo de execução que garante que os parâmetros das defesas baseadas em contadores permaneçam válidos sob condições térmicas dinâmicas.