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

Technische Samenvatting: Dynamisch Beheer van Rowhammer-drempelwaarden

Probleemstelling
De Rowhammer-kwetsbaarheid, gekenmerkt door de Rowhammer-drempelwaarde ($T_{RHD}$)—het minimale aantal rijactivaties dat vereist is om een bit-flip te induceren—is met elke DRAM-generatie geïntensiveerd, waarbij deze daalde van ~139K in 2014 naar minder dan 4.8K in moderne DDR4 en zich richt op sub-1K voor DDR5. Huidige in-DRAM-verdedigingen (Target Row Refresh [TRR], Per-Row Activation Counting [PRAC] en SALT-C) beperken dit door activaties bij te houden en slachtoffers te verversen wanneer een vaste drempelwaarde wordt overschreden.

Deze verdedigingen zijn echter bij fabricage geparametriseerd met een statische $T_{RHD}$-waarde. Dit creëert een kritieke "drempel-verouderingskwetsbaarheid" (threshold staleness) omdat de werkelijke $T_{RHD}$ aanzienlijk varieert met de operationele omstandigheden tijdens runtime, met name de temperatuur. Geaggregeerde gegevens van SpyHammer [6] geven een bijna lineaire afhankelijkheid van de Bit Error Rate (BER) van de temperatuur (50–95°C) aan, wat resulteert in een spreiding van wel 3,3× binnen de BER per module. Bovendien toont VRD [7] aan dat drempelwaarden stochastisch fluctueren over de tijd. Bijgevolg kan een verdediging die gekalibreerd is voor een nominale omgeving van 65°C, bij hogere temperaturen (bijv. 85°C) stilzwijgend ondermaatse mitigatie bieden, waardoor een exploiteerbaar venster ontstaat waarin de geconfigureerde drempelwaarde te ruim is voor de werkelijke fysieke condities.

Methodologie
De auteurs stellen Dynamic Rowhammer Threshold Management voor, een verdedigings-agnostische runtime-laag die bestaande teller-gebaseerde verdedigingen retrofitteert. In plaats van een nieuw verdedigingsmechanisme, herbevraagt deze laag de drempelparameter voor elke verdediging één keer per epoch (standaard 10 ms) op basis van de geobserveerde temperatuur.

De methodologie bestaat uit drie componenten:

1. Dynamisch $T_{RHD}$-model: De effectieve drempelwaarde ($T_{RHDeff}$) wordt berekend als:
   $$T_{RHDeff}(t) = T_{RHDinit} \cdot f_{temp}(T) \cdot g$$
   • Temperatuurfactor ($f_{temp}$): Afgeleid van een lineaire regressie van de SpyHammer [6] data, waarbij de degradatie van $T_{RHD}$ bij stijgende temperatuur wordt gemodelleerd. Het model handelt fabrikant-specifieke variaties af (bijv. de omgekeerde teken van Samsung) via een lookup-tabel gebaseerd op de Manufacturer ID (MID).
   • Guardband ($g$): Een multiplicatieve derating-factor (empirisch ingesteld op 0,9) om rekening te houden met stochastische temporele variaties (VRD [7]) en per-rij dispersie die niet door het populatiegemiddelde temperatuurmodel wordt gevangen.
2. Per-Epoch Updateprocedure: De controller samplet de temperatuur van SPD-zijde sensoren (DDR4) of SPD-Hub sensoren (DDR5), berekent $T_{RHDeff}$, en projecteert deze waarde op de specifieke drempelvariabele van de actieve verdediging.
3. Drempelprojectie: De laag brengt de berekende $T_{RHDeff}$ in kaart naar de specifieke beveiligingscontracten van elke verdediging:
   • SALT-C: Herrekent de Activations Per Minute (APM) parameter om te garanderen dat de maximale activaties ($MaxACT$) onder de gedegradeerde fysieke drempelwaarde blijven.
   • PRAC: Past de per-rij alert-drempel ($ATH_{PRAC}$) aan door het ABO grace budget af te trekken van $T_{RHDeff}$.
   • TRR: Past de vaste-diepte tracker-drempel aan naar $T_{RHDeff}/2$.

Cruciaal is dat de laag de drempelwaarde alleen maar aanscherpt (nooit versoepelt), waardoor de correctie-argumenten van de onderliggende verdedigingen behouden blijven.

Belangrijkste Bijdragen

1. Een Verdedigings-Agnostische Runtime-Laag: Een mechanisme dat de drempelparameter ontkoppelt van de statische fabricageconstante, waardoor het kan adapteren aan runtime thermische condities zonder de kernlogica van de verdediging te wijzigen.
2. Uniform Evaluatiekader: Een evaluatie over drie verschillende verdedigingsarchitecturen (SALT-C, PRAC, TRR) met behulp van een "ontkoppelde oracle". Deze oracle schaalt de fysieke $T_{RHD}$ per-DIMM door een stochastische factor $\delta \sim N(1, \sigma)$ om model-zelfconsistentie te doorbreken, waardoor de evaluatie het vermogen van de verdediging test om met real-world variantie om te gaan in plaats van alleen de interne aannames van het model.
3. Hardware Haalbaarheidsanalyse: Het artikel schetst twee implementatieroutes: een host-zijde implementatie die JEDEC-standaard updates vereist (het blootstellen van per-bank drempelregisters) en een on-die implementatie met gebruik van bestaande interne thermische sensoren en ROM-tabellen, waardoor nieuwe host-schrijfbare registers worden vermeden.

Resultaten
De evaluatie werd uitgevoerd met DRAMSim3 met een double-sided Rowhammer-trace (600K activaties) over 7M cycli.

• PRAC: De nominale-statische configuratie (gekalibreerd bij 65°C) leed onder 72 breaches bij 85°C. De Dynamische laag verminderde dit naar 0 breaches bij $\sigma=0$. Zelfs met stochastische variantie ($\sigma=0.10$), verminderde de Dynamische laag met een guardband ($g=0,9$) de breaches van 38,4 (bij $g=1,0$) naar 9,6.
• SALT-C: De nominale-statische configuratie had 10 breaches bij 85°C. De Dynamische laag verminderde dit naar 2 breaches (toe te schrijven aan eerste-epoch transiënten), die werden geëlimineerd naar 0 met behulp van een bootstrap-beleid dat de drempelwaarde initieert op basis van de initiële temperatuur. De dynamische operatie veroorzaakte een latentiekost van 5,1% bij 85°C vergeleken met nominal-statisch, maar was 3,6% goedkoper dan een worst-case statische configuratie (gekalibreerd voor 85°C) bij 65°C.
• TRR: De laag fungeerde primair als een diagnostisch hulpmiddel voor TRR. Bij een kleine tracker-diepte ($K=4$) leed TRR aan capaciteitslimieten (evicties) in plaats van drempel-veroudering, wat resulteerde in hoge breach-aantallen ongeacht de kalibratie. De laag werd pas effectief wanneer de tracker-diepte werd vergroot ($K \ge 16$).
• Overhead: De computationele kosten zijn verwaarloosbaar (< 1 ns voor berekening). De dominante kosten zijn de geheugenbandbreedte die nodig is om nieuwe drempelwaarden naar per-bank registers te schrijven, geschat op ~260 ns per 10 ms epoch (0,003% van de DRAM-bandbreedte).

Betekenis en Claims
Het artikel claimt dat Dynamic Rowhammer Threshold Management de "thermische-verouderingskloof" (thermal-staleness gap) dicht die statische verdedigingen kwetsbaar maakt in hete operationele omgevingen. Het demonstreert dat een dunne runtime-laag bestaande verdedigingen retrospectief kan herparameteriseren zonder een fundamentele herontwerp van de DRAM-architectuur of de verdedigingsalgoritmen zelf te vereisen.

De auteurs benoemen expliciet de beperkingen:

• De resultaten zijn simulatie-gebaseerd; on-silicon karakterisering van $HC_{first}$ (activatie-aantal voor de eerste bit-flip) versus temperatuur is vereist voor implementatie.
• Het lineaire temperatuurmodel is afgeleid van DDR4-data en mogelijk niet generaliseerbaar naar DDR5 zonder her-fitting vanwege proceswijzigingen.
• De aanpak gaat ervan uit dat de geobserveerde temperatuur de werkelijke cel-temperatuur reflecteert, wat het kwetsbaar laat voor sensor-spoofing of thermische manipulatie-aanvallen, hoewel een on-die sensor implementatie dit mitigeert.
• De laag pakt geen niet-teller-gebaseerde verdedigingen aan (bijv. row-swap) of specifieke aanvalspatronen zoals Blacksmith of ZenHammer, hoewel het naar verwachting orthogonaal is aan deze.

Uiteindelijk positioneert dit werk zich niet als een nieuwe verdediging, maar als een noodzakelijke runtime management-laag die ervoor zorgt dat de parameters van teller-gebaseerde verdedigingen geldig blijven onder dynamische thermische condities.