Repository navigation
Expand file tree
/
Copy pathindex.html
More file actions
381 lines (339 loc) · 21.7 KB
/
Copy pathindex.html
File metadata and controls
381 lines (339 loc) · 21.7 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
<!DOCTYPE html>
<html lang="en">
<head>
<title>RMPocalypse Attack</title>
<meta charset="UTF-8" />
<meta property="og:title" content="RMPocalypse Attack">
<meta property="og:description" content="How A Catch-22 Breaks AMD SEV-SNP">
<meta property="og:type" content="website">
<meta property="og:url" content="https://rmpocalypse.github.io/">
<meta property="og:image" content="https://rmpocalypse.github.io/preview.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="627">
<meta property="og:site_name" content="RMPocalypse Attack">
<meta name=twitter:card content="summary_large_image">
<meta name=twitter:image content="https://rmpocalypse.github.io/preview.png">
<meta name=twitter:title content="RMPocalypse Attack">
<meta name=twitter:description content="How A Catch-22 Breaks AMD SEV-SNP">
<meta name=twitter:site content="@sectrs_ethz">
<meta name=description content="How A Catch-22 Breaks AMD SEV-SNP">
<script
type=application/ld+json>{"@context":"https://schema.org","@graph":[{"@type":"WebSite","url":"https://rmpocalypse.github.io/","name":"RMPocalypse Attack","description":"AMD SEV-SNP offers confidential computing in form of confidential VMs, such that the untrusted hypervisor cannot tamper with its confidentiality and integrity. SEV-SNP, the latest addition, ensures integrity via the Reverse Map Table (RMP) that stops the hypervisor from tampering guest page mappings. AMD uses RMP entries to protect the rest of the RMP, thus causing a Catch-22 during the RMP setup phase. To address this, SEV-SNP relies on AMD's Platform Security Processor (PSP), that resides next to the x86 cores executing SEV-SNP VMs, to perform the RMP initialization. During initialization, only PSP should be able to alter the RMP memory. All other memory accesses must be fenced, especially from the x86 cores. We present RMPocalypse, a novel attack that shows a critical gap in the security of RMP initialization, wherein the x86 cores maliciously control parts of the initial RMP state. Our analysis shows that the vulnerability arises due to the complex, but insufficient, interplay of multiple hardware components and distributed access controls. To show the impact of our finding, we exploit this gap to break confidentiality and integrity guarantees of SEV-SNP. We demonstrate RMPocalypse by enabling debug on production-mode CVMs, faking attestation, VMSA state replay, and code injection"}]}</script>
<script
type=application/ld+json>{"@context":"https://schema.org","@graph":[{"@type":"Organization","url":"https://rmpocalypse.github.io/","name":"Secure and Trustworthy Systems Group ETHZ","image":[{"@id":"https://rmpocalypse.github.io/preview.jpg"}],"logo":{"@id":"https://rmpocalypse.github.io/android-chrome-512x512.png"]}</script>
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="shortcut icon" type="image/x-icon" href="favicon.ico">
<link href="https://cdn.jsdelivr.net/npm/tailwindcss@2.2.19/dist/tailwind.min.css" rel="stylesheet">
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap" rel="stylesheet">
<style>
html {
scroll-behavior: smooth;
font-family: 'Inter', sans-serif;
}
</style>
</head>
<body class="bg-gray-50 text-gray-800 font-inter">
<section class="min-h-screen flex items-center justify-center bg-black text-white px-6">
<div class="max-w-6xl mx-auto flex flex-col md:flex-row items-center gap-10">
<!-- Image -->
<div class="md:w-1/2 text-center">
<img src="rmpocalypse_logo.png" alt="RMPocalypse: How a Catch-22 Breaks AMD SEV-SNP"
class="mx-auto w-full max-w-lg rounded-lg shadow-lg" />
</div>
<!-- Text Content -->
<div class="md:w-1/2 text-center md:text-left">
<h1 class="text-5xl font-bold mb-4">RMPocalypse</h1>
<p class="text-xl mb-6">How a Catch-22 Breaks AMD SEV-SNP<br>(ACM CCS 2025)</p>
<a href="#abstract" class="bg-white text-black px-6 py-3 rounded-full font-semibold">Learn More</a>
</div>
</div>
</section>
<!-- Abstract -->
<section id="abstract" class="max-w-3xl mx-auto py-16 px-6">
<h1 class="text-3xl font-bold mb-6 text-center">
Summary
</h1>
<article class="text-justify text-lg leading-relaxed text-gray-900 space-y-6">
<p>
Confidential computing allows customers to off-load their computation to the cloud without having to
trust the cloud provider. One of the approaches to enable confidential computing is by anchoring the
trust in the hardware. AMD’s SEV-SNP, one such hardware mechanism, supports confidential computing by
creating confidential virtual machines. With RMPocalypse, we demonstrate an attack on all AMD processors
that support SEV-SNP (Zen 3/4/5) and compromise all confidential computing guarantees.
Reverse Map Table, in short RMP, is one of the main protection mechanisms in SEV-SNP to stop the
hypervisor from accessing the confidential virtual machines. In RMPocalypse, we exploit AMD’s incomplete
protections that allow us to perform a single memory write to the RMP, thus breaking SEV-SNP.
</p>
<h2 class="text-xl font-semibold mt-2">What is AMD SEV-SNP? </h2>
<p>
Secure Encrypted Virtualization-Secure Nested Paging, SEV-SNP for short, is AMD’s latest hardware
extension to support confidential computing.
</p>
<h2 class="text-xl font-semibold mt-2">What is RMP? </h2>
<p>
SEV-SNP uses a data structure called Reverse Map Table (RMP) to store security metadata for all DRAM
pages in the system. Since RMP can be large in size, it is stored in the DRAM. Now you might ask, who
protects the RMP? Well, the RMP! Easier said than done, as this design choice by AMD creates a
chicken-and-egg problem. The main challenge lies in the initialization, when the RMP is being set up in
the DRAM, there has to be an orthogonal mechanism in place to make sure this is done correctly. Only
after a successful initialization can the RMP protect itself (and of course the confidential VMs). AMD
has an elegant solution to this problem. They use a security co-processor called the PSP to initialize
the RMP. During initialization, platform protection mechanisms configured by the PSP protect the RMP.
</p>
<h2 class="text-xl font-semibold mt-2">What went wrong?</h2>
<p>
RMPocalypse shows that AMD’s platform protection mechanisms are not complete, thus leaving a small
window of opportunity for the attacker to maliciously overwrite the RMP on initialization. Due to the
design of the RMP, a single overwrite of 8 bytes within the RMP causes the entire RMP to become
subsequently compromised. With a compromised RMP, all integrity guarantees of SEV-SNP become void.
RMPocalypse case studies show that an attacker-controlled RMP not only voids the integrity but also
results in a full breach of confidentiality.
</p>
<h2 class="text-xl font-semibold mt-2">What can an attacker do with this vulnerability?</h2>
<p>
We showcase RMPocalypse primitives by forging attestation values, enabling debug, reading and writing
arbitrary encrypted CVM memory, and replaying the CVM register state.
</p>
</article>
</section>
<section id="abstract" class="max-w-3xl mx-auto py-4 px-6 text-center">
<h1 class="text-3xl font-bold mb-5">Attack Overview</h1>
<article class="text-justify text-lg leading-relaxed text-gray-900 space-y-6">
<p>
AMD performs an initialization step when the hypervisor wants to enable SEV-SNP on the platform. Setting
up the RMP is one of the critical steps in this initialization. Thus, during initialization, AMD blocks
all the memory accesses to the memory region that holds the RMP data structure. In particular, AMD uses
so-called Trusted Memory Regions (TMRs) to block any access from untrusted components (e.g., x86 cores).
</p>
<p>
In our analysis of the RMP initialization, we observed that the malicious hypervisor running on the x86
cores can still create dirty cachelines pointing to DRAM. As the TMR barrier only stops the memory
access at the memory controller level, it cannot stop cache pollution. Note that this in itself does not
compromise SEV-SNP yet, since the RMP is still intact in memory at this point and if the attacker tries
to flush the entry, the TMR will block it. It is after the initialization, when AMD lifts the TMR
barrier, when we can perform the flush, and the write goes through to the DRAM!
</p>
<p>
In summary, we identify the root-cause as the misalignment of different memory protection mechanisms on
the platform.
</p>
</article>
<!-- Image -->
<div class="text-center py-6">
<img src="AttackDetail.svg"
alt="High level overview of the RMPocalypse attack during SEV-SNP initialization"
class="mx-auto w-full rounded-lg shadow-lg bg-white p-2"
style="background-color: white; filter: none; mix-blend-mode: normal; color-scheme: only light;" />
</div>
<article class="text-justify text-lg leading-relaxed text-gray-900 space-y-6 py-5">
<p>
Figure (a) shows the main components of our attack with x86 cores and caches connected to the DRAM over
an interconnect. During SEV-SNP init, as shown in (b), a malicious hypervisor creates dirty cachelines
pointing to RMP memory.
Then it lets the PSP setup the RMP per usual and waits for the acknowledgement that the initialization
is complete. In particular, after writing to the RMP range the PSP notifies the platform to switch from
the TMR protection mechanism and start enforcing SEV-SNP semantics. Concretely, this means that the TMR
access checks are lifted and the core starts enforcing RMP checks on memory accesses. However, these RMP
checks occur before the memory write gets written to cache. Thus, all data within the cache is assumed
to be valid and already complies with the current security semantics. This leaves us with a time window
during RMP initialization, where the x86 cores can flush the previously created dirty cacheline entries.
They are neither subject to access control checks based on the TMR nor the RMP, thus bypassing both
protection mechanisms. As depicted in (c), the malicious hypervisor can use the primitive to get
arbitrary unchecked writes to RMP memory.
</p>
</article>
</section>
<section id="abstract" class="max-w-3xl mx-auto py-4 px-6">
<h1 class="text-3xl font-bold mb-6 text-center">
Attack Complexity
</h1>
<article class="text-justify text-lg leading-relaxed text-gray-900 space-y-6">
<p>
We perform the above RMP corruption during the SEV initialization. RMPocalypse is deterministic since
our malicious write always goes through. Next, with our choice of corrupting the root RMP entry with
this write, we can tamper with all RMP entries in the system and the logic state they belong to. Our
paper explains the detailed analysis of the RMP states. But in short, the RMP write-protects a critical
metadata page for CVMs. This page holds security sensitive information, such as debug-enable bit and the
attestation hash. With the RMP checks practically disabled, we show how to corrupt these metadata pages
to enable debug mode and bypass attestation. With each of these primitives, we can arbitrarily tamper
with the execution of the confidential VMs and exfiltrate all secrets with 100% success rate.
</p>
</article>
</section>
<!-- Paper Link -->
<section class="bg-gray-100 py-16 px-6">
<div class="max-w-3xl mx-auto text-center">
<h2 class="text-3xl font-bold mb-4">Further Information</h2>
<p class="mb-6">Read the full academic paper for implementation details.</p>
<div class="flex flex-col sm:flex-row justify-center gap-4 max-w-2xl mx-auto">
<a href="rmpocalypse-CCS2025.pdf" target="_blank" rel="noopener noreferrer"
class="flex-1 bg-black text-white text-center px-6 py-3 rounded-full font-semibold">
Read the Paper
</a>
<a href="citation.html" target="_blank" rel="noopener noreferrer"
class="flex-1 bg-black text-white text-center px-6 py-3 rounded-full font-semibold">
View Citation
</a>
<a href="https://github.com/rmpocalypse" target="_blank" rel="noopener noreferrer"
class="flex-1 bg-black text-white text-center px-6 py-3 rounded-full font-semibold">
View Code
</a>
</div>
</section>
<section id="faq" class="bg-white py-16 px-6">
<div class="max-w-3xl mx-auto text-left text-gray-900 space-y-6">
<h2 class="text-3xl font-bold mb-6">FAQ</h2>
<!-- FAQ Items -->
<div class="space-y-4" id="faq-container">
<!-- Each item gets rendered below -->
</div>
</div>
</section>
<section id="abstract" class="max-w-3xl mx-auto py-16 px-6">
<h1 class="text-3xl font-bold mb-6 text-center text-gray-800">
Media Coverage
</h1>
<ul class="list-disc space-y-4 pl-6">
<li class="text-lg text-gray-700">
<a>ETH News Article (en):</a>
<a href="https://ethz.ch/en/news-and-events/eth-news/news/2025/10/eth-researchers-uncover-vulnerability-in-confidential-cloud-environments.html"
class="text-blue-600 hover:underline hover:text-blue-800 transition-colors">
ETH researchers uncover vulnerability in confidential cloud environments
</a>
</li>
<li class="text-lg text-gray-700">
<a>ETH News Article (de):</a>
<a href="https://ethz.ch/de/news-und-veranstaltungen/eth-news/news/2025/10/eth-forschende-entdecken-sicherheitslueck-in-vertraulichen-cloud-bereichen.html"
class="text-blue-600 hover:underline hover:text-blue-800 transition-colors">
ETH-Forschende entdecken Sicherheitslücke in vertraulichen Cloud-Bereichen
</a>
</li>
<li class="text-lg text-gray-700">
<a>The Hacker News (en):</a>
<a href="https://thehackernews.com/2025/10/rmpocalypse-single-8-byte-write.html"
class="text-blue-600 hover:underline hover:text-blue-800 transition-colors">
RMPocalypse: Single 8-Byte Write Shatters AMD's SEV-SNP Confidential Computing
</a>
</li>
<li class="text-lg text-gray-700">
<a>Cyber Security News (en):</a>
<a href="https://cybersecuritynews.com/new-rmpocalypse-attack/"
class="text-blue-600 hover:underline hover:text-blue-800 transition-colors">
New RMPocalypse Attack Let Hackers Break AMD SEV-SNP To Exfiltrate Confidential Data
</a>
</li>
<li class="text-lg text-gray-700">
<a>SecurityWeek (en):</a>
<a href="https://www.securityweek.com/rmpocalypse-new-attack-breaks-amd-confidential-computing/"
class="text-blue-600 hover:underline hover:text-blue-800 transition-colors">
RMPocalypse: New Attack Breaks AMD Confidential Computing
</a>
</li>
<li class="text-lg text-gray-700">
<a>DataBreach Today (en):</a>
<a href="https://www.databreachtoday.com/confidential-virtual-machine-flaw-amd-patch-push-underway-a-29721"
class="text-blue-600 hover:underline hover:text-blue-800 transition-colors">
Confidential Virtual Machine Flaw: AMD Patch Push Underway
</a>
</li>
</ul>
</section>
<script>
const faqs = [
{
q: "Which AMD processors are affected?",
a: "All AMD Zen processors supporting SEV-SNP. Namely Zen 3, Zen 4 and Zen 5."
},
{
q: "Does RMPocalypse affect non-confidential VMs that I have in the cloud?",
a: "No, RMPocalypse does not affect non-confidential VMs."
},
{
q: "Is there a CVE?",
a: "Yes, CVE-2025-0033."
},
{
q: "What was AMDs response?",
a: "AMDs response is available here <a href='https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3020.html' target='_blank' class='text-blue-600 underline'>AMD Security Bulletin</a>."
},
{
q: "Is there a patch available?",
a: "Yes, AMD released firmware updates to mitigate the issue. Refer to AMDs Security Bulletin for more information.",
},
{
q: "Does this attack require physical access?",
a: "No, RMPocalypse does not require physical access and can be exploited remotely.",
},
{
q: "How difficult is it to exploit?",
a: "RMPocalypse is easy to exploit without the need of any heuristics, single-stepping, or side-channel information. In other words, we achieve a 100% success probability.",
},
{
q: "What is the root-cause?",
a: "The root cause of RMPocalypse lies with misaligned memory protection mechanisms during the bootstrapping of SEV-SNP."
},
{
q: "Does this attack also impact other confidential computing platforms such as Intel SGX, Intel TDX, Arm CCA?",
a: "No, RMPocalypse exploits unique aspects of SEV-SNP. Other technologies such as Intel TDX or ARM CCA are not affected as per our analysis."
},
{
q: "Can I use the logo?",
a: "Sure, the logo is free to use."
},
];
const container = document.getElementById("faq-container");
faqs.forEach((item, i) => {
const wrapper = document.createElement("div");
wrapper.className = "border border-gray-200 rounded-lg";
wrapper.innerHTML = `
<button onclick="toggleFAQ(${i})"
class="w-full flex justify-between items-center px-4 py-3 text-left font-semibold text-lg focus:outline-none hover:bg-gray-50">
<span>${item.q}</span>
<span id="faq-icon-${i}" class="transition-transform duration-300 transform">▼</span>
</button>
<div id="faq-answer-${i}" class="px-4 pb-4 text-base text-gray-700 hidden transition-all duration-300">
${item.a}
</div>
`;
container.appendChild(wrapper);
});
function toggleFAQ(index) {
const answer = document.getElementById(`faq-answer-${index}`);
const icon = document.getElementById(`faq-icon-${index}`);
const isOpen = !answer.classList.contains('hidden');
// Close all first (optional)
// document.querySelectorAll('[id^="faq-answer-"]').forEach(el => el.classList.add('hidden'));
// document.querySelectorAll('[id^="faq-icon-"]').forEach(el => el.classList.remove('rotate-180'));
answer.classList.toggle('hidden');
icon.classList.toggle('rotate-180');
}
</script>
<!-- Authors -->
<section class="bg-gray-100 py-16 px-6">
<div class="max-w-4xl mx-auto flex flex-col md:flex-row items-stretch gap-8">
<!-- Author List -->
<div class="flex-1 flex flex-col justify-center">
<h2 class="text-3xl font-bold mb-4 text-center md:text-left">Authors</h2>
<ul class="list-disc space-y-4 text-lg">
<li><a href="https://benschlueter.com/" target="_blank" class="text-blue-600 underline">Benedict
Schlüter</a></li>
<li><a href="https://www.shwetashinde.org/" target="_blank" class="text-blue-600 underline">Shweta
Shinde</a></li>
</ul>
</div>
<!-- Group Logo -->
<div class="flex-1 flex justify-center items-center">
<img src="sectrs.png" alt="Group Logo"
class="transform scale-50 h-full scale-50 w-auto object-contain" />
</div>
</div>
</section>
<!-- Footer -->
<footer class="text-center py-8 bg-black text-white">
<span style="float:left;"> <a href="imprint.html">Imprint</a></span>
<p>© 2025 Sectrs Group @ETH Zurich. All rights reserved.</p>
<p>Contact: <a href="mailto:benedict.schlueter@inf.ethz.ch" class="underline">benedict.schlueter@inf.ethz.ch</a>
</p>
</footer>
</body>
</html>