1 of 26

ZENHAMMER: Rowhammer Attacks on �AMD Zen-based Platforms

Patrick Jattke^* Max Wipfli^* Flavien Solt �Michele Marazzi Matej Bölcskei Kaveh Razavi

^*Joint first authors

August 14–16, 2024�Philadelphia, PA, USA

Track 2 – Side Channel II:�Rowhammer

2 of 26

Executive Summary

Today, every third sold x86 CPU is from AMD

2

Are current AMD Zen-based platforms vulnerable to Rowhammer?

63.9%

33.4%

We find bit flips on 7/10 DIMMs (Zen 2) and 6/10 DIMMs (Zen 3).
Up to 46x more bit flips on Zen 3 than on Coffee Lake.
First bit flips on one DDR5 DIMM on Zen 4.

We built ZENHAMMER to answer this!

AMD Zen introduced

No Rowhammer attacks on AMD Zen*

3 of 26

Background

DIMM Organization

DRAM addressing

3

DRAM Address

Physical address

CPU

Virtual address

Processor

Memory �Controller

Rowhammer

Application

Two bits flipped!

Double-sided pattern

Zen*

Before we talk about ZenHammer, let me give you a quick overview of DRAM and Rowhammer.
Multiple DRAM chips are mounted on DRAM DIMMs

and each DRAM chip consists of several banks that are organized into bank groups.
Each bank is made of a matrix of rows and columns and each cell stores a bit of information as a charge.
Whenever data is read from or written to the DRAM bank, the whole row first needs to be loaded into the row buffer, which causes a measurable delay when another row has been loaded of that bank before.

The Rowhmmer vulnerability is a memory disturbance error.

It happens when two rows are accessed (or hammered) with one row in between.
Repeating this hammering many times over and over again leads to bit flips by draining charge from capacitors in the victim row.

As Rowhammer requires that we very precisely address rows, we need the DRAM address mappings that are used by the memory controller to translate physical addresses into DRAM addresses.

These mappings, however, are part of the in-CPU memory controller and until now have not been reverse engineered for AMD Zen-based systems.

4 of 26

C1 Recovering DRAM address mappings

4

Function output of f(x) = 0x64440100 for same-cluster addresses.

Function output of f(x) after applying an offset of 768 MiB.

Recovery of correct function �g(x) = 0x44440100 with offset 768 MiB.

O1. DRAM functions are non-linear and require an address offset.

O2. Memory blocks >1 GiB need to be accessed for mapping recovery.

DRAMA [1] could not recover mappings.�⇨ Functions only worked on limited memory regions.

C0

C1

..

C#bk

1. Building timing clusters

2b Functions

00..0011

00..0101

…

10..0001

…

11..0000

C0

f( ) = f(a0…aN) = 0

f( ) = 1

…

f( ) = 0

C1

C#bk

Expected:

50%: 0

50%: 1

2. Brute-forcing DRAM functions

[1] P. Pessl, D. Gruss, C. Maurice, M. Schwarz, and S. Mangard, “DRAMA: Exploiting DRAM Addressing for Cross-CPU Attacks,” in USENIX Security ’16.

a0

a1

…

aN

DRAM₃

DRAM₂

PCI

DRAM₁

DRAM₂

DRAM₃

CPU�(phy. address space)

AMD

0 GiB

4 GiB

TOM

Our first challenge is recovering these secret DRAM address mappings.
We first tried the established DRAMA approach, which consists of

Creating bank-conflict clusters using a timing side channel
And then systematically testing potential address functions, for example, 2-bit XOR functions by applying them on all addresses of a bank cluster.
If the function is correct, we would expect that

all addresses within a cluster lead to the same result
and that halve of the clusters result in 0 and the other halve in 1.

DRAMA, however, could not recover the mappings: the found mappings only worked on limited memory regions.

We then used the same approach to build same-bank address clusters over a larger memory area.

We found that the distribution between the function’s output values is not even, as you can see in this example.

So we tried to subtract different offsets to see how this changes the result.

As you can see here, the result for some addresses changed and the number of addresses between function output values is now equal.

Using these system-specific offset we were then able to recover the correct address mappings.
We learned from this that DRAM functions may be non-linear and may require a constant offset to be substracted.

This is because on AMD systems physical memory is remapped due to the physical address space below the 4 GiB mark that is reserved for PCI devices.

Another observation is that we need memory areas larger than 1 GiB to recover the functions on AMD systems.

5 of 26

C1 Recovering DRAM address mappings

Visualization of <1 RK, 4 BG, 4 BK, 2¹⁶ rows> functions.

5

See our paper for more �DRAM configurations!

Physical Address Bit	32	28	24	20	16	12	8	4	0
AMD Zen 3
BG 0x0022220100
BG 0x0044440200
BA 0x0088880400
BA 0x0111100800
ROW 0x01fffe0000
AMD Zen+/Zen 2
BG 0x0088883fc0
BG 0x0111104000
BA 0x0022228000
BA 0x0044450000
ROW 0x01fffe0000

6 of 26

Testing for Rowhammer

We created the Blacksmith [2] fork ZenHammer with our found DRAM address mappings.
DIMMs from major manufacturers:

6h fuzzing runs on each DIMM.

6

DIMM	Zen 2		Zen 3		Coffee Lake
DIMM	#Patt.	#Bit Flips	#Patt.	#Bit Flips	#Patt.	#Bit Flips
S₀	14	19	0	0	122	3’502
S₁	4	4	0	0	102	1’374
S₂	14	28	0	0	782	22’339
S₃	0	0	0	0	3	3
S₄	4	5	0	0	47	654
S₅	6	7	0	0	155	4’131
H₀	0	0	0	0	24	35
M₀	0	0	0	0	16	23

5/10 devices

0/10 devices

8/10 devices

⇨ Porting the DRAM address functions is insufficient to do Rowhammer on AMD Zen-based systems.

[2] P. Jattke, V. van der Veen, P. Frigo, S. Gunter, and K. Razavi, “BLACKSMITH: Scalable Rowhammering in the Frequency Domain,” in IEEE S&P ’22.

6x

2x

7 of 26

In-DRAM TRR: REF synchronization

Rowhammer mitigations (TRR) act at the same time as periodic REFs.

7

…

Rowhammer pattern of length 4 tREFI

time

REF

TRR

REF

TRR

REF

TRR

Non-synchronized

…

Memory access

Synchronized

SMASH [3],�Blacksmith [4]

…

REF synchronization

Requirement for doing Rowhammer:

⇨ proper synchronization with REFs ( C2 )

[3] F. de Ridder, P. Frigo, E. Vannacci, H. Bos, C. Giuffrida, and K. Razavi, “SMASH: Synchronized Many-sided Rowhammer Attacks From JavaScript,” in USENIX Security ’21

[4] P. Jattke, V. van der Veen, P. Frigo, S. Gunter, and K. Razavi, “BLACKSMITH: Scalable Rowhammering in the Frequency Domain,” in IEEE S&P ’22.

Therefore, we looked more into other possible reasons.
A major concern was that we might not bypass the in-DRAM TRR mitigations, which act at the same time as periodic refreshes.
However, TRR might not happen at every REF but, for example, only every fourth refresh.
This is why frequency-based Rowhammer patterns can also be longer than one refresh interval (tREFI), for example here it is 4 tREFI.
When hammering a pattern, we basically just repeat this pattern many times over and over again.
You can see that if we just start hammering at any time, then the pattern shifts in between these four refresh intervals, which makes it easier for the mitigation to detect aggressors.
Therefore, state-of-the-art patterns synchronize with the refresh command before hammering and before each pattern repetition, as shown in Blacksmith and using soft-synchronization in SMASH.
As this synchronization routine is platform-dependent and might not work as expected on Zen-based systems, we addressed it in Challenge 2.

8 of 26

C2 Adapting timing-based� REF synchronization

We measured the time between REFs.

8

Solution: Continuous, non-repeating refresh synchronization.

Zen 3

Zen+

Correct detection

No clear signal

t0

t1

A₁

A₂

F₁

F₂

REF

…

REF detected

REF

…

REF detected

REF

REF undetected

…

REF

t1

t2

t0

REF

…

REF sync.

= Mem. access

= Flush

⇨ Synchronization does not work on Zen 3.

t0

t1

t2

Our second challenge is adapting the timing-based refresh synchronization to make it work on AMD systems.
We measured the time between consecutive refreshes and found that on Zen+ the detection works correctly but on Zen 3 it does not show a clear signal.
Looking at the synchronization routine, where rectangles are accesses and triangles flushes, the REF can successfully be detected if it happens in between our two accesses or in between the flushes;

but it cannot be detected if it happens between repetitions of the synchronization routine as our time measurement stops before repeating again.

We found two issues in the current synchronization routine that we fixed by using a continuous, non-repeating refresh synchronization.

First, we use distinct rows to avoid the need for flushing caches which increases precision as flushes are non-constant, and
Second, we use a continuous timing measurement that avoids blind gaps.

We found that this new routine strongly improves the refresh synchronization.

9 of 26

C2 Adapting timing-based REF synchronization

9

tREFI (7.8μs)

7.81

7.77

#Rows used for synchronization

Original

Improved

7.62

5.37

10 of 26

In-DRAM TRR: activation count

10

time

REF

TRR

REF

TRR

REF

…

Synchronized hammering

…

Requirements for doing Rowhammer:

⇨ sufficient activation count to the aggressors ( C3 )

Decoy rows

To bypass mitigations

REF

TRR

refresh window (64 ms)

≜ 8192 refresh intervals

11 of 26

C3 Increasing the ACT rate and preserving order

On average, ACTs/tREFI on Z+ (41.9) and Z3 (37.2) are halved compared to CL (76.8).

11

Access �Type	Flushing�Strategy	Fence�Type	#Rows
Access �Type	Flushing�Strategy	Fence�Type	1	2	4	8	16	32	256
MOV (load)	gather	mfence	24	49	71	91	100	110	114
MOV (load)	gather	lfence	24	49	80	113	134	147	121
MOV (load)	gather	sfence	24	49	80	113	133	146	125
MOV (load)	gather	–	24	49	80	113	133	146	125
MOV (load)	scatter	mfence	24	49	79	107	126	143	157
MOV (load)	scatter	lfence	24	49	95	137	149	153	159
MOV (load)	scatter	sfence	24	48	97	154	159	159	159
MOV (load)	scatter	–	24	49	97	154	159	159	159
PREFETCHNTA	scatter	–	80	132	191	208	243	309	273
PREFETCHNTA	scatter	mfence	24	49	80	108	141	170	284

BEST

Cache

hits

Systematic testing of different �hammering instruction sequences:

Cache flushing �(e.g., CLFLUSH/CLFLUSHOPT, gathered/scattered)
Memory barriers �(e.g., mfence, lfence, sfence)
Access types�(e.g., load vs store)
Vector instructions�(e.g., vpgatherdd)

Zen 3

Max.�ACTs

40 ACTs/tREFI gives 36K ACTs with 18 aggs.

⇨ too low for many devices

Z+

Z3

CL

Gathered flushes

Scattered flushes

A₁

A₂

A₃

A₄

A₅

A₆

…

F₁

F₂

F₃

F₄

F₅

F₆

A₁

A₂

A₃

A₄

A₅

A₆

…

F₁

F₂

F₃

F₄

F₅

F₆

Our last challenge is increasing the activation rate while preserving the order of memory accesses.
For this, we measured the activation rate on our Zen+ and Zen 3 systems and we found that the activation rate is halved compared to Coffe Lake.

If we assume that we need at least 18 aggressors to bypass the mitigation, then the resulting hammer count of 36k is too low for many devices to trigger any bit flips.

To increase the ACT rate, we systematically tested dfifferent hammering instructions sequences, including

Cache flushing with CLFLUSH or CLFLUSHOPT and either flushing at the end of the pattern (”gathered”) or right after accessing each aggressor (“scattered”)
Dfiferent types of memory barriers
Loads and stores
And also vector instructions.

We found that scattering with either SFENCE or no fences at all achieve the highest activation rate across different pattern lengths.

This turned out to be one of the reasons why we could not find bit flips on Zen 3.
We also found that some combinations cause cache hits, which are undesirable for doing Rowhammer.

12 of 26

Evaluation: Best Rowhammer pattern

12

DIMM	Zen 2		Zen 3		Coffee Lake
DIMM	#Patt.	#Bit Flips	#Patt.	#Bit Flips	#Patt.	#Bit Flips
S₀	51	6’945	31	17’775	122	6’782
S₁	26	1’758	25	15’613	102	10’106
S₂	97	12’893	45	79’306	782	1’708
S₃	8	2’020	1	667	3	0
S₄	60	1’183	43	13	47	18’357
S₅	25	1’911	26	10’741	155	5’860
H₀	6	182	0	0	0	0
H₁	0	0	0	0	24	0
M₀	0	0	0	0	0	0
M₁	0	0	0	0	16	2

Optimizations drastically increased #effective patterns.
Higher #bitflips in 4 cases (Z2) and 5 cases (Z3) compared �to Coffee Lake.
Bit flips on DIMM H₀ on Z2 where we found none on Coffee Lake.
We also analyzed the impact on exploitation, see �our paper for results!

7/10 devices

6/10 devices

8/10 devices

5/10 devices

0/10 devices

13 of 26

Demo: PTE Attack on AMD Zen 3

13

14 of 26

Evaluation: ZENHAMMER on DDR5

Upon the request of reviewers, we �extended our evaluation to Zen 4.
We repeated all experiments and �tested 10 random DDR5 DIMMs.

4x
1x
5x

We found bit flips on 1/10 DIMMs:

41’995 bit flips during 256 MiB sweep

14

Microarch.	Release Date	CPU
Zen 4	September 2022	Ryzen 7 7700X
Zen 3	November 2020	Ryzen 5 5600G
Zen 2	July 2019	Ryzen 5 3600X
Zen+	April 2018	Ryzen 5 2600X

Reviewer A: Do you have any early results/thoughts on Zen4 applicability?

Reviewer C: However, the newest microarchitecture that is evaluated is Zen 3 from 2020. Since then, there have been […] Zen 4 (2022) […]

15 of 26

Check out our paper�for more information!

pjattke@ethz.ch

pjattke

linkedin.com/in/pjattke

Conclusion

Current AMD Zen-based systems are equally vulnerable to Rowhammer as Intel systems.

DRAM addr. mappings

for Zen 2/3/4 incl. offsets.

Up to 46x more bit flips

on Zen 3 compared to Coffee Lake.

Exploitation

in the best case (PTE) in just 6s (Zen 2) and 2s (Zen 3).

End-to-end�PTE exploit on Zen 3.

ZenHammer bit flips

Zen 2: 7/10 DIMMs

Zen 3: 6/10 DIMMs

Zen 4: 1/10 DIMMs

First ever reported DDR5 bit flips!

DDR4

DDR5

Patrick Jattke

16 of 26

Are current AMD Zen-based platforms vulnerable to Rowhammer attacks?

Our test systems

16

Microarchitecture	Release Date	CPU
Zen 3	November 2020	Ryzen 5 5600G
Zen 2	July 2019	Ryzen 5 3600X
Zen+	April 2018	Ryzen 5 2600X

17 of 26

Executive Summary

Today, every third sold x86 CPU is from AMD�⇨ not reflected in Rowhammer attack research

17

Are current AMD Zen* platforms vulnerable to Rowhammer?

63.9%

33.4%

Intel

AMD

We find bit flips on 7/6 DIMMs on Zen 2/3
46x more bit flips on Zen 3 than on Coffee Lake ⇨ devices are easier exploitable
First bit flips on one DDR5 DIMM on Zen 4

19x

1x

(C1) DRAM addr. mapping

(C2) Timing-based REF synchronization

(C3) ACT rate and memory access order

DRAM �Address

Phy.�Address

…

vs.

ACTs/tREFI

a

b

a

b

a

b

Before we get started, let me give you a brief overview about our work.
AMD has been gaining market share over the last decade and today, every third sold x86 CPU is from AMD.

This, however, is not reflected in the Rowhammer attack research.
If we look at the existing Rowhammer attack papers we see that almost all are focused on Intel platforms and none has looked at newer AMD Zen-based systems.

Therefore, we asked ourselves if current AMD Zen-absed platforms are vulnerable to Rowhammer.
To answer this, we had to solve three challenges:

Reverse engineering the DRAM address mappings
Adapting the timing-based refresh synchronization, and
Optimizing the activation rate while preserving the memory access order.

With these changes, we find bit flips on 7 and 6 DIMMs on AMD Zen 2 and 3, compared to 8 DIMMs on Coffee Lake.
We find 46 times more bit flips on Zen 3 than on Coffee Lake, making devices easier exploitable.
And we also present the first bit flips on one DDR5 DIMM on Zen 4.

18 of 26

C3 Increasing the ACT rate and preserving order

We designed and evaluated six fence scheduling policies during 6h fuzzing runs on all devices/platforms.

18

SP_NONE

SP_BP

SP_BP/2

SP_PAIR

SP_REP

SP_FULL

A₁

A₂

A₁

A₂

A₃

A₄

A₃

A₄

A₃

A₄

A₁

A₂

A₁

A₂

A₅

A₆

A₅

A₆

A₅

A₆

A₁

A₂

A₁

A₂

A₃

A₄

A₃

…

A₁

A₂

A₁

A₂

A₃

A₄

A₃

A₄

A₃

A₄

A₁

A₂

A₁

A₂

A₅

A₆

A₅

A₆

A₅

A₆

A₁

A₂

A₁

A₂

A₃

A₄

A₃

…

A₁

A₂

A₁

A₂

A₃

A₄

A₃

A₄

A₃

A₄

A₁

A₂

A₁

A₂

A₅

A₆

A₅

A₆

A₅

A₆

A₁

A₂

A₁

A₂

A₃

A₄

A₃

…

A₁

A₂

A₁

A₂

A₃

A₄

A₃

A₄

A₃

A₄

A₁

A₂

A₁

A₂

A₅

A₆

A₅

A₆

A₅

A₆

A₁

A₂

A₁

A₂

A₃

A₄

A₃

…

A₁

A₂

A₁

A₂

A₃

A₄

A₃

A₄

A₃

A₄

A₁

A₂

A₁

A₂

A₅

A₆

A₅

A₆

A₅

A₆

A₁

A₂

A₁

A₂

A₃

A₄

A₃

…

A₁

A₂

A₁

A₂

A₃

A₄

A₃

A₄

A₃

A₄

A₁

A₂

A₁

A₂

A₅

A₆

A₅

A₆

A₅

A₆

A₁

A₂

A₁

A₂

A₃

A₄

A₃

…

Base �period

Memory barrier (fence)

Double-sided�aggressor pair

19 of 26

Evaluation: Best Rowhammer pattern

ZenHammer fuzzing in three stages

19

3

256 MiB

. . .

Large sweep of the best pattern ⇨ # Bit flips

2

4 MiB

..

Quick sweep of each �effective pattern ⇨ best pattern

Effective patterns

Best pattern

1

Short fuzzing with each fence �scheduling policy ⇨ SP_OPT

SP_OPT

SP

SP_PAIR

x

ZENHAMMER

x

After all these optimizations, we again tested Rowhammering.
We followed a three steps methodology,

We first fuzzed for 6h with each fence scheduling policy to determine the best policy SP_OPT
We then sweeped each effective pattern over 4 MiB of contiguous memory to determine the best pattern
And finally, we sweeped the best pattern over 256 MiB of contig. Memory

Our results show that our optimizations drastically improved results.

On Zen 2, we now found bit flips on 70% of the devices instead of 50% before and
on Zen 3, where we found no bit flips before, we found bit flips on 60% of the devices.

In the best case, Samsung DIMM S2, we found roughly six times more patterns.
We also find in 4 and 5 cases more bit flips on Zen 2 and Zen 3 compared to Coffee Lake.
Interestingly, we also found bit flips on one Hynix device H0 on Zen 2 where we found none on Cofffee Lake.

We also repeated the same experiments on a Zen 4 (DDR5) machine and found bit flips on one out of 10 tested DDR5 devices.

20 of 26

C3 Increasing the ACT rate and preserving order

On average, ACTs/tREFI on Z+ (41.9) and Z3 (37.2) are halved compared to CL (76.8).

40 ACTs/tREFI gives HC of 36K for n=18�⇨ too low for many devices.

20

Zen+

Z3

CL

R1

R2

Recommendations

Systematic testing of different hammering instruction sequences:

Cache flushing �(e.g., CLFLUSH vs CLFLUSHOPT, gather vs scatter)
Memory barriers �(e.g., mfence, lfence, sfence)
Access types�(e.g., load vs store)
Vector instructions�(e.g., vpgatherdd)

R3

O4. Memory loads following a CLFLUSH(OPT) never incur cache hits on Zen 3 but on Zen+/2.

21 of 26

C2 Adapting timing-based REF � synchronization

We measured the time between REFs.�⇨ Synchronization does not work on Zen 3.

21

Solution: Continuous, non-repeating refresh synchronization.

Correct detection

Zen 3

Zen+

No clear signal

O3. Continuous, non-repeating time measurements strongly improve REF synchronization.

t0

t1

t2

t3

t4

t5

t6

t7

t0

t1

t2

t3

t4

t5

t6

t7

Issue: REF<t5,t6> not detected

⇨ measure continuously

Issue: Measurement imprecise

ACTs/tREFI = 8 x + 8 x

⇨ eliminate flushes

A₁

A₂

F₁

F₂

REF

t0

t1

t2

t3

t4

t5

t6

t7

t8

t9

t10

t11

Our second challenge is adapting the timing-based refresh synchronization to make it work on AMD systems.
We looked at refresh synchronization as previous work showed that in-DRAM TRR mitigations work at refresh time, so proper synchronization is essential to bypass Rowhammer mitigations.
We measured the time between consecutive refreshes and found that on Zen+ the detection works correctly but on Zen 3 it does not.
We found two issues in the current synchronization routine that we fixed by using a continuous, non-repeating refresh synchronization.

First, we use distinct rows to avoid the need for flushing caches which saves time, and
Second, we use a continuous timing measurement that avoids blind gaps.

We found that this continuous, non-repeating timing measurements strongly improve the refresh synchronization.

22 of 26

C3 Increasing the ACT rate and preserving order

We designed six fence scheduling policies and evaluated them during 6h fuzzing runs on all devices/platforms.

22

Policy	Fencing Frequency	Pattern-Aware	Cache-Avoiding
SP_NONE	No fences	✘	✘
SP_BP	Every base period	✓	✘
SP_BP/2	Every half base period	✓	✘
SP_PAIR	Between different aggressor pairs	✓	✘
SP_REP	Between aggressor pair repetitions	✓	✓
SP_FULL	Every access (Blacksmith default)	✘	✓

Optimal Policy SP_OPT

⇨ Zen 2 (75%), Zen 3 (43%)

⇨ Coffee Lake (100%)

Stronger ordering

23 of 26

Evaluation: Exploitation

We simulate attacks using Hammertime: page table flipping (PTE;+PoC), �flip feng shui (RSA-2048), sudo binary (sudo).
High number of bit flips significantly reduces the time for exploitation and increases the number of exploitable devices.

23

Check out our paper�for details on the PoC!

DIMM	PTE						RSA-2048						sudo
	Zen 2		Zen3		Coffee Lake		Zen 2		Zen3		Coffee Lake		Zen 2		Zen3		Coffee Lake
	#Ex.	Time	#Ex.	Time	#Ex.	Time	#Ex.	Time	#Ex.	Time	#Ex.	Time	#Ex.	Time	#Ex.	Time	#Ex.	Time
S₀	7	6m 4s	7	2m 55s	3	15s	17	2m 47s	37	46s	14	1m 36s	–	–	4	3m 13s	1	23m 49s
S₁	90	9s	1’474	2s	846	2s	6	2m 2s	27	30s	21	26s	–	–	1	6m 50s	1	1m 20s
S₂	641	21s	5’326	1s	126	11s	30	2m 16s	170	6s	6	1m 59s	–	–	12	1m 17s	–	–
S₃	142	9s	61	32s	–	–	7	2m 21s	–	–	–	–	–	–	–	–	–	–
S₄	220	28s	3	23m 52s	2’658	1s	7	12m 29s	1	23m 52s	53	26s	–	–	–	–	4	5m 16s
S₅	102	6s	625	2s	330	4s	6	1m 14s	28	33s	11	5s	–	–	2	5m 58s	3	2m 34s
H₀	11	53s	–	–	–	–	–	–	–	–	–	–	–	–	–	–	–	–
Median		21s		17s		4s		2m 19s		33s		1m 5s				4m 36s		3m 55s

24 of 26

In-DRAM TRR: Order of accesses and ACT rate

Issue: the memory controller reorders accesses�⇨ enforce order by adding memory fences: which fence? where?

24

refresh window (64 ms)

≜ 8192 refresh intervals

refresh interval (7.8 µs)

REF�+TRR

REF

REF�

REF�+TRR

REF

REF�+TRR

REF

time

memory access�(hammer)

Issue: too few ACTs due to hammering ”too slowly”�⇨ the ACT rate should be maximized to make bit flips more likely

A₁

A₂

A₁

A₂

A₃

A₄

A₁

A₂

A₃

A₄

Program:

A₁

A₂

A₁

A₂

A₃

A₄

A₁

A₂

A₃

A₄

Execution (after optimization):

25 of 26

AMD Zen-based systems are equally vulnerable to Rowhammer as Intel systems.
We disclose the secret DRAM mappings for AMD �Zen-based systems including their address offsets.
We found bit flips on 7 DIMMs (Zen 2) and 6 DIMMs (Zen 3) compared to 8 DIMMs on Intel Coffee Lake.
We show 46x more bit flips on Zen 3 than on Coffee Lake ⇨ devices are easier exploitable
In the best case, we only need 6s (Zen 2) and �2s (Zen 3) to mount an attack (PTE).

Check out our paper�for more information!

pjattke@ethz.ch

pjattke

linkedin.com/in/pjattke

Conclusion

26 of 26

C3 Increasing the ACT rate and preserving order

26

O6. For SK Hynix devices, SP_PAIR works best across all devices.

O7. For Micron devices, preserving the access order is essential.

O5. For Samsung devices, SP_PAIR is most widely applicable and most effective.