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

Riepilogo Tecnico: Gestione Dinamica della Soglia Rowhammer

Problematica
La vulnerabilità Rowhammer, caratterizzata dalla Soglia Rowhammer ($T_{RHD}$)—il numero minimo di attivazioni di riga necessarie per indurre un bit flip—si è intensificata con ogni generazione di DRAM, scendendo da circa 139K nel 2014 a meno di 4.8K nelle moderne DDR4 e puntando a meno di 1K per le DDR5. Le attuali difese in-DRAM (Target Row Refresh [TRR], Per-Row Activation Counting [PRAC] e SALT-C) mitigano questo problema tracciando le attivazioni e aggiornando le righe vittime quando viene superata una soglia fissa.

Tuttavia, queste difese sono parametrizzate al momento della produzione utilizzando un valore $T_{RHD}$ statico. Ciò crea una vulnerabilità critica di "obsolescenza della soglia" (threshold staleness) poiché il vero $T_{RHD}$ varia significativamente con le condizioni operative a runtime, in particolare la temperatura. I dati aggregati da SpyHammer [6] indicano una dipendenza quasi lineare del Bit Error Rate (BER) dalla temperatura (50–95°C), risultando in un intervallo fino a 3,3× nel BER all'interno del modulo. Inoltre, VRD [7] dimostra che le soglie fluttuano stocasticamente nel tempo. Di conseguenza, una difesa calibrata per un ambiente nominale a 65°C può silenziosamente sotto-mitigare quando il sistema opera a temperature più elevate (ad esempio, 85°C), creando una finestra sfruttabile in cui la soglia configurata è troppo permissiva rispetto alle effettive condizioni fisiche.

Metodologia
Gli autori propongono la Gestione Dinamica della Soglia Rowhammer, uno strato runtime agnostico rispetto alla difesa che integra le difese basate su contatori esistenti. Invece di un nuovo meccanismo di difesa, questo strato ricalcola dinamicamente il parametro di soglia per ogni difesa una volta per epoca (default 10 ms) in base alla temperatura osservata.

La metodologia consiste in tre componenti:

1. Modello $T_{RHD}$ Dinamico: La soglia effettiva ($T_{RHDeff}$) è calcolata come:
   $$T_{RHDeff}(t) = T_{RHDinit} \cdot f_{temp}(T) \cdot g$$
   • Fattore di Temperatura ($f_{temp}$): Derivato da una regressione lineare dei dati di SpyHammer [6], che modella la degradazione di $T_{RHD}$ all'aumentare della temperatura. Il modello gestisce le variazioni specifiche dei vendor (ad esempio, il segno invertito di Samsung) tramite una tabella di lookup basata sull'ID del Produttore (MID).
   • Guardband ($g$): Un fattore di derating moltiplicativo (impostato empiricamente a 0.9) per tenere conto delle variazioni temporali stocastiche (VRD [7]) e della dispersione per riga non catturata dal modello di media della popolazione della temperatura.
2. Procedura di Aggiornamento per Epoca: Il controller campiona la temperatura dai sensori lato SPD (DDR4) o dai sensori SPD-Hub (DDR5), calcola $T_{RHDeff}$ e proietta questo valore sulla specifica variabile di soglia della difesa attiva.
3. Proiezione della Soglia: Lo strato mappa la $T_{RHDeff}$ calcolata sulla specifica contratto di sicurezza di ciascuna difesa:
   • SALT-C: Ricalcola il parametro di Attivazione per Minuto (APM) per garantire che le attivazioni massime ($MaxACT$) rimangano al di sotto della soglia fisica degradata.
   • PRAC: Regola la soglia di allerta per riga ($ATH_{PRAC}$) sottraendo il budget di grazia ABO da $T_{RHDeff}$.
   • TRR: Regola la soglia del tracker a profondità fissa a $T_{RHDeff}/2$.

Fondamentalmente, lo strato stringe sempre la soglia (non la rilassa mai), preservando gli argomenti di correttezza delle difese sottostanti.

Contributi Chiave

1. Uno Strato Runtime Agnostico rispetto alla Difesa: Un meccanismo che scollega il parametro di soglia dalla costante statica di fabbricazione, permettendogli di adattarsi alle condizioni termiche a runtime senza modificare la logica di difesa principale.
2. Framework di Valutazione Unificato: Una valutazione attraverso tre distinte architetture di difesa (SALT-C, PRAC, TRR) utilizzando un "oracolo disaccoppiato". Questo oracolo scala la $T_{RHD}$ fisica per ogni DIMM tramite un fattore stocastico $\delta \sim N(1, \sigma)$ per rompere l'auto-coerenza del modello, garantendo che la valutazione testi la capacità della difesa di gestire la varianza del mondo reale piuttosto che solo le assunzioni interne del modello.
3. Analisi di Fattibilità Hardware: Il documento delinea due percorsi di implementazione: un'implementazione lato host che richiede aggiornamenti agli standard JEDEC (esponendo i registri di soglia per banca) e un'implementazione on-die utilizzando i sensori termici interni esistenti e le tabelle ROM, evitando nuovi registri scrivibili dall'host.

Risultati
La valutazione è stata condotta utilizzando DRAMSim3 con una traccia Rowhammer double-sided (600K attivazioni) su 7 milioni di cicli.

• PRAC: La configurazione nominale-statica (calibrata a 65°C) ha subito 72 violazioni a 85°C. Lo strato Dinamico ha ridotto questo valore a 0 violazioni a $\sigma=0$. Anche con varianza stocastica ($\sigma=0.10$), lo strato Dinamico con una guardband ($g=0.9$) ha ridotto le violazioni da 38.4 (con $g=1.0$) a 9.6.
• SALT-C: La configurazione nominale-statica ha avuto 10 violazioni a 85°C. Lo strato Dinamico ha ridotto questo valore a 2 violazioni (attribuite a transitori della prima epoca), che sono state eliminate portandole a 0 utilizzando una politica di bootstrap che imposta la soglia basandosi sulla temperatura iniziale. L'operazione dinamica ha comportato un costo di latenza del 5.1% a 85°C rispetto alla configurazione nominale-statica, ma è stata del 3.6% più economica rispetto a una configurazione statica worst-case (calibrata per 85°C) a 65°C.
• TRR: Lo strato ha agito principalmente come strumento diagnostico per TRR. Con una piccola profondità del tracker ($K=4$), TRR ha sofferto di limiti di capacità (evizioni) piuttosto che di obsolescenza della soglia, risultando in un alto numero di violazioni indipendentemente dalla calibrazione. Lo strato è diventato efficace solo quando la profondità del tracker è stata aumentata ($K \ge 16$).
• Overhead: Il costo computazionale è trascurabile (< 1 ns per il calcolo). Il costo dominante è la larghezza di banda della memoria necessaria per scrivere le nuove soglie nei registri per banca, stimata in circa 260 ns per epoca di 10 ms (0.003% della larghezza di banda DRAM).

Significatività e Rivendicazioni
Il documento sostiene che la Gestione Dinamica della Soglia Rowhammer colma il divario di "obsolescenza termica" che rende le difese statiche vulnerabili in ambienti operativi caldi. Dimostra che un sottile strato runtime può correggere retroattivamente la parametrizzazione delle difese esistenti senza richiedere una riprogettazione fondamentale dell'architettura DRAM o degli algoritmi di difesa stessi.

Gli autori dichiarano esplicitamente le limitazioni:

• I risultati sono basati su simulazioni; la caratterizzazione su silicio di $HC_{first}$ (conteggio attivazioni per il primo bit flip) rispetto alla temperatura è necessaria per il deployment.
• Il modello di temperatura lineare è derivato da dati DDR4 e potrebbe non generalizzarsi a DDR5 senza un nuovo fitting a causa dei cambiamenti di processo.
• L'approccio assume che la temperatura osservata rifletta la temperatura effettiva della cella, lasciandolo vulnerabile ad attacchi di spoofing dei sensori o manipolazione termica, sebbene un'implementazione con sensore on-die mitighi questo rischio.
• Lo strato non affronta difese non basate su contatori (ad esempio, row-swap) o pattern di attacco specifici come Blacksmith o ZenHammer, sebbene sia previsto che sia ortogonale ad essi.

In definitiva, il lavoro si posiziona non come una nuova difesa, ma come un necessario strato di gestione a runtime che assicura che i parametri delle difese basate su contatori rimangano validi sotto condizioni termiche dinamiche.