arxiv: 2605.12990 · v1 · submitted 2026-05-13 · 💻 cs.CR

Recognition: unknown

Insecure Despite Proven Updated: Extracting the Root VCEK Seed on EPYC Milan via a Software-Only Attack

Muyan Shen , Yu Qin

Authors on Pith no claims yet

Pith reviewed 2026-05-14 18:24 UTC · model grok-4.3

classification 💻 cs.CR

keywords SEV-SNPVCEK seed extractionEPYC MilanAMD secure processorattestation report forgeryTCB rollbackfuse controllersoftware-only attack

0 comments

The pith

Software-only attack extracts the root VCEK seed on EPYC Milan, allowing forgery of any SEV-SNP attestation report.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper shows that AMD's SEV-SNP protection against TCB rollback attacks, which depends on signing attestation reports with a versioned key derived from the hardware root seed, fails on EPYC Milan processors. The authors achieve this by first running code on the secure processor through the MilanLaunchy exploit and then reading the root seed via the BadFuse attack that takes advantage of unrestricted write access to the fuse controller. If correct, this means an adversary can generate valid reports for any firmware version, breaking the core security guarantee of the architecture. Readers should care because it reveals that the hardware root seed is not adequately protected against software attacks on deployed hardware.

Core claim

The authors present an end-to-end attack that extracts the hardware root seed from EPYC Milan via software only, enabling the creation of valid attestation reports for arbitrary firmware versions and thereby undermining the SEV-SNP security model.

What carries the argument

The MilanLaunchy attack for gaining code execution on the secure processor combined with the BadFuse attack that reads the hardware root seed by exploiting missing write restrictions in the fuse controller.

If this is right

Attackers gain the ability to forge attestation reports signed with the VCEK for any TCB version.
The claimed prevention of TCB rollback attacks in SEV-SNP is defeated on EPYC Milan.
Malicious code can impersonate trusted virtual machine configurations in attestation.
Existing deployments of SEV-SNP on Milan processors become vulnerable to this class of attack.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

Other AMD processors using similar secure processor and fuse designs may be susceptible to comparable extraction techniques.
Future hardware revisions should add access controls or encryption to the root seed storage.
Developers relying on SEV-SNP attestation should consider additional verification methods beyond the report signature.

Load-bearing premise

Once code execution is obtained on the secure processor, the fuse controller permits reading the hardware root seed without additional restrictions.

What would settle it

Executing the described attack on actual EPYC Milan hardware and verifying whether the extracted seed allows generation of accepted attestation reports for different firmware versions; successful extraction and forgery would support the claim while inability to extract or forge would refute it.

Figures

Figures reproduced from arXiv: 2605.12990 by Muyan Shen, Yu Qin.

**Figure 2.** Figure 2: A comparison of key derivation flows for CEK and [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

**Figure 3.** Figure 3: The specific cryptographic loading and decryption [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

**Figure 5.** Figure 5: The memory layout and PC trajectory within the [PITH_FULL_IMAGE:figures/full_fig_p007_5.png] view at source ↗

**Figure 6.** Figure 6: Secret fuse access permissions for the off-chip boot [PITH_FULL_IMAGE:figures/full_fig_p009_6.png] view at source ↗

read the original abstract

In the official whitepaper of Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP), AMD explicitly emphasizes the capability to prevent Trusted Computing Base (TCB) rollback attacks. Cryptographically, this is realized by signing attestation reports with the Versioned Chip Endorsement Key (VCEK), which is derived by incorporating the TCB version into the hardware root seed. In this architecture, safeguarding the hardware root seed is the ultimate line of defense. However, our research reveals that this protection is insufficient on EPYC Milan by presenting a software-only exploit. Specifically, we firstly introduce MilanLaunchy attack, an exploit that achieves code execution on the AMD secure processor. Building on this foundation, we develop the BadFuse attack, which extracts the hardware root seed by exploiting a lack of write restrictions in the fuse controller. This end-to-end attack chain enables an adversary to forge valid attestation reports for any firmware version, thereby effectively undermining the security model of SEV-SNP.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

The paper presents a software-only attack to extract the VCEK root seed on EPYC Milan, but the details needed to verify the extraction step are missing from the abstract.

read the letter

The main point is that the authors claim a complete software-only attack to extract the root VCEK seed from EPYC Milan chips. If it works, it lets an attacker forge valid SEV-SNP attestation reports no matter what the firmware version is. The new part is the two named components: MilanLaunchy gets code execution on the AMD secure processor, and BadFuse then reads the hardware root seed by taking advantage of missing write restrictions in the fuse controller. This directly challenges AMD's statement in the SEV-SNP whitepaper that the root seed protects against TCB rollback. The paper does well by spelling out the attack chain in the abstract and linking it to real attestation forgery, which makes the practical consequence easy to see. The soft spots are in the verification. The abstract names the steps but does not include code snippets, test setups, or confirmation that the extraction actually succeeded on real hardware. The stress-test note correctly flags that the fuse controller might have extra protections that survive even after code execution on the secure processor. Without seeing those details in the full manuscript, it is hard to judge whether the central claim holds or if the attack stops at code execution. This work is aimed at people who study or deploy confidential computing on AMD platforms. Anyone tracking SEV-SNP security research would find the specific attack names and the rollback angle useful to follow up on. I recommend sending it to peer review. The topic is timely and the claimed result is important enough to warrant referee scrutiny, even if the current write-up needs more evidence on the BadFuse step.

Referee Report

2 major / 2 minor

Summary. The paper claims to demonstrate a software-only attack on AMD EPYC Milan processors running SEV-SNP. The attack consists of two parts: MilanLaunchy, which achieves code execution on the secure processor, and BadFuse, which extracts the hardware root seed from the fuse controller due to missing write restrictions. This allows an attacker to derive VCEK for any firmware version and forge attestation reports, bypassing the TCB rollback protection.

Significance. If the attack holds, it is significant because it shows that the root seed protection in SEV-SNP on Milan is insufficient against software attacks on the secure processor. This would mean the versioned attestation mechanism can be undermined, allowing rollback to vulnerable firmware versions. The work provides an empirical demonstration that could inform hardware design improvements, though the current presentation leaves key verification steps unclear.

major comments (2)

[§4] §4 (BadFuse attack): the extraction of the hardware root seed is asserted to succeed due to lack of write restrictions in the fuse controller, but no register-level access sequences, observed responses, or confirmation that secure-processor privileges bypass any remaining hardware protections are supplied; this is load-bearing for the forgery claim.
[§3–§4] §3–§4 transition: MilanLaunchy code execution is described, yet the manuscript does not demonstrate that the resulting privilege level is sufficient to read the root seed when the fuse controller may still enforce additional access controls or fuse-based locks.

minor comments (2)

[Abstract] Abstract: the title phrase 'Proven Updated' is not explained in the text; clarify whether it refers to a specific AMD update or is rhetorical.
[§4] The manuscript would benefit from a table listing the exact fuse controller registers accessed by BadFuse and their observed values on Milan hardware.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their insightful comments on our paper. We address each major comment below and have made revisions to incorporate additional technical details as suggested.

read point-by-point responses

Referee: [§4] §4 (BadFuse attack): the extraction of the hardware root seed is asserted to succeed due to lack of write restrictions in the fuse controller, but no register-level access sequences, observed responses, or confirmation that secure-processor privileges bypass any remaining hardware protections are supplied; this is load-bearing for the forgery claim.

Authors: We agree that the manuscript would benefit from more detailed evidence in §4. In the revised version, we will include the specific register-level access sequences used in the BadFuse attack, along with the observed responses from the fuse controller that demonstrate the absence of write restrictions. Additionally, we will provide confirmation through experimental results showing that the privileges obtained via MilanLaunchy allow direct access bypassing any hardware protections. This will strengthen the support for the forgery claim. revision: yes
Referee: [§3–§4] §3–§4 transition: MilanLaunchy code execution is described, yet the manuscript does not demonstrate that the resulting privilege level is sufficient to read the root seed when the fuse controller may still enforce additional access controls or fuse-based locks.

Authors: The MilanLaunchy attack results in code execution with full secure processor privileges, which we will demonstrate more explicitly in the revised manuscript. We will add a detailed explanation of the privilege level achieved and include evidence, such as successful direct reads from the fuse controller registers, confirming that no additional access controls or locks prevent extraction of the root seed. This will clarify the transition from §3 to §4. revision: yes

Circularity Check

0 steps flagged

No circularity: empirical attack demonstration with no derivation chain

full rationale

The paper describes a practical, end-to-end software-only attack (MilanLaunchy for code execution on the secure processor, followed by BadFuse for root seed extraction via fuse controller behavior). No equations, first-principles derivations, predictions, or fitted parameters are present that could reduce to self-definitional inputs or self-citations by construction. The security claims rest on observed hardware behavior and exploit steps that are externally falsifiable through reproduction on target hardware, not on any tautological renaming or load-bearing self-reference. This is a standard empirical security result with no circularity in its justification.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

The central claim rests on the existence of exploitable code-execution and fuse-controller weaknesses in the Milan secure processor; no free parameters, axioms, or invented entities are introduced beyond standard hardware attack assumptions.

pith-pipeline@v0.9.0 · 5473 in / 982 out tokens · 26561 ms · 2026-05-14T18:24:10.240032+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

56 extracted references · 1 canonical work pages

[1]

Advanced Micro Devices

Inc. Advanced Micro Devices. Amd secure encrypted virtualization api version 0.24, 2020

2020
[2]

Using SEV with AMD EPYC Processors, 2023

Advanced Micro Devices, Inc. Using SEV with AMD EPYC Processors, 2023. https://www.amd.com/co ntent/dam/amd/en/documents/epyc-technical -docs/tuning-guides/58207-using-sev-with-a md-epyc-processors.pdf

2023
[3]

SEV Secure Nested Paging - Firmware ABI Specification Revision 1.58,

Advanced Micro Devices, Inc. SEV Secure Nested Paging - Firmware ABI Specification Revision 1.58,
[4]

https://www.amd.com/content/dam/amd/en /documents/epyc-technical-docs/specificat ions/56860.pdf
[5]

Versioned Chip Endorse- ment Key (VCEK) Certificate and KDS Interface Spec- ification, 2025

Advanced Micro Devices, Inc. Versioned Chip Endorse- ment Key (VCEK) Certificate and KDS Interface Spec- ification, 2025. https://www.amd.com/content/da m/amd/en/documents/epyc-technical-docs/sp ecifications/57230.pdf. 11

2025
[6]

Amd server vulnerabilities – november 2021,

AMD. Amd server vulnerabilities – november 2021,

2021
[7]

https://www.amd.com/en/resources/produ ct-security/bulletin/amd-sb-1021.html
[8]

Amd-aspfw, 2023

AMD. Amd-aspfw, 2023. https://github.com/amd /AMD-ASPFW

2023
[9]

Amd server vulnerabilities – nov 2023, 2023

AMD. Amd server vulnerabilities – nov 2023, 2023. https://www.amd.com/en/resources/product-s ecurity/bulletin/amd-sb-3002.html

2023
[10]

Guest memory vulnerabilities, 2024

AMD. Guest memory vulnerabilities, 2024. https: //www.amd.com/en/resources/product-securit y/bulletin/amd-sb-3011.html

2024
[11]

Undermining integrity features of sev-snp with memory aliasing, 2024

AMD. Undermining integrity features of sev-snp with memory aliasing, 2024. https://www.amd.com/en /resources/product-security/bulletin/amd-s b-3015.html

2024
[12]

Amd server vulnerabilities – august 2025, 2025

AMD. Amd server vulnerabilities – august 2025, 2025. https://www.amd.com/en/resources/product-s ecurity/bulletin/amd-sb-3014.html

2025
[13]

Amd sev confidential computing vulnerability,

AMD. Amd sev confidential computing vulnerability,
[14]

https://www.amd.com/en/resources/produ ct-security/bulletin/amd-sb-3019.html
[15]

Amd secure encrypted virtualization (sev)

AMD. Amd secure encrypted virtualization (sev). http s://www.amd.com/en/developer/sev.html, 2026

2026
[16]

Milanlaunchy firmware loader, 2026

AMD. Milanlaunchy firmware loader, 2026. https: //www.amd.com/en/resources/product-securit y/bulletin/amd-sb-3045.html

2026
[17]

Arm confidential compute architecture (cca)

ARM. Arm confidential compute architecture (cca). https://www.arm.com/architecture/securit y-features/arm-confidential-compute-archi tecture, 6 2023

2023
[18]

Uncover, Understand, Own - Regaining Control Over Your AMD CPU

Robert Buhren, Alexander Eichner, and Christian Wer- ling. Uncover, Understand, Own - Regaining Control Over Your AMD CPU. https://media.ccc.de/v/3 6c3-10942-uncover_understand_own_-_regain ing_control_over_your_amd_cpu, 2019

2019
[19]

One glitch to rule them all: Fault injection attacks against amd’s secure encrypted virtualization

Robert Buhren, Hans-Niklas Jacob, Thilo Krachenfels, and Jean-Pierre Seifert. One glitch to rule them all: Fault injection attacks against amd’s secure encrypted virtualization. InProceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, pages 2875–2889, 2021

2021
[20]

Insecure until proven updated: analyzing amd sev’s remote attestation

Robert Buhren, Christian Werling, and Jean-Pierre Seifert. Insecure until proven updated: analyzing amd sev’s remote attestation. InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communi- cations Security, pages 1087–1099, 2019

2019
[21]

J Chuang, A Seto, N Berrios, S van Schaik, C Garman, and D Genkin. Tee. fail: Breaking trusted execution environments via ddr5 memory bus interposition. In 2026 IEEE Symposium on Security and Privacy (SP). Los Alamitos, CA, USA: IEEE Computer Society, pages 1894–1912, 2026

2026
[22]

Amd secure processor for confidential computing secu- rity review

Cfir Cohen, James Forshaw, Jann Horn, and Mark Brand. Amd secure processor for confidential computing secu- rity review. Technical report, Technical Report. Google Project Zero and Google Cloud Security, 2022

2022
[23]

Amd platform security processor (psp) firmware integration guide

Coreboot. Amd platform security processor (psp) firmware integration guide. https://doc.corebo ot.org/soc/amd/psp_integration.html, 6 2023

2023
[24]

Reversing the amd secure processor (psp)- part 1: Design and overview, 2023

dayzerosec. Reversing the amd secure processor (psp)- part 1: Design and overview, 2023. https://dayzer osec.com/blog/2023/04/17/reversing-the-amd -secure-processor-psp.html

2023
[25]

Reversing the amd secure processor (psp)- part 2: Cryptographic co-processor (ccp), 2023

dayzerosec. Reversing the amd secure processor (psp)- part 2: Cryptographic co-processor (ccp), 2023. https: //dayzerosec.com/blog/2023/04/22/reversing -the-amd-secure-processor-psp-part-2-crypt ographic-co-processor-ccp.html

2023
[26]

Battering ram: Low- cost interposer attacks on confidential computing via dynamic memory aliasing

Jesse De Meulemeester, David Oswald, Ingrid Ver- bauwhede, and Jo Van Bulck. Battering ram: Low- cost interposer attacks on confidential computing via dynamic memory aliasing. In47th IEEE Symposium on Security and Privacy (S&P), 2026

2026
[27]

Badram: Practical memory aliasing at- tacks on trusted execution environments

Jesse De Meulemeester, Luca Wilke, David Os- wald, Thomas Eisenbarth, Ingrid Verbauwhede, and Jo Van Bulck. Badram: Practical memory aliasing at- tacks on trusted execution environments. In46th IEEE Symposium on Security and Privacy. IEEE, 2024

2024
[28]

All your secrets belong to us: Leverag- ing firmware bugs to break tees

Tom Dohrmann. All your secrets belong to us: Leverag- ing firmware bugs to break tees. BlackHat USA, 2024

2024
[29]

Counterseveillance: Performance-counter attacks on amd sev-snp

Stefan Gast, Hannes Weissteiner, Robin Leander Schröder, and Daniel Gruss. Counterseveillance: Performance-counter attacks on amd sev-snp. InNet- work and Distributed System Security Symposium 2025: NDSS 2025, 2025

2025
[30]

Tcgtrusted platform ar- chitecturehardware requirements for a device identifier composition engine

Trusted Computing Group. Tcgtrusted platform ar- chitecturehardware requirements for a device identifier composition engine. https://www.trustedcomputi nggroup.org/wp-content/uploads/Device-Ide ntifier-Composition-Engine-Rev69_Public-R eview.pdf, 2021

2021
[31]

Security analysis of encrypted virtual machines.ACM SIGPLAN Notices, 52(7):129–142, 2017

Felicitas Hetzelt and Robert Buhren. Security analysis of encrypted virtual machines.ACM SIGPLAN Notices, 52(7):129–142, 2017. 12

2017
[32]

Intel® Trust Domain Extensions (Intel TDX)

Intel. Intel® Trust Domain Extensions (Intel TDX). https://www.intel.com/content/www/us/en/de veloper/articles/technical/intel-trust-dom ain-extensions.html, 2 2023

2023
[33]

faultpm: Exposing amd ftpms’ deepest secrets

Hans Niklas Jacob, Christian Werling, Robert Buhren, and Jean-Pierre Seifert. faultpm: Exposing amd ftpms’ deepest secrets. In2023 IEEE 8th European Symposium on Security and Privacy (EuroS&P), pages 1128–1142. IEEE, 2023

2023
[34]

Psb status

Michał Kope´c. Psb status. https://github.com/mko pec/psb_status, 2023

2023
[35]

Severe security advisory on amd processors

CTS Labs. Severe security advisory on amd processors. https://safefirmware.com/amdflaws_whitepap er.pdf, 2018

2018
[36]

A systematic look at ciphertext side channels on amd sev- snp

Mengyuan Li, Luca Wilke, Jan Wichelmann, Thomas Eisenbarth, Radu Teodorescu, and Yinqian Zhang. A systematic look at ciphertext side channels on amd sev- snp. In2022 IEEE Symposium on Security and Privacy (SP), pages 337–351. IEEE, 2022

2022
[37]

{CIPHERLEAKS}: Breaking constant-time cryptography on {AMD}{SEV} via the ciphertext side channel

Mengyuan Li, Yinqian Zhang, Huibo Wang, Kang Li, and Yueqiang Cheng. {CIPHERLEAKS}: Breaking constant-time cryptography on {AMD}{SEV} via the ciphertext side channel. In30th USENIX Security Sym- posium (USENIX Security 21), pages 717–732, 2021

2021
[38]

Sever- ity: Code injection attacks against encrypted virtual ma- chines

Mathias Morbitzer, Sergej Proskurin, Martin Radev, Marko Dorfhuber, and Erick Quintanar Salas. Sever- ity: Code injection attacks against encrypted virtual ma- chines. In2021 IEEE Security and Privacy Workshops (SPW), pages 444–455. IEEE, 2021

2021
[39]

Exploring amd platform secure boot

Krzysztof Okupski. Exploring amd platform secure boot. https://www.ioactive.com/exploring-amd -platform-secure-boot/, 2024

2024
[40]

PSPTool: Display, extract, and manipulate PSP firmware inside UEFI images

PSPTool Contributors. PSPTool: Display, extract, and manipulate PSP firmware inside UEFI images. https: //github.com/PSPReverse/PSPTool, 2025

2025
[41]

Rmpocalypse: How a catch-22 breaks amd sev-snp

Benedict Schlüter and Shweta Shinde. Rmpocalypse: How a catch-22 breaks amd sev-snp. InProceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, pages 3840–3854, 2025

2025
[42]

Wesee: using malicious# vc inter- rupts to break amd sev-snp

Benedict Schlüter, Supraja Sridhara, Andrin Bertschi, and Shweta Shinde. Wesee: using malicious# vc inter- rupts to break amd sev-snp. In2024 IEEE Symposium on Security and Privacy (SP), pages 4220–4238. IEEE, 2024

2024
[43]

In 33rd USENIX Security Symposium (USENIX Security 24), pages 3459–3476, 2024

Benedict Schlüter, Supraja Sridhara, Mark Kuhne, An- drin Bertschi, and Shweta Shinde.{HECKLER}: Break- ing confidential {VMs} with malicious interrupts. In 33rd USENIX Security Symposium (USENIX Security 24), pages 3459–3476, 2024

2024
[44]

Heracles: Chosen plaintext attack on amd sev-snp

Benedict Schlüter, Christoph Wech, and Shweta Shinde. Heracles: Chosen plaintext attack on amd sev-snp. In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, pages 3810– 3824, 2025

2025
[45]

Fabricked: Misconfiguring infinity fabric to break amd sev-snp

Benedict Schlüter, Christoph Wech, and Shweta Shinde. Fabricked: Misconfiguring infinity fabric to break amd sev-snp. 2026

2026
[46]

Wiretap: Breaking server sgx via dram bus interposition

Alex Seto, Oytun Kuday Duran, Samy Amer, Jalen Chuang, Stephan van Schaik, Daniel Genkin, and Christina Garman. Wiretap: Breaking server sgx via dram bus interposition. InProceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, pages 708–722, 2025

2025
[47]

Strengthening vm isolation with in- tegrity protection and more.White Paper, January, 53(2020):1450–1465, 2020

AMD Sev-Snp. Strengthening vm isolation with in- tegrity protection and more.White Paper, January, 53(2020):1450–1465, 2020

2020
[48]

Coconut secure vm service module

Coconut SVSM. Coconut secure vm service module. https://github.com/coconut-svsm/svsm, 2026

2026
[49]

Badaml: Exploiting legacy firmware interfaces to compromise confidential virtual machines

Satoru Takekoshi, Manami Mori, Takaaki Fukai, and Takahiro Shinagawa. Badaml: Exploiting legacy firmware interfaces to compromise confidential virtual machines. InProceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, pages 4469–4483, 2025

2025
[50]

Pwrleak: Exploiting power reporting interface for side-channel attacks on amd sev

Wubing Wang, Mengyuan Li, Yinqian Zhang, and Zhiqiang Lin. Pwrleak: Exploiting power reporting interface for side-channel attacks on amd sev. InIn- ternational Conference on Detection of Intrusions and Malware, and Vulnerability Assessment, pages 46–66. Springer, 2023

2023
[51]

Sev-step: A single-stepping framework for amd-sev.arXiv preprint arXiv:2307.14757, 2023

Luca Wilke, Jan Wichelmann, Anja Rabich, and Thomas Eisenbarth. Sev-step: A single-stepping framework for amd-sev.arXiv preprint arXiv:2307.14757, 2023

work page arXiv 2023
[52]

{Relocate- V ote}: Using sparsity information to exploit ciphertext {Side-Channels}

Yuqin Yan, Wei Huang, Ilya Grishchenko, Gururaj Saileshwar, Aastha Mehta, and David Lie. {Relocate- V ote}: Using sparsity information to exploit ciphertext {Side-Channels}. In34th USENIX Security Symposium (USENIX Security 25), pages 5699–5717, 2025

2025
[53]

Ci- phersteal: Stealing input data from tee-shielded neural networks with ciphertext side channels

Yuanyuan Yuan, Zhibo Liu, Sen Deng, Yanzuo Chen, Shuai Wang, Yinqian Zhang, and Zhendong Su. Ci- phersteal: Stealing input data from tee-shielded neural networks with ciphertext side channels. In2025 IEEE Symposium on Security and Privacy (SP), pages 4136–
[54]

{CacheWarp}: Software-based fault injection using selective state reset

Ruiyi Zhang, Lukas Gerlach, Daniel Weber, Lorenz Hetterich, Youheng Lü, Andreas Kogler, and Michael Schwarz. {CacheWarp}: Software-based fault injection using selective state reset. In33rd USENIX Security Symposium (USENIX Security 24), pages 1135–1151, 2024

2024
[55]

Stackwarp: Breaking amd sev-snp integrity via deterministic stack-pointer manipulation through the cpu’s stack engine

Ruiyi Zhang, Tristan Hornetz, Daniel Weber, Fabian Thomas, and Michael Schwarz. Stackwarp: Breaking amd sev-snp integrity via deterministic stack-pointer manipulation through the cpu’s stack engine. 2026

2026
[56]

{VeriSMo}: A verified se- curity module for confidential {VMs}

Ziqiao Zhou, Weiteng Chen, Sishuai Gong, Chris Haw- blitzel, Weidong Cui, et al. {VeriSMo}: A verified se- curity module for confidential {VMs}. In18th USENIX Symposium on Operating Systems Design and Imple- mentation (OSDI 24), pages 599–614, 2024. 14 A Appendix Table 3: Metadata Header Fuse Bit-map Address Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0...

2024