Probabilistic Tracker Management Policies for Low-Cost and Scalable Rowhammer Mitigation
Aamer Jaleel Stephen W. Keckler Gururaj Saileshwar

An Efficient Reconstructed Differential Evolution Variant by Some of the Current State-of-the-art Strategies for Solving Single Objective Bound Constrained Problems
    
		1st Sichen Tao Faculty of Engineering 
 University of Toyama 
 Toyama, Japan 
 taosc73@hotmail.com 
 d2278002@ems.u-toyama.ac.jp
		2nd Ruihan Zhao School of Mechanical Engineering 
 Tongji University 
 Shanghai, China 
 2110415@tongji.edu.cn
		3rd Kaiyu Wang Faculty of Engineering 
 University of Toyama 
 Toyama, Japan 
 greskofairy@gmail.com
            4th Shangce Gao Faculty of Engineering 
 University of Toyama 
 Toyama, Japan 
 gaosc@eng.u-toyama.ac.jp
	
    
======================================================================================================================================================================================================================================================================================================================================================================================================================================================================================











plain
plain
arabic






  





This paper focuses on mitigating DRAM Rowhammer attacks.  In recent years, solutions like TRR have been deployed in DDR4 DRAM to track aggressor rows and then issue a mitigative action by refreshing neighboring victim rows. Unfortunately, such in-DRAM solutions are resource-constrained (only able to provision few tens of counters to track aggressor rows) and are prone to thrashing based attacks, that have been used to fool them. Secure alternatives for in-DRAM trackers require tens of thousands of counters. 

In this work, we demonstrate secure and scalable rowhammer mitigation using resource-constrained trackers. Our key idea is to manage such trackers with probabilistic management policies (PROTEAS). PROTEAS includes component policies like request-stream sampling and random evictions which enable thrash-resistance for resource-constrained trackers. We show that PROTEAS can secure small in-DRAM trackers (with 16 counters per DRAM bank) even when Rowhammer thresholds drop to 500 while incurring less than 3% slowdown. Moreover, we show that PROTEAS significantly outperforms a recent similar probabilistic proposal from Samsung (called DSAC) while achieving 11X - 19X the resilience against Rowhammer.




§ INTRODUCTION

DRAM scaling has led to higher DRAM capacities by packing DRAM cells more closely. This has increased inter-cell interference, leading to the problem of Rowhammer <cit.>, whereby rapid activations of one DRAM row can cause charge leakage and bit-flips in neighboring rows. Such Rowhammer bit-flips are not just a reliability problem, but also a major security threat. 
Numerous studies have illustrated exploits using Rowhammer <cit.>.
Moreover, the vulnerability is worsening with each DRAM generation. 
The number of activations required to induce bit-flips, called the Rowhammer threshold (TRH), has dropped from 140K in DDR3 <cit.> to just 4.9K in LPDDR4 <cit.> over the last decade. Thus, there is a growing need for effective and scalable mitigations, as TRH is expected to drop further. 

Mitigating Rowhammer effects within the DRAM module has been an ongoing challenge.
Since the release of DDR4 in 2015, DRAM manufacturers have deployed an in-DRAM mitigation called Targeted Row Refresh (TRR). 
TRR and many subsequent solutions rely on a tracking mechanism to identify rapidly activated rows or aggressor rows and then issue a mitigative action by refreshing the neighboring victim rows <cit.>.
The tracker typically consists of a group of counters within each DRAM bank that counts row activations and issues mitigations in the background of regular refresh commands when they are issued to DRAM by the memory controller.

Unfortunately, given the limited storage capabilities within the logic space of a DRAM module, TRR implementations often store less than 32 counters per DRAM bank <cit.>. 
Such limited capacity of in-DRAM trackers has made them significantly vulnerable to thrashing-based attacks such as TRRespass <cit.> and Blacksmith <cit.>, which ensure aggressor rows are evicted from the tracker by activating a larger number of rows than the tracker capacity, as shown in <ref>(b). Such thrashing-based attacks can continue to activate untracked rows far beyond TRH without a mitigation, thus inducing Rowhammer bit-flips and rendering resource-limited trackers such as TRR non-secure.



Emerging trackers attempt to avoid such thrashing-based attacks with deterministic tracking algorithms, which require a larger number of counters.

Graphene <cit.> maintains activation counts using the Misra-Gries algorithm <cit.>; recent proposals <cit.> store such counters within the DRAM logic area. 
However, the required counters  per bank increases as the TRH decreases; as shown in <ref>(a), Graphene and similar solutions require ∼5K counters per bank at TRH of 500 (680KB of SRAM per DRAM rank in DDR5 <cit.>); such high storage overheads make these solutions impractical for in-DRAM adoption.
Alternative solutions maintain one counter per row, requiring 8K to 16K counters per bank. These counters are stored in memory <cit.> and require additional DRAM accesses to fetch and update the counters, leading to high worst-case performance overheads of up to 70% <cit.>; storing them entirely within the DRAM array <cit.> requires complex redesigns of the DRAM MATs. Consequently, such deterministic trackers requiring thousands of counters per bank have been difficult to adopt in commodity DRAM.




While trackerless solutions such as PARA <cit.> exist which probabilistically issue mitigations to adjacent rows on activations, incurring no storage overhead, such solutions however cannot be implemented transparently within the DRAM. They are required to be implemented only within the memory controller, as mitigative refresh commands cannot be issued by the DRAM transparently after any given activation.




In recent years, many solutions to mitigate Rowhammer have been proposed which rely on a tracking mechanism to identify rapidly activated rows or aggressor rows, and then issue a mitigative action by refreshing the neighboring victim rows <cit.>

State-of-the-art solutions for tracking aggressor rows can be broadly classified into two categories:

   
   A) Probabilistic Solutions: Solutions like PARA <cit.> or PRA <cit.> issue a mitigative activation to neighbors on any given activation with a probability p. While such tracker-less solutions incur no storage overheads, they require frequent mitigative activations when TRH drops to 1000 or below. : our analysis shows that for a threshold of 500, PARA incurs an average slowdown of 17%, making such solutions not scalable. Furthermore, these solutions are memory-controller based and require knowledge of neighboring rows in-DRAM which is not available to memory controllers in current DRAM interfaces.
   
   B) Tracker-Based Solutions: Such solutions <cit.> track activation counts for aggressor rows and deterministically issue mitigations when a count crosses a given threshold. DRAM-based trackers like HYDRA <cit.> and CRA <cit.> maintain exact activation counts for rows in DRAM (8K to 16K counters per bank) while caching the counters within the memory controller. They also require extra DRAM accesses for updating counters on each activation which can lead to performance overheads/attacks. Tracking these counts entirely within the DRAM <cit.> requires redesigning the DRAM MATs at significant complexity. Alternatively, SRAM-based trackers like Graphene <cit.> and Mithril <cit.> maintain approximate counts of activations in SRAM (within the memory controller or in-DRAM). Unfortunately, their storage overheads increase as TRH reduces.  As shown in <ref>(a), Graphene requires ∼5K counters per bank at TRH of 500 (680KB SRAM per DRAM rank in DDR5 <cit.>); such storage overheads are a deterrent for practical adoption. 

Consequently, industry has gravitated towards in-DRAM solutions. how to clarify difference between in-DRAM and DRAM-based, in-dram is in the logic die
Since state-of-the-art tracking solutions incur large storage overheads or complexity, DRAM vendors have adopted simple trackers with few counters. Prior work <cit.> reverse-engineered in-DRAM trackers (used in the TRR defense in DDR4) to have tens of counters per bank (less than 32).
Unfortunately, such small trackers are easily fooled by new attack patterns like TRRespass <cit.> and Blacksmith <cit.> which either thrash the tracker to evict hammered rows <cit.>, or ensure hammered rows are not inserted into the tracker <cit.>, thus fooling such trackers and rendering them insecure, as shown in <ref>(b).






For an in-DRAM only solution, we seek a defense that  (a) incurs low storage  (b) has strong security (c) has low performance overheads (d) scales to low row hammer thresholds (<1K), and (e) is compatible with current DRAM interfaces.

Thus, we focus on low overhead mechanisms to secure

in-DRAM trackers (like TRR) 


by making them thrash-resistant.














This paper shows that in-DRAM trackers can be made thrash-resistant by enhancing the tracker management policies, which heavily influence the tracker's security properties. Conventional tracker management policies typically consist of (a) a lookup policy (which DRAM activations should consult the tracker) (b) an update policy (how to update tracker state on hits) (c) an eviction policy (which entry to evict when it is capacity-limited), (d) an insertion policy (whether to insert entries on a miss), and finally (e) a mitigation policy (which entry to issue a mitigation for). For instance, the in-DRAM tracker in TRR <cit.> has a lookup policy where the activation stream is sampled at deterministic time instances, 
and mitigation/eviction policies, though not documented, that are also likely deterministic (as attack patterns aligned to mitigation instances have shown better success in deterministically evicting entries <cit.>). 

Such deterministic policies are the root cause of vulnerability to thrashing-based attacks.


Based on this observation, we propose PRObabilistic TrackEr mAnagement policieS () to enable thrash-resistant in-DRAM trackers. 
We observe that non-determinism can be best introduced by varying the insertions and evictions, rather than the mitigation policy. 
To that end,  proposes (i) probabilistic sampling to minimize the number of insertions into the tracker and (ii) randomize replacement to ensure that a diversity of rows are retained in the tracker. 



<ref>(c) illustrates  which employs (i) probabilistic sampling to minimize the number of insertions into the tracker and (ii) random replacement to ensure that a diversity of rows are retained in the tracker. 











We systematically study two different sampling approaches to minimize thrashing. 
First, like the Bimodal Insertion Policy (BIP) <cit.> for caches, thrashing can be limited by modifying the tracker insertion policy to perform Probabilistic Miss Stream Sampling (PMSS) where only a subset of the misses are inserted into the tracker while the others are bypassed. Alternatively, thrashing can also be prevented by modifying the tracker lookup policy to perform Probabilistic Request Stream Sampling (PRSS).  In this approach, a subset of the request stream can look up the tracker while the rest are bypassed. We show that PRSS generally performs better than PMSS. Furthermore, with either approach, we show that the sampling rate must be proportional to the underlying mitigation rate (i.e., 1 per tREFI). Doing so ensures that 

the portion of requests (or misses) that escape sampling are not exploitable. We also propose that the tracker sampling decisions are based on a pseudo-random number generator (PRNG), seeded with a secret seed, so the sampling instances are unpredictable to the attacker. Doing so prevents an attacker from surgically avoiding sampling and launching attacks like Blacksmith <cit.>. 



We systematically study two different sampling approaches to minimize thrashing. 
First, thrashing can be prevented by modifying the tracker insertion policy to perform Probabilistic Miss Stream Sampling (PMSS), where only a subset of the misses are inserted into the tracker while the others are bypassed (similar to the Bimodal Insertion Policy (BIP) <cit.> for caches). 
A similar scheme was proposed recently by Samsung's probabilistic tracker, DSAC <cit.>. 
However, we show that sampling the miss stream is ineffective as the periodic insertions continue to thrash the small tracker. 

Alternatively, we can modify the tracker lookup policy to perform Probabilistic Request Stream Sampling (PRSS) where only a subset of the request stream looks up the tracker while the rest are bypassed. 
We observe that PRSS performs significantly better than PMSS (or DSAC) 
because sampling the request stream results in a working set smaller than the tracker capacity. 

This ensures that inserted rows get mitigated without the adversary being able to thrash them, 
and thus provides much stronger protection against thrashing-based attacks.


Consequently,  adopts  PRSS for its sampling-based thrash-resistance. 

  aligns closely with recent work by Samsung (i.e., DSAC <cit.>) and SK Hynix <cit.> who also employ non-determinism through PRNG based Rowhammer trackers. Samsung's DSAC uses miss-sampling (like PMSS), making it less thrash resistant; in <ref> we find that it is insecure for Blacksmith-like attacks <cit.>. 
Hynix provides insufficient details for us to provide a reasonable security comparison.


However, thrash resistance alone is not sufficient. If the sampling rate is not carefully selected, too low of a sampling rate can allow requests that escape sampling to be used for rowhammer, and too high of a sampling rate can lead to thrashing. 
Hence, we derive the optimal sampling rate where the tracker just begins to thrash, when the insertion probability equals the mitigation probability of the tracker (1 per tREFI). To prevent such thrashing from being exploitable,  proposes a random replacement policy to ensure a diversity of rows are stored in the tracker, and thus the frequency-based mitigations are to diverse rows, as shown in <ref>(c). 
The tracker sampling decisions are based on a pseudo-random number generator (PRNG) with a secret seed (which is periodically changed), so the attacker cannot align with and exploit sampling instances <cit.>.









However, thrash resistance alone is not sufficient.
If the tracker sampling probability is too low, a sufficient number of aggressor activations can escape sampling, which can then be used by an attacker to perform Rowhammer.
To prevent such attacks, 
At the same time, to prevent the resultant thrashing from being exploitable,  ensures a diversity of rows are retained in the tracker and mitigated by using a tracker eviction-policy based on random replacement.
Thus, the rows that escape mitigations due to thrashing are different each time, and thus are less likely to be used for sustained hammering and if they are frequently accessed, they may be mitigated within a few mitigations. 





Our analysis shows that a sampling probability between p=1 % to 5%, in combination with a random replacement based evictions, is sufficient to prevent Rowhammer via thrashing-based evictions or rows that escaped sampling.

It would seem that the sampling probability is proportional to the number of mitigations issued per TREFI?












We evaluate  on 500 uniform and non-uniform attack patterns based on TRRespass<cit.> and Blacksmith<cit.>. 
Across all patterns, we measure maximum disturbance, the maximum activations any row receives before a mitigation. With 1 mitigation per tREFI,  limits the maximum disturbance to 2.1K, making it a suitable defense for current (LP)DDR4 DRAM with TRH of 4.9K to 9K <cit.>. 



We also co-design  with RFM (a feature in DDR5), which allows extra mitigation opportunities to the DRAM. We observe that a baseline deterministic tracker (like TRR), benefits minimally from additional RFM mitigations, as it is easily thrashed even in the shorter period between mitigations; it thus suffers a maximum disturbance of 73K to 64K activations with 1 to 8 mitigations per tREFI. Whereas,  with RFM significantly benefits from additional mitigations: 
with 4 mitigations per tREFI,  limits the maximum disturbance to 600, which reduces to 300 with 8 mitigations per tREFI. This makes  a scalable defense even as TRH drops to 1K or 500 in the future.


Compared to recent probabilistic designs, our in-DRAM solution  achieves a maximum disturbance that is 15% lower than  PARA <cit.>, a trackerless solution in the memory controller, and 19X lower than Samsung's DSAC <cit.>, a probabilistic in-DRAM tracker at equivalent mitigation costs. 




In comparison, DSAC <cit.>, which uses a probabilistic insertion policy for its tracker, with a decreasing sampling probability has a maximum disturbance as high as 32K; this is mainly because non-uniform attack patterns can exploit its low sampling probabilities and continue to induce Rowhammer, as we explain in Section-X.






    



Overall, this paper makes the following contributions:

    
    
  * We show that effective tracker management can enable in-DRAM trackers to be secure against row hammer attacks at Rowhammer thresholds of 1K or below.
    
  * We propose  , a probabilistic tracker management policy, that uses request stream sampling and random replacement to prevent tracker thrashing.
    
  * We demonstrate how a recent probabilistic tracker, Samsung's DSAC <cit.>, is insecure and incurs a max disturbance beyond TRH, and 19X higher than .
    
  * We co-design  with RFM on DDR5 systems to show  can significantly lower the max disturbance below TRH of 1K and 500, unlike deterministic trackers (like TRR) in commodity DRAM which benefit minimally from extra RFM mitigations.
    
    


To our knowledge, this is the first work to systematically analyze the relationship between a tracker's management policies and its susceptibility to rowhammer. 
Our Gem5 evaluations with SPEC CPU2017 workloads show that the average performance impact is less   than 1% for a TRH of 1K and 3%  for TRH of 500. Our in-DRAM implementation incurs negligible storage (less than 3KB per DRAM rank) that is similar to current TRR implementations.






Paper Raw Outline
I.  Introduction

State of the art solutions in academia:

   A) Probabilistic Solutions (PARA or PRA) –> No Storage. Low Security, High Slowdown at Low Thresholds. Memory-Controller based, so requires knowledge of in-DRAM architecture.
   
   B) Tracker Based Solutions (exact counts or approximate counts)
    - Can be implemented in-DRAM or in-Memory Controller. Industry moving towards in-DRAM solutions.
    –> Problem: High Storage Overheads.

For In-DRAM solutions, conventional tracker-based solutions require large storage overheads/impactical and DRAM vendors are not adopting.  Instead, DRAM vendors have adopted a tracker based solutions with few counters (less than 32).  Prior work has reverse engineered and shown that there are few tens of counters.

Problem:  small trackers are susceptible to thrashing. Attacks like TRRespass (uniform hammering patterns), Blacksmith (non-uniform hammering patterns.

to address the tracker thrashing problem, what do state of the art solutions do?  

b)  How can we prevent tracker from thrashing?  Increasing tracker size is not a solution .  Thrash resistence without incurring additional storage, bandwidth, and performance overheads?  Key idea:  prevent the tracker from thrashing.  Existing designs for thrashing attempt to preserve some portion of the access stream so some get hits.  But this prevents those are not in the tracker from getting row hammer mitigations.

Soluution:  probabilistically sample the input request stream (PRESS)
Probabilistically sampling ensures that you insert sufficient elements into the tracker without overflowing the tracker and allowing entries to be selected for mitigation.

Is thrash resistance enough?  How do we bring non-determinism into the picture?       
        b) non-determinism brought in by random eviction (to prevent attacker from aligning to PRESS).  Cite blacksmith (that was aligning).

Brief summary of how our design works and issues mitigations at TREFI interval.  We find that our proposal brings maximum distrubance to be near 1K for both TRESSPASS and BlackSmith access patterns.

Can we do better?  And we find that we can increase the number of mitigations issued per TREFI, for DDR5 and beyond.  This brings the maximum distrubance down further (closer to 500) at the cost of additonal command bandwidth overhead to DRAM.  This incurs X 

Contributions:
– Systematically analyze the benefits of the different sources of non-determinsm in our design.
– other items from above.

II.  Background     Background
a) Row hammer Thresholds
b) Characterize Mitigation Space
  a) Memory Controller Based  (requires knowledge of DRAM internals)
  b) In-DRAM based (two categories)
    a) Accurate Counting (counter per row)
    b) Approximate Counting (few counters per bank)

These past two solutions require large storage overheads/impactical and DRAM vendors are not adopting.  Instead, DRAM vendors have adopted a tracker based solutions with few counters (less than 32).  Prior work has reverse engineered and shown that there are few tens of counters.

   a) Memory Controller Based  (requires knowledge of DRAM internals)
   b) In-DRAM based (two categories)
    a) Accurate Counting (counter per row)
    b) Approximate Counting (few counters per bank)
c) Why is there a limitation in number of counters you can store in-DRAM?
d) Motivating Table:
Table Columns:   Storage (H/L), Compatibility with DRAM Interface (Y/N), Disturbance.
Graphene-In-DRAM: H, Y, < RTH
GrapheneLC-In-DRAM: L, Y, >> RTH
PARA: N, N,  RTH
PARA-In-DRAM: N, Y, >> RTH
*PARA-In-DRAM with N-Mitigation/tREFI still performs worse than our solution.

e) Goal:  L, Y, << RTH

III:  Experimental  Methodology


IV Our Proposal:

a) Design
  i) Design space of non-determinism to prevent thrashing.
  ii) Probabilistic Sampling. 
      – Sensitivity to Sampling Rate (Bath-tub curve)
  iii) Eviction Policy (LFU (Baseline), BIP, Random)
  iv) Mitigation policy (Frequency based (Baseline), Random). Random works better in thrashing, Frequency better in non-uniform outliers (target rows smaller than tracker). Frequency wins!
  v) N Mitigations per tREFI to decrease Max Disturbance even further.

b) Storage     Power Overhead
c) Security Analysis

V:  Results
1. Maximum disturbance (1 Mitigation per tREFI) of PRESS + Rand-Repl vs  Graphene-LC, DSAC, ??BIP?? 
    – Subsection on DSAC - why does it fail?
2. Maximum disturbance (1-N Mitigations per tREFI) of PRESS + Rand-Repl vs  Graphene-LC, DSAC, ??BIP?? 
3. Number of mitigations for achieving same disturbance for  PRESS + Rand-Repl vs  Graphene-LC, DSAC, ??BIP??
3. Comparison of PARA vs PRESS + Rand-Replacement (Same-Mitigation     Same-Disturbance)
4. Performance evaluations of mitigations/tREFI to achieve K-Threshold (PRESS + Rand-Repl     DSAC, Graphene-LC, PARA)
5. Sensitivity of Performance evaluation to Blast-Radius (mitigation cost increases).

VI:  Related

VII:  Conclusion


### Outline
### Evaluation Plans
0. Describe evaluation methodology : define "Max-Disturbance", define the attack patterns (TRRespass, Blacksmith).
1. Maximum disturbance (1 Mitigation per tREFI) of PRESS + Rand-Repl vs  Graphene-LC, DSAC, ??BIP?? 
    – Subsection on DSAC - why does it fail?
2. Maximum disturbance (1-N Mitigations per tREFI) of PRESS + Rand-Repl vs  Graphene-LC, DSAC, ??BIP?? 
3. Number of mitigations for achieving same disturbance for  PRESS + Rand-Repl vs  Graphene-LC, DSAC, ??BIP??
3. Comparison of PARA vs PRESS + Rand-Replacement (Same-Mitigation     Same-Disturbance)
4. Performance evaluations of mitigations/tREFI to achieve K-Threshold (PRESS + Rand-Repl     DSAC, Graphene-LC, PARA)
5. Sensitivity of Performance evaluation to Blast-Radius (mitigation cost increases).
6. Storage     power overheads - no evaluations. Highlight our tracker does not add much storage (in addition to counters) or power. The only added circuits are for a PRNG for sampling     replacement (check for citations on power/storage costs). 






§ BACKGROUND AND MOTIVATION





 §.§ DRAM Architecture and Parameters.



To access data from DRAM, the memory controller first issues an activate (ACT) for a DRAM row to read it into a row-buffer, the 64B data is then transferred to the bus, and then the row may be closed and pre-charged (PRE). 
For reliable operation, the memory controller ensures a minimum time gap of  between two successive ACTs to a bank. The charge of a DRAM row must also be refreshed periodically every tREFW time period.
For this, the memory controller issues a REF command every tREFI period to refresh a subset of rows. There are 8192 REFs issued every tREFW period to cover all DRAM rows. <ref> provides these timing parameters.

DRAM is organized in the form of “rows” of cells. For a 64B data transfer, the memory controller issues an activate (ACT) for a DRAM row, the row contents are transferred to the row-buffer of the DRAM bank, and then the 64B data is transferred to the bus, following which the row may be closed and pre-charged (PRE). To ensure sufficient time for the ACT and PRE commands, the memory controller is required to ensure a minimum time gap of   between two successive ACTs to a bank. Also, to prevent retention failures, the charge of a DRAM row must be refreshed periodically every tREFW time period. For this, the memory controller issues a REF command every tREFI period to refresh a subset of rows. There are 8192 REFs issued every tREFW period to cover all DRAM rows. <ref> provides these timing parameters.


DRAM is organized in the form of “rows” of cells. For a 64B data transfer, the memory controller issues an activate (ACT) for a DRAM row, the row contents are transferred to the row-buffer of the DRAM bank, and then the 64B data is transferred to the bus, following which the row may be closed and pre-charged (PRE). 
For reliable operation, the memory controller is required to ensure a time gap of  between two successive ACTs to a bank and the charge of a DRAM row must also be refreshed periodically every tREFW time period. 
For this, the memory controller issues a REF command every tREFI period to refresh a subset of rows. There are 8192 REFs issued every tREFW period to cover all DRAM rows. <ref> provides these timing parameters.







 §.§ DRAM Rowhammer Attacks

Kim et al. <cit.> discovered that rapid activations of a DRAM row (called Rowhammer) can cause charge leakage and bit flips in neighboring rows. 
The heavily activated row is called an “aggressor” row and the neighboring row with a bit-flip is called the “victim” row. These bit flips can occur up to distance of 2 rows from the aggressor rows (also known as the “blast-radius”) <cit.>.
The minimum number of activations to an aggressor row to cause a bit-flip in a victim row is called the “Rowhammer threshold” (TRH).
With DRAM scaling, TRH has dropped significantly from 139K for DDR3 in 2014 <cit.> to 10K for DDR4 <cit.> and just 4.8K–9K for LPDDR4 in 2020 <cit.>.
(see <ref>).

Rowhammer is not only a reliability issue but has also become a critical security threat. Numerous exploits have shown that Rowhammer bit-flips in page-tables or sensitive binaries can be used by attackers to escalate to kernel-level privileges <cit.>, or the data-dependent nature of the bit-flips can  be used to leak confidential data <cit.>. Thus, it is imperative to reduce the risk of Rowhammer attacks.












 §.§ Threat Model

Our threat model assumes an attacker with native execution capability, that can issue memory requests for arbitrary addresses. 
We assume the attacker knows the defense algorithm, but does not have physical access to the memory controller or DRAM to learn any secret information stored inside DRAM (e.g., seed used for random-number generator).
Our defense aims to prevent all known forms of Rowhammer attacks, including TRRespass <cit.> and Blacksmith <cit.>, that attempt to fool the tracker or Half-Double <cit.> which fools mitigative refresh. 
The recent RowPress <cit.> attack is out-of-scope, since its effects are orthogonal to Rowhammer and can be mitigated with a paging policy that limits the time a row is kept open.




 §.§ Targeted Row Refresh (TRR) Mitigation in DDR4

DDR4 modules support in-DRAM mitigation against Rowhammer called Targeted Row Refresh (TRR) <cit.>. 
TRR maintains an aggressor row tracker within each DRAM bank. Each tracker entry holds the DRAM row number and a frequency counter.
When the memory controller issues a REF command every tREFI period, the DRAM issues a mitigation for the highest activated row in the tracker.
The mitigation involves refreshing the neighboring victim rows (in a given blast radius) during tRFC in the background of a REF command.


Recent Attacks. Recent studies <cit.> have shown that trackers typically contain less than 32 entries per bank due to DRAM storage constraints. The TRRespass <cit.> attack exploited this limited storage by uniformly hammering a large number of rows beyond the tracker capacity, to thrash the tracker, and evict resident entries. As a result, the hammered rows that are evicted escape a mitigation, and bit-flips can be induced by fooling the tracker.
Recent work <cit.> also observed that some tracker implementations may perform deterministic temporal sampling   of activations for insertion into the tracker. The Blacksmith attack <cit.> exploited this to flip bits by aligning its hammering pattern to escape sampling and increasing the intensity of hammering for these rows. 


can we snip this para?In addition to these attacks that exploited the tracker, a recent Half-Double attack exploited mitigations. This attack exploited the fact that frequent mitigative refreshes to the neighbors can themselves be used for hammering, and in turn induce bit-flips in distance-2 neighbors. To mitigate this, the mitigative refreshes can be extended to cover 2 rows above and 2 rows below the aggressor (cover a blast-radius of 2).


Refresh Management (RFM). DDR5  includes a new feature, RFM, where memory controller can issue additional mitigations (RFM commands) to the DRAM when the activations per bank crosses a threshold. 
However, the actual row to be mitigated still depends on the in-DRAM tracker implementation. Consequently, if a vulnerable tracker like TRR <cit.> can be fooled (by thrashing or escaping sampling) between mitigations, it can allow existing attacks to continue despite additional RFM mitigations, as we shown in  <ref>.

[boxrule=1pt,left=5pt,right=5pt,top=3pt,bottom=3pt]
Resource-constrained trackers (like TRR with <32 entries) are susceptible to attacks exploiting thrashing-based evictions or deterministic sampling to escape insertions.





 §.§ Storage Overheads of State-of-the-Art Trackers

State-of-the-art trackers typically store a large number of entries to deterministically prevent thrashing-based attacks. 
Such trackers may be stored in SRAM, DRAM or in both SRAM and DRAM.
At one end of the spectrum, Graphene <cit.> and Mithril <cit.> perform approximate counting and require fewer counters, while at the other end of the spectrum, solutions utilize one counter per row <cit.> to perform exact tracking.
Other trackers <cit.> lie between these.

Graphene: Graphene <cit.> uses activation counters based on Misra-Gries summaries, a solution to the frequent element problem, to identify aggressor rows from a stream of row activations in the memory controller. When any counter in the tracker crosses a predefined threshold (TRH/2), the associated row is mitigated. The counts in this tracker are always guaranteed to be greater than or equal to the actual row activation counts, so long as the number of tracker entries is greater than  ACTs-per-tREFW / (TRH/2). 
For TRH of 500, this requires 5440 counters per DRAM bank (87K counters per rank) consuming 240 KB SRAM per DRAM rank; additionally,

this must be organized as a 5400-entry CAM per bank, which may be beyond practical capabilities <cit.>. 

Mithril: Mithril <cit.> stores a similar Misra-Gries tracker within DRAM, and co-designs it with RFM to allow a smaller tracker size when the mitigations are issued at a higher frequency (with lower RFM_TH).
Unfortunately, Mithril also faces a similar problem that at low thresholds of 500, to keep performance overheads low, it requires a tracker of few thousand counters per DRAM bank, which is impractical given that deployed in-DRAM defenses only have tens of counters.  

Hydra: Hydra <cit.> and CRA <cit.> store one counter per DRAM row, in a reserved portion of the DRAM. 
A 4GB DRAM Rank (with 8KB rows) requires 512K counters per rank. 
Unfortunately, Hydra faces performance overheads due to additional DRAM accesses to fetch and update the counters. 
Although these solutions deploy complex caching and filtering mechanisms on-chip within the memory controller  to avoid extra DRAM accesses, recent work <cit.> shows that the average slowdown for CRA is 25%, and for pathological workloads where Hydra's filtering may be ineffective, the worst-case slowdown can be as high as 70%.  

Panopticon: Panopticon <cit.> and PRHT from Hynix <cit.> propose per-row counters stored within the DRAM array. This requires 512K counters per DRAM rank, as before, which may be updated without additional DRAM accesses.
However, such solutions require a significant redesign of the DRAM MATs, and additional logic to store and update these counters in the background of a DRAM ACT, which can additionally impact DRAM timings.
The required complex redesign of the DRAM arrays makes such solutions less desirable.



[boxrule=1pt,left=5pt,right=5pt,top=3pt,bottom=3pt]
State-of-the-art trackers require large storage overhead (87K – 512K counters per DRAM rank) or require significant SRAM / DRAM changes making them undesirable.





 §.§ Challenge with Existing Probabilistic Mitigations

PARA <cit.> or PRA <cit.> are trackerless probabilistic solutions that issue a neighboring row activation from the memory controller with a probability p on each DRAM activation.
Such solutions are trackerless, so they incurs no storage overheads. 
Unfortunately, this cannot be implemented transparently within the DRAM as  only the memory controller can issue additional activation commands at arbitrary time instances to specific rows; thus, such solutions must be implemented within the memory controller.
This also means that the memory controller requires the knowledge of adjacent rows, which is not currently exposed by DRAM to the memory controller.
Prior works <cit.> have attempted to minimize mitigations in PARA, but at the cost of lowering the security.


















[boxrule=1pt,left=5pt,right=5pt,top=3pt,bottom=3pt]
PARA (and PRA) as a probabilistic, trackerless solution, incurs negligible storage but is not scalable to sub-1K Rowhammer thresholds due to high slowdown.



Recent proposals like PRoHIT <cit.> and Samsung's DSAC <cit.> employ stochastic replacement in resource constrained in-DRAM trackers, to filter out decoy rows in TRRespass attacks. DSAC achieves this by modifying the tracker insertion policy to progressively reduce the probability of eviction from the tracker on misses as the minimum count in the tracker increases. PRoHIT uses two tracker tables (hot table and cold table) and probabilistically promotes entries from the cold to hot table to limit thrashing.  
While such designs provide security against TRRespass attack, they are vulnerable to newer attacks: e.g., DSAC's consistent reduction in insertion probability allows rows that escape sampling 
to still be hammered (like in the Blacksmith attack <cit.>). 

In <ref>, we show that both PRoHIT and DSAC are insecure against Blacksmith-like attack patterns, which were not evaluated in the original submissions. 





 §.§ Goal: Low Cost, Scalable, and Secure Trackers

Ideally, we desire a secure Rowhammer mitigation solution that incurs low performance and storage overheads and is compatible with existing DRAM protocols to be easily adoptable by current and future DRAM. Furthermore, we desire a scalable solution as Rowhammer thresholds drop to 500 (by 10x compared to 2020 levels). To that end, we study storage-limited trackers (like TRR) and redesign them to be secure by systematically enabling them to be thrash-resistant. 



## – Rowhammer thresholds are dropping. Security and reliability problem.
## – Existing solutions - Memory Controller based (PARA, HYDRA, AQUA, Mythril,etc.) or In-DRAM tracker based (Graphene, etc.)





§ METHODOLOGY







To analyze the thrash-resistance properties of trackers, we use an empirical methodology based on access patterns derived from recent row hammer attacks, like TRRespass <cit.>, Blacksmith <cit.>, and SMASH <cit.>. We develop a trace-driven Rowhammer simulator which models our trackers and uses DRAM activation traces of attacks as input. 

Attack Patterns: We use uniform <cit.> and non-uniform <cit.> attack  patterns (see <ref>).  A uniform attack pattern resembles a TRRespass attack <cit.>, consisting of a cyclical reference to a set of target rows r with length j (larger than the tracker capacity). A non-uniform pattern is like Blacksmith <cit.>, where activations occur to a set of target rows r with length j with a higher intensity (X), compared to a second set of rows d with length k, with an intensity of 1. 
The difference in intensity (X) and sequence lengths (j, k) achieves the effect of varying intensity, phase, and frequency like in Blacksmith <cit.>. 

We evaluate 10 uniform activation patterns for different values of j (see Table <ref>).  For non-uniform activation patterns, we evaluate ten different values for j, four different values for X, and six different values for k for a total of 240 non-uniform patterns. Recent attacks <cit.> show that aligning activation patterns to tREFI can further increase the success of row hammer attacks. Thus, we evaluate aligned and unaligned versions of our 250 attack patterns for a total of 500 patterns. 
These patterns cover footprints of 2-220 unique addresses. 




Simulator: We use a trace-based simulator modeling an aggressor-row tracker assuming DRAM parameters listed in <ref>. We assume a baseline 16-entry fully-associative tracker. We run our 500 attack patterns through the simulated tracker. 

For our baseline tracker, 
on hits, the frequency counter of the associated entry is incremented. On every miss, a new entry is inserted into the tracker with the frequency counter set to zero. In the event the tracker is full, the Least Frequently Used (LFU) entry in the tracker is evicted. 
At tREFI intervals, the Most Frequently Used (MFU) entry is selected for mitigation after which the entry is invalidated. The attack patterns are continually repeated for a value N that covers one refresh interval. Like prior work <cit.>, we report “maximum disturbance” which is the maximum activations received by any row in the attack pattern before being refreshed.



§ PROBABILISTIC TRACKER MANAGEMENT

We first formalize the management policies of a typical aggressor-row tracker. We then systematically study probabilistic tracker management policies for thrash protection.

 




 §.§ Formalizing Tracker Management Policies

Structure. <ref> shows a representative aggressor-row tracker typical in DRAM defenses like TRR.

We study small trackers (e.g. 16 entry) which can be fully-associative in-DRAM tables.  Each entry stores the DRAM row address and a frequency counter, which counts the hits received by the entry while resident in the tracker. 

Since the entries with the highest counts are selected for mitigation, a fool-proof tracker management policy that retains frequently activated rows is critical for effective mitigation.





Policies. As shown in <ref>, tracker management is composed of many different policies: 1 Lookup Policy, 2 Update Policy, 3 Eviction Policy, 4 Insertion Policy, and 5 Mitigation Policy.
In state-of-the-art trackers (like TRR <cit.> or Graphene <cit.>), the Lookup Policy typically consults the tracker on all (or a deterministic subset of) DRAM activations <cit.>.  On a hit, the Update Policy increments the associated counter. 

On a miss, the Insertion Policy typically inserts all missing entries into the tracker <cit.> with a frequency count of zero. 
If the tracker is full[The insertion policy prioritizes inserting into invalid entries first.], the Eviction Policy typically employs a Least Frequently-Used (LFU) policy where the entry with the lowest count is evicted.

Finally, when issuing a mitigation, the Mitigation Policy selects the entry with highest count for mitigation <cit.>, after which the entry is invalidated to enable other frequently accessed rows to receive mitigations. Without loss of generality, 

we assume mitigations are issued at tREFI intervals and refresh neighboring rows within a blast-radius of 2 (to protect against Half-Double <cit.>). 



 §.§ Probabilistic Tracker Management Policies ()



Unfortunately, deterministic policies in state-of-the-art trackers are susceptible to thrashing attack patterns. Such attack patterns are designed with a working set larger than the tracker capacity to 

cause thrashing, or are cleverly designed to avoid insertions into the tracker exploiting the deterministic policies. 

To address this, we enable thrash resistance with PRObabilistic TrackEr mAnagement policieS ()[Named after the Greek God Proteus who could change his form at will. PROTEAS probabilistically changes insertion patterns seen by the tracker.]. 





PROTEAS consists of two key components to introduce non-determinism and diversity in rows resident within the tracker: probabilistic sampling of insertions to avoid thrashing and a random-replacement based Eviction Policy. Unlike conventional tracker policies, both of these mechanisms enable diversity in mitigations. We systematically explain the design of these two components and their benefits.
We retain the baseline Update and Mitigation Policy in <ref> (i.e, frequency counter update on  hits and MFU-based mitigations) since we still desire that the most heavily activated rows are tracked and mitigated accurately.   





 §.§ Probabilistic Sampling to Limit Tracker Thrashing

Our goal is to prevent thrashing based attacks from being able to fool the tracker by deterministically evicting tracked entries. 
Probabilistic sampling of insertions aims to reduce the number of insertions to limit thrashing capability of the attack. At the same time, the probabilistic sampling decisions are based on a pseudo-random-number generator (PRNG), whose seed is a secret stored within the DRAM and not known to the attacker, so the attacker may not surgically avoid sampling into the tracker.
Moreover, the seed can be changed periodically, to prevent an attacker from reverse-engineering the sequence.

Intuitively, sampling to limit insertions can be implemented either at the Miss Stream or Request Stream.
We analyze both.

Probabilistic Miss Stream Sampling (PMSS): Typical Insertion Policies insert all missing entries into the tracker. When the tracker is full, the Eviction Policy is used to select a suitable victim. Consequently, when the access pattern has a footprint that is larger than the tracker size, the tracker starts thrashing. Past studies have shown that thrashing can be avoided by inserting only a subset of the  miss stream and bypassing the rest <cit.>. 

<ref>(b) illustrates the implementation of PMSS. On a Miss, if there is available capacity in the tracker, the missing entry is installed in the empty locations. If the tracker is full, PMSS uses a PRNG with a sampling probability p to insert a subset of misses into the tracker. 
This preserves a portion of the working set in the tracker, and intermittently installs new entries, thus allowing new untracked rows to be tracked.
In fact, such a technique is deployed in thrash-resistant cache replacement policies like BIP <cit.> and in DSAC's stochastic replacement for aggressor-row tracking.



Probabilistic Request Stream Sampling (PRSS): 
An alternative approach to limit thrashing is to probabilistically sample the request stream and only use a subset of the activations to consult  the tracker.  As shown in <ref>(a), PRSS uses a sampling probability p, based on a a PRNG, to select a subset of the requests to lookup the tracker. The key idea is that frequently accessed rows have a higher chance of being sampled.  Only the sampled requests update on hits and or can insert into the tracker on misses,  while the non-sampled requests bypass the tracker.

For both PMSS and PRSS, the sampling probability p must be selected appropriately. If p is high, the tracker can get thrashed; if p is very low, the non-sampled activations can induce sufficient hammering while escaping mitigations.



Results. <ref> shows the maximum disturbance (i.e., the maximum number of activations any DRAM row receives before a mitigation) as the sampling probability p varies for PRSS and PMSS (using the baseline LFU replacement), across the 500 attack patterns described in <ref>.


The baseline policy of consulting the tracker on all requests/misses (p=1 or 100%) incurs a maximum disturbance exceeding 64K, indicating that the tracker can be easily thrashed. As p reduces, PRSS and PMSS both reduce tracker thrashing because the maximum disturbance decreases until p=0.01 (1%). However, as p reduces below  1%, maximum disturbance starts increasing again. This is because with such low sampling rates, the tracker is severely underutilized, enabling non-sampled rows to induce hammering. This suggests that the sampling rate must ensure at least one insertion per tREFI period. With a maximum of 165 activations per tREFI (see <ref>), ensuring at least one entry in the tracker is populated requires a sampling probability of at least 1/165 (i.e., 0.6%).



The lowest maximum disturbance value for PRSS is 2.2K while that of PMSS is 8.1K (both at p=0.01 (or 1%)). 

PRSS significantly outperforms PMSS because of its underlying implementation.  PMSS by design ensures that the tracker stays fully occupied because invalid entries are prioritized for insertion (see <ref>(b)). Thus, in the steady state, whenever PMSS performs an insertion, a tracker entry must be evicted. 

As such, PMSS still thrashes the tracker and the portion of access pattern that are not resident escape mitigation similar to the baseline. On the other hand, with PRSS, the tracker does not thrash and the occupancy is often below the maximum capacity (on average 80% in our studies) and it performs best when the sampling rate equals the mitigation rate. Given the low chance of eviction, the sampled activations have a higher chance of receiving mitigations, and thus PRSS achieves a much lower maximum disturbance than PMSS. Thus for , we choose PRSS with p=0.01 (1%) as our default design.
As our tracker just begins to have infrequent evictions at this probability, we now study replacement policy.










































 §.§ Random Replacement Policy for Diversity in Tracking

On tracker misses, state-of-the-art trackers <cit.> employ least frequency used (LFU) replacement to select an eviction candidate. 
The goal is to retain heavily accessed rows resident in the tracker so they have the opportunity to be selected for mitigation. 
However, the disadvantage of such deterministic replacement is that it can be exploited by attack patterns to dislodge target entries deterministically.  In doing so, the target entries may be used for continued hammering while escaping mitigations (since they are not  resident in the tracker). 

To address this vulnerability, we propose random replacement on evictions. 
This ensures that evictions are unpredictable to the adversary, thus thwarting attacks that may attempt to dislodge a specific entry. Furthermore, random replacement ensures a diversity of rows are retained in the tracker allowing diversity in mitigations. Note that we only modify the Eviction Policy to use random replacement. We retain and continue to update the frequency counters used by the MFU-based Mitigation Policy, which selects the entry with the highest counter for mitigation.

Results. <ref> shows the maximum disturbance for PRSS with LFU and Random replacement. 
We observe that PRSS with Random replacement is almost always better than LFU replacement. In fact, it achieves a 10% lower minima for the maximum disturbance (2K) compared to LFU based replacement (2.2K). This is because random replacement further avoids thrashing from being easily exploitable by introducing non-determinism into the tracker replacement behavior.




 §.§ Putting it all together: 

Based on <ref>, 
 uses PRSS with random replacement as the default design choice. <ref> shows the complete design of , with the PRSS and random replacement enhancements. As illustrated in the figure,   requires minimal changes to the baseline tracker design. We introduce only two pseudo-random number generators (PRNG): one for PRSS and one for random replacement. <ref> discusses the design overhead of these modifications. 










 §.§ Sizing the Probabilistic Tracker

<ref> illustrates the sensitivity of  to tracker size as it varies from 2 to 128 counters. Across tracker sizes, the lowest value for the maximum disturbance is achieved close to p=0.01 (1%), at which point the tracker insertion rate (approximately 1.6 per tREFI) is close to the mitigation rate (1 per tREFI). 
As tracker size increases from 2 to 128, the maximum disturbance decreases. 
For a 16-entry tracker, the maximum disturbance (at p=0.01) is 2K.
As the tracker size increases to 32, 64, and 128, the maximum disturbance decreases to 1834, 1538, and 1431 respectively. This is because the extra tracker capacity makes the attacker take longer to thrash the tracker. Thus, the chance that a resident entry receives a mitigation before it is evicted increases thereby reducing the maximum disturbance for an attack pattern.
On the other hand, as tracker size decreases from 16 to 4 and 2, the maximum disturbance increases as high as 2.5K. Out of an abundance of caution, we choose the default tracker size of 16 for  (at p=0.01), where the maximum disturbance of 2K is less than half the current TRH of 4.9K.






§ COMBINING  WITH RFM FOR SCALABILITY



Thus far, we studied  with one mitigation per tREFI, which is issued at the time of the regular refresh during tRFC.
Such a design is appropriate for LPDDR4 and DDR4 (and HBM2) memories, where the opportunity for issuing mitigations is only on DRAM refresh commands. 
Given the limited tRFC, it is not practical to issue mitigations for more than one aggressor row per tREFI which involves refreshing victim rows within a blast radius of 2 or 4.

In DDR5 and HBM3 standards, the memory controller can issue Refresh Management (RFM) commands <cit.> to the DRAM for additional mitigative refreshes per tREFI.
We now show how  can leverage these additional mitigations per tREFI to further limit the maximum disturbance.

<ref> shows our design of  with RFMs for DDR5 and LPDDR5 (and HBM3).
The memory controller maintains a Rolling Accumulation of ACTs (RAA) counter  <cit.>) per bank.
When any RAA counter crosses a threshold, RFM_TH, the memory controller resets the RAA counter and issues an RFM command for the corresponding DRAM bank.
To ensure k mitigations per tREFI under continuous activations to a DRAM bank, we set the RFM_TH to ACTs-per-tREFI/k, i.e.,  once every 165/k activations. 
On each RFM-based mitigation, as illustrated in <ref>, the Mitigation Policy (MFU-based) selects an entry from the tracker and correspondingly issues refreshes to victim rows within the blast-radius (radius of 2 by default).





<ref> shows how maximum disturbance varies with sampling probability (p), as the number of mitigations per tREFI is increased (RFM_TH is lowered). 
As the number of mitigations per tREFI is increased from 1 to 2, 4, and 8, the maximum disturbance decreases from 2K to 1K, 533, and 290. 
Additionally, the sampling probability (p) at which the minima for the maximum disturbance increases as the frequency of mitigation increases, with it being at p=0.01 for the baseline and increasing to 0.03, 0.05, and 0.10 for 2, 4, and 8 mitigations per tREFI. 
This shows that the sampling rate must be proportional to the mitigation rate. If the sampling rate is lower than the mitigation rate, then the proposed policy would be unable to issue mitigations since the tracker can be empty. 


Overall, we observe that PROTEAS combined with RFM

is suitable for TRH of 1K and 500.

Thus,  is a simple, practical, and scalable solution as Rowhammer thresholds drop to 500 (by 10x compared to 2020 levels).






V:  Results
1. Maximum disturbance (1 Mitigation per tREFI) of PRESS + Rand-Repl vs  Graphene-LC, DSAC, ??BIP?? 
    – Subsection on DSAC - why does it fail?
2. Maximum disturbance (1-N Mitigations per tREFI) of PRESS + Rand-Repl vs  Graphene-LC, DSAC, ??BIP?? 
3. Number of mitigations for achieving same disturbance for  PRESS + Rand-Repl vs  Graphene-LC, DSAC, ??BIP??
3. Comparison of PARA vs PRESS + Rand-Replacement (Same-Mitigation     Same-Disturbance)
4. Performance evaluations of mitigations/tREFI to achieve K-Threshold (PRESS + Rand-Repl     DSAC, Graphene-LC, PARA)
5. Sensitivity of Performance evaluation to Blast-Radius (mitigation cost increases).





§ RESULTS



 §.§ Evaluation Methodology

We now evaluate  for Rowhammer protection efficacy, performance overheads, and storage overheads.



Rowhammer mitigation efficacy. We use our Rowhammer simulator to compare  with prior probabilistic mitigations such as DSAC <cit.> and PARA <cit.>. We collect the maximum disturbance (number of activations before a refresh) across all 500 attack patterns (<ref>). The reported disturbance is averaged over 100  different seeds provided to the random number generator.
We assume a 16-entry tracker (like TRR) with a baseline policy of deterministic lookup and insertion (100% sampling).
We configure DSAC to target a TRH of 500. 
We configure the baseline, PARA, and DSAC with similar mitigation frequency as  (1, 2, 4, or 8 mitigations per tREFI). 
For PARA, we achieve a rate of 1, 2, 4, and 8 mitigation per tREFI with mitigation probabilities of 0.6%, 1.2%, 2.5%, and 5%. 


Performance evaluations. We also model  in Gem5 <cit.>, a cycle-accurate simulator in the Syscall Emulation (SE) mode. 
We model a 4-core out-of-order CPU with DDR4 2400MT/s memory, with timings based on Micron datasheets <cit.>.
<ref> shows the configuration.
To model the effects of our mitigative action, for 1 mitigation per tREFI configuration, we assume it is issued during tRFC, similar to TRR. 
For additional mitigations per tREFI, we model the overhead similar to RFM, where the bank is busy for a period of 2×blast-radius× tRC.
We evaluate our design with 17 SPEC2017 <cit.> rate workloads and 17 mixed workloads. We fast-forward the workloads by 25 billion instructions to reach regions of interest and simulate for 250 million instructions.  









 §.§ Comparing Maximum Disturbance of 


 <ref> compares the Max-Disturbance for  with prior probabilistic defenses, PRoHIT <cit.>, DSAC <cit.>, and PARA <cit.>. We compare  against a baseline deterministic tracker which samples all lookups and uses LFU for  evictions.







At one mitigation per tREFI,  with 1% sampling achieves a max-disturbance of 2.1K, which is 35X lower than baseline which has a max-disturbance of 74K.
As mitigations per tREFI increase to 2, 4, and 8, the baseline deterministic tracker continues to see a high max-disturbance (65K-67K), whereas  has  max-disturbance that reduces to 1128, 585, and 305 at sampling rates of 3%, 5%, and 10%, respectively.
 achieves 60X to 222X decrease over the baseline because the  deterministic tracker gets easily thrashed despite the additional mitigations per tREFI, and the resident entries are easily evicted between an insertion and potential mitigation, despite the shorter time window with higher mitigation frequency.
However with , the tracker can get thrashed over a much longer period, and hence frequent mitigations limits the time available to an attacker, thus reducing the maximum disturbance linearly.


Mitigs	Baseline	DSAC	PARA	PROTEAS
Mititg/tREFI = 1	73728	40933.5	2461.9	2132.1
Mititg/tREFI = 2	67814	19081.2	1253.9	1128.9
Mititg/tREFI = 4	65536	6483.2	682.5	585.9
Mititg/tREFI = 8	67814	4254.5	348.6	305.2




In comparison, the prior probabilistic tracker PRoHIT <cit.>, achieves a max-disturbance of 21k with one mitigation per tREFI (10x higher than ). This is because Blacksmith patterns deterministically evict entries from PRoHIT's cold table before they are promoted to the hot table, thus avoiding mitigations for hammered rows. Similarly, Samsung's DSAC <cit.>, achieves a max-disturbance of 41K with one mitigation per tREFI (19x higher than ), which decreases to  4K at 8 mitigations per tREFI (14x higher than ). 
This is because DSAC adopts stochastic evictions similar to PMSS in <ref>, which reduces thrashing to a less extent compared to PRSS in .
Moreover, the sampling probability in DSAC varies inversely to the minimum count in the tracker. We observe the p in DSAC dynamically varies between 1 and 0.05 leaving it more vulnerable to thrashing than our PRSS which always operates at the optimal sampling probability.
The highest maximum disturbance for DSAC is achieved for non-uniform attack patterns (where decoy rows are accessed immediately after few iterations of target rows similar to Blacksmith <cit.>) which effectively thrash this tracker and severely degrade its security – these patterns were not evaluated in DSAC.

The maximum disturbance with  is generally lower than PARA at similar mitigation costs. PARA with one mitigation issued per tREFI achieves a max-disturbance of 2.4K (15% higher than ), and with 8 mitigations per tREFI, this reduces to 350 (14% higher than ). 
This is because, unlike PARA where the mitigations are fully probabilistic,  samples probabilistically into the tracker and then intelligently selects entries for mitigation based on frequency. This allows  to achieve slightly better resilience at equivalent mitigation costs.
Moreover, unlike PARA which is required to be implemented in the memory-controller, that requires knowledge of neighboring rows in DRAM,  is an in-DRAM solution that can be managed directly by memory vendors.  

Overall,  <ref> shows that with 1 mitigation per tREFI,  reduces max disturbance by 35X versus baseline, by 10X compared to PRoHIT, by 19X compared to DSAC, and by 15% compared to PARA. With 8 mitigations/tREFI, these reductions with  are 222X vs baseline, 72x vs PRoHIT, 14X vs DSAC, and 14% vs PARA.












 §.§ Comparing Average Disturbance of  
 


We also compare the average disturbance for  to that of PRoHIT <cit.>, DSAC <cit.>, and PARA <cit.>. Again, we compare these against a baseline deterministic tracker which samples all lookups and uses LFU for  evictions.
Figure <ref> illustrates the average disturbance received across the different schemes. The figure shows that with 1 mitigation per tREFI,  reduces average disturbance by 20X versus baseline, by 9X compared to PRoHIT, by 3X compared to DSAC, and by 30% compared to PARA. With 8 mitigations/tREFI, these reductions with  are 135X vs baseline, 62x vs PRoHIT, 6X vs DSAC, and 40% vs PARA.
Thus,  reduces both the maximum disturbance and the average disturbance for the hammered rows compared to all prior probabilistic defenses. 






 §.§ Sensitivity of  to Tracker Eviction Policy




To better understand the impact of replacement algorithms on trackers, we study sensitivity to tracker eviction policy in both deterministic and probabilistic trackers. We study LRU, LFU, BIP <cit.>, and random replacement as the eviction policy but maintain a LFU-based mitigation policy. <ref> illustrates the maximum disturbance for the different eviction policies on the baseline deterministic tracker (no sampling based insertion) and a  tracker. For a deterministic tracker, LRU has the highest maximum disturbance (226K) followed by LFU (70K), which remains high even if mitigation frequency is increased because they are easily thrashed. BIP and Random replacement minimize thrashing and reduce maximum disturbance to 15K and 2K with 8 mitigations per tREFI. BIP is thrash-resistant in that it retains a fixed portion of the access stream in the tracker. Random replacement on the other hand retains different portions of the access stream allowing them to receive mitigations over time <cit.>.

For , there is limited benefit from intelligent replacement policies since the maximum disturbance across all policies are similar. This is because intelligent replacement policies like LRU/LFU/BIP lose  temporal locality information in the request stream and thus behave like random.





 §.§ Performance Overheads of 

We implement  in Gem5 and measure its performance overheads[For space reasons we only report performance of .  and PARA incur similar slowdown. PROTEAS requires 15% fewer mitigation refreshes to achieve similar Max-Disturbance vs  PARA, so it achieves slightly better performance (but both are within 1% of each other). Unlike , PARA is a memory controller solution that cannot be deployed in-DRAM.] at different Rowhammer thresholds, using 1, 2, 4, and 8 mitigations per tREFI which correspond to TRH values of 5K, 2K, 1K, and 500 respectively. 
As shown in <ref>, across 17  SPEC-CPU 2017 workloads and 17 mixed workloads (random combinations of SPEC workloads),  incurs negligible slowdown at TRH of 5K and 2K. 
At these operating points,  requires RFM_TH of 166 and 83, which results in 1 mitigation every 166 or 83 activations in the worst case. As activations are only a subset of memory accesses, the resulting overheads are insignificant.  

At TRH of 1K and 500,  incurs slowdowns of 0.3% and 2.9%. 
The comparatively higher slowdown is because  requires more frequent mitigations at these thresholds (i.e., one mitigation per 42 and 21 activations).
With a default blast-radius of 2, each mitigation incurs 4 activations.
Thus,  at lower thresholds can cause 10% and 20% extra DRAM activations, which leads to higher slowdowns.
The highest slowdowns are for workloads like lbm (14.9%) and blender (13.4%) at TRH of 500, which have the highest DRAM activation rates of more than 20 per thousand instructions (PKI).
Workloads such as cactuBSSN and those after it in the sorted list in <ref> have a DRAM activation rate of less than 1 PKI and thus incur negligible slowdown even at lower thresholds.














 §.§ Sensitivity of Performance to Blast Radius


<ref> shows the performance-sensitivity of  to the blast-radius of the mitigation. 
Our default defense refreshes victim rows within a blast radius of 2 from the aggressor (refreshes to 2 rows above and 2 rows below) to ensure protection against Half-Double <cit.> attacks which flip bits in distance-2 victims.
At TRH of 5K and 2K, we observe negligible slowdown even for blast radius up to 4. 
At TRH of 1K, as blast-radius of mitigation increases from 1 to 2 to 4,  slowdown increases from 0.3%, 0.7%, and 1.5%, whereas at TRH of 500, the slowdown increases from 1% to 3% to 6%.
As mitigation blast radius increases from 1 to 4, the number of neighbor rows refreshed per mitigation increases from 2 to 8. 
This increases the slowdown at lower thresholds.


        TRH  Blast-Radius=1  Blast-Radius=2  Blast-Radius=4
0  TRH=5000           1.000           1.000           1.000
1  TRH=2000           0.999           0.999           0.999
2  TRH=1000           0.997           0.993           0.984
3   TRH=500           0.990           0.971           0.939


















 §.§ Storage Overheads of 


 requires 16 counters (each requiring 5-bytes: 21  bit counter and 17-bit rowID) per DRAM-bank (<ref>). 
In DDR4, across 16 banks, this incurs a storage overhead of 1.3 KB per rank, and in DDR5 (32 banks) requires 2.6 KB of counters  per rank in-DRAM. 
In the memory controller, RFM requires one 8-bit counter per DRAM bank, incurring 32B of storage within the memory controller for 32 banks per rank in DDR5. 
These  overheads are similar to TRR and RFM.




 also requires extra logic for two PRNGs per DRAM bank (for PRSS and random replacement), requiring a few thousand gates <cit.> in-DRAM per bank. We believe this is practical especially since recent work by Hynix <cit.> showcased a DRAM chip fabricated with a PRNG per bank. 



 §.§ Energy Overheads of 

 relies on mitigative refreshes to victim rows to prevent Rowhammer, which can lead to an increase in DRAM energy consumption. 
On one hand, the additional mitigations require extra activation and precharge operations internally within the DRAM, which increase dynamic energy consumption.
On the other hand, extra mitigations may also cause the overall execution time to increase, which causes an increase in static DRAM energy (due to normal refreshes and leakage power).
<ref> shows the average energy overheads for  across 34 workloads reported from Gem5, compared to a baseline without extra mitigations.
On average,  incurs negligible energy overheads at TRH of 5K, whereas at TRH of 1K, this overhead goes up to 0.5%, and 2.4% at TRH of 500. 
While the dynamic energy increases by 4.2% at TRH of 500, the static energy, which makes up the majority of the DRAM energy for several workloads, increases by only 2.3%, making the overall increase in energy of 2.4%. 


	Static Energy	Dynamic Energy	Total Energy
R1	0.0
R4	0.6
R8	2.3





§ RELATED WORK







 §.§ Deterministic Aggressor-Row Trackers


Prior Rowhammer detection mechanisms use resource intensive trackers to identify frequently accessed DRAM rows deterministically. These structures can either be stored on-chip in SRAM or off-chip within the DRAM itself. 
<ref> compares the storage overheads of these trackers with .

At one end of the spectrum, Graphene <cit.> uses the Misra-Gries algorithm for tracking, which provides a lower bound on the number of counters required for guaranteed detection of rows that may be activated beyond the Rowhammer threshold.
Mithril <cit.> and PROTRR <cit.> leverage a similar algorithm and store such a tracker within the logic portion of the DRAM.

However, at TRH of 500, and with the doubling of number of banks in DDR5, such structures require a SRAM storage of 640KB per rank, which is too high to be stored in SRAM on-chip <cit.> or in the logic portion of the DRAM <cit.>. 

At the other end of the spectrum, Hydra <cit.> (and CRA <cit.>) stores one counter per row in DRAM, with additional filters or caches in on-chip SRAM to limit extra accesses to DRAM. 
While such trackers require reserving 2.3MB of storage in DRAM, which is not significant, the SRAM-based performance optimizations are access-pattern dependent, which can lead to a worst-case slowdown of up to 70% with pathological workloads.
Storing such counters in the DRAM array <cit.> to avoid these performance issues requires a significant redesign of the DRAM arrays, which may affect DRAM access times, and is less desirable. 

Other prior trackers typically incur different storage and performance overheads.
TWiCe <cit.> maintains a table of counters to track activations per row, and prunes the entries that are unlikely to reach the Rowhammer threshold to save space. 
CAT <cit.> maintains a dynamic tree of counters which allocates more counters to hot rows, to enable a storage-efficient tracker.
The storage overheads of such solutions scale as the number of attacked rows increase. 
At low thresholds of 500, such solutions incur higher storage overheads than Hydra or CRA, making them impractical.

D-CBF <cit.> uses a counting bloom-filter to identify potential aggressor rows that cross a certain threshold of activations. Unfortunately, as this is a blocklisting-based tracker, rows once inserted into the filter will continue to be flagged as aggressors until the end of the refresh period (64ms) when the tracker can be reset, making it incur high mitigation costs. Additionally, this incurs a high SRAM storage overhead of 1.5MB per rank. 

In contrast,  incurs negligible storage costs of less than 3KB SRAM stored within the DRAM logic area (equivalent to currently deployed TRR) and has low mitigation costs, while providing significantly better security than TRR by enabling effective thrash protection. 



Existing row hammer detection mechanisms maintain counter-based data structures to track frequently access DRAM rows.  These data structures can either be stored on-chip in SRAM or off-chip within the DRAM array itself.  In-DRAM array data structures require changes to the existing DRAM structure and also incur additional bandwidth to retrieve and update the counter values.  Comparatively, on-chip counter-based structures are either placed directly within the memory-controller or in the logic portion of the DRAM. These structures tend to be small and have generally been suitable for large row hammer thresholds (TRH>16K). Scaling these data structures for ultra low row hammer thresholds (i.e., TRH <=500) require impractical data structure sizes. For ultra low row hammer thresholds (TRH=500), <ref> illustrates the storage overheads of recent proposals.  Compared to prior art, PROTEAS requires nearly 20-2000x lower storage overhead. In fact, PROTEAS incurs a negligible 1.3KB overhead on DDR4 and 2.6KB overhead on DDR5 systems.







 §.§ Alternative Rowhammer Mitigation Mechanisms

 uses a mitigative action of refreshing the neighboring victim rows <cit.>.
Alternatively, REGA <cit.> proposed a mitigation of refreshing additional rows in parallel to DRAM activations, at no slowdown, by modifying the DRAM sense amplifiers. 
This avoids slowdown but has the cost of significant additional refreshes and increased DRAM energy consumption.
 can be combined with REGA, to invoke such refreshes selectively only for the neighborhood of aggressor rows, thus significantly lowering the DRAM energy overheads, while enjoying the performance benefits of simultaneous refresh and activation.

Prior works have also proposed alternative mitigation that penalizes the aggressors.


For instance, recent schemes like RRS <cit.> and SRS <cit.> move aggressor rows within memory by periodically swapping them with another random row in memory. 
AQUA <cit.> similarly moves an aggressor row to a quarantine region once it has been activated beyond a certain threshold.
As such mitigative actions are invoked from the memory-controller, they cannot be directly applied with , which is an in-DRAM defense.
On other hand, in-DRAM mitigations like SHADOW <cit.> or CROW <cit.> which similarly relocate aggressor or victim rows in-DRAM within the sub-array at low cost can be combined with . 

Alternatively, memory-controller-based solutions like Blockhammer <cit.> limit the access rate to potential aggressor rows. Such mechanisms incur significant worst-case performance overheads and as such cannot be combined with  given that it is implemented within DRAM.




 §.§ Cryptographic Detection of Rowhammer Bit-Flips

Recent works propose storing cryptographic signatures like Message Authentication Codes (MACs) for data in DRAM, and using them to verify that data is free from tampering on DRAM reads.

SafeGuard <cit.> and CSI-RH <cit.> store MACs for each 64 byte data in DRAM, 

whereas PT-Guard <cit.> only stores MACs for OS page-table data.

Since these solutions detect a Rowhammer attack when bits flip, uncorrectable multi-bit flips can lead to data loss.
On the other hand, because tracker-based solutions like  adopt an orthogonal approach of tracking aggressors and issuing mitigations to prevent a Rowhammer bit-flip, such data loss is prevented.

 

 

Graphene: Graphene <cit.> uses activation counters based on Misra-Gries summaries, a solution to the frequent element problem, to identify aggressor rows from a stream of row activations in the memory controller. When any counter in the tracker crosses a predefined threshold (TRH/2), the associated row is mitigated. The counts in this tracker are always guaranteed to be greater than or equal to the actual row activation counts, so long as the number of tracker entries is greater than  Num-Activations-in-tREFW / (TRH/2). 
For a TRH of 500, this requires 5440 counters per DRAM bank (87K counters per rank) consuming 240 KB SRAM per DRAM rank; additionally to facilitate lookups and updates, this must be organized as a 5400-entry CAM per bank which is impractical <cit.>. 

Mithril: Mithril <cit.> uses a similar Misra-Gries based tracker inside the DRAM, and co-designs it with RFM for getting mitigations issued to the aggressor rows detected by the tracker.
Unfortunately, this faces a similar problem that it requires a tracker of 5400 counters per DRAM bank, which can be impractical for an in-DRAM implementation, given that deployed in-DRAM defenses store only tens of counters.  

Hydra: Hydra <cit.> and CRA <cit.> store one counter per DRAM row, in a reserved portion of the DRAM. 
For a 4GB DRAM Rank (with 8KB rows and 16 banks), this requires 512K counters per rank. 
Unfortunately, this faces performance overheads due to additional DRAM accesses to fetch and update the counters. 
Although these solutions deploy complex caching and filtering mechanisms on-chip within the memory controller  to avoid extra DRAM accesses, in recent work <cit.>, the average slowdown for CRA is shown to be 25%, and for pathological workloads where Hydra's filtering may be ineffective, the worst-case slowdown can be as high as 70%.  

Panopticon: Panopticon <cit.> and PRHT from Hynix <cit.> propose per-row counters stored within the DRAM array. This requires 256K counters per DRAM rank, as above, and may be updated without additional DRAM accesses from the memory controller.
However, this requires significantly redesigning the DRAM MATs, and additional logic to store and update these counters in the background of a DRAM ACT, which can additionally impact DRAM timings.
This added complexity and significant redesign of the DRAM architecture makes such solutions less desirable.



[boxrule=1pt,left=5pt,right=5pt,top=3pt,bottom=3pt]
State-of-the-art trackers require 87K – 512K counters per DRAM rank for thrash protection and incur significant SRAM storage, or complex SRAM and DRAM changes, or suffer high slowdowns, which makes them undesirable.




 §.§ Limited Scalability of Probabilistic Mitigations (PARA)

PARA <cit.> or PRA <cit.> are trackerless probabilistic solutions that issue a neighboring row activation from the memory controller with a probability p on each DRAM activation.
Assuming knowledge of neighboring rows is avalable to memory controller, such solutions allow for Rowhammer mitigation without any tracker or storage costs. 
Unfortunately, as TRH reduces, to maintain sufficient security,  the sampling probability p needs to be increased significantly. Consequently, the additional mitigative activations incur additional performance overheads.
We evaluate the performance impact of increasing sampling probability as TRH drops from 5K to 1K and 500, with 18 SPEC CPU-2017 <cit.> and 18 mixed workloads, on Gem5 <cit.>. 
As  mitigation, we insert additional activations over a blast-radius of 2 (for mitigating Half-Double <cit.>).
As shown in <ref>, PARA has slowdown of 2% at TRH of 5000, but at TRH of 1K and 500, it incurs higher slowdowns of 8% and 13%. This is due to the higher number of mitigations needed at lower thresholds, which add a significant fraction of extra DRAM accesses (20% and 41% extra accesses respectively on average), thus hindering its scalability.








[boxrule=1pt,left=5pt,right=5pt,top=3pt,bottom=3pt]
PARA (and PRA) as a probabilistic, trackerless solution, incurs negligible storage but is not scalable to sub-1K Rowhammer thresholds due to high slowdown.


Recent Probabilistic Trackers. Recently, an unpublished work from Samsung proposed DSAC <cit.>, a stochastic tracker which attempts to filter out decoys rows in TRRespass attacks. It achieves this by reducing the probability of evicting an entry from the tracker on misses progressively as the minimum count in the tracker increases.
While this provides security against TRRespass attacks which uses decoy rows to dislodge hammered rowsI thought TRRespass was cyclical, the consistent reduction in insertion probability allows rows that escape sampling towards the end of a tREFI period to be used for Rowhammer (like in the Blacksmith attack <cit.>)
Our evaluations in Section-X show that DSAC configured to mitigate a TRH of 8K can allow rows to be activated for over 16,000 activations before a mitigation is issued under Blacksmith-like attack patterns (which are not evaluated in DSAC <cit.>). Thus DSAC itself is not secure.[Hynix <cit.> similarly showcased the fabrication of a DRAM chip with a Rowhammer tracker and an in-DRAM pseudo-random number generator, but with no implementation details or evaluations, so its security is unknown.]








§ CONCLUSION





In current DRAM modules, DRAM vendors have deployed Target Row Refresh (TRR) which uses a small in-DRAM tracking structure with tens of counters to detect row hammer attacks. Unfortunately, thrashing-based attack patterns 

have rendered TRR vulnerable. 
This paper proposes  PRObabilistic TrackEr mAnagement policieS () to make in-DRAM trackers thrash resistant.  employs Probabilistic Request Stream Sampling (PRSS) and random replacement to prevent thrashing and introduce diversity in entries held within the tracker.  significantly reduces the maximum disturbance (i.e., number of activations before a mitigation) by 35X compared to a deterministic tracker baseline at current TRH of 4.9K, and by 220X at thresholds of 500 when co-designed with RFM. 

PROTEAS requires only 2.6KB storage overhead on DDR5 systems while incurring only 0.3% and 3% slowdown for TRH of 1K and 500, respectively.





§ ANALYTICALLY DERIVING OPTIMAL SAMPLING RATES




The goal of  is to minimize tracker thrashing. So we operate  at sampling rates that minimizes thrashing.




All entries inserted into the tracker exit the tracker either when they are evicted on a capacity/conflict miss OR when the entry is mitigated.  desires to operate at a sampling probability where thrashing is minimized such that entries inserted exit from the tracker predominantly on mitigations. At this point, the  tracker insertion rate should be at least equal to the tracker mitigation rates, as inserting at a lower rate than the mitigation rate means that the tracker is not fully utilized. The insertion rate should be no more than the mitgation rate, as that would overflow the tracker and cause thrashing.



For sequence of A activations to a tracker with sampling rate S and a given MissRate, the total insertions (I_A) is:


    I_A = A × MissRate × S



The total mitigations (M_A) for A activations assuming  mitigation rate M (number of mitigations per activation) is:



    M_A = A × M




To avoid thrashing,   desires I_A equal M_A. By equating (1) and (2), the sampling rate S is:



    S = M / MissRate



Without loss of generality, assuming a MissRate = 0.5; the optimal analytical sampling rate of  is = M × 2.  <ref> 

shows that the empirical sampling rate closely matches the analytical sampling rate.













IEEEtranS



