Official Revision Date: 20-10-2025

Preface: A 3rd Gen AMD EPYC processor uses an integrated memory controller within its System on a Chip (SoC) to connect to DDR4 DRAM modules, rather than having a separate memory controller component. The memory controller is part of the I/O Die (IOD) which is connected to the Core Complex Dies (CCDs) via the Infinity Fabric. Each processor has up to eight memory channels, each capable of supporting up to two DIMM slots, for a maximum of 4TB of memory per socket.

Background: The secure memory area for the RMP (Reverse Map Table) on a 3rd Gen AMD EPYC processor is a protected region within the DDR4 DRAM modules themselves, managed by the processor’s security features. It is not located inside the SoC but is in a secure area of the system’s main RAM, making it part of the dedicated system memory rather than the processor’s on-chip memory.

In a 3rd Gen AMD EPYC processor, the secure memory area for the Reverse Map Table (RMP) is a protected region within the DDR4 DRAM modules themselves, not a separate “hidden area” on the SoC. The secure memory is managed by the processor’s security features, such as the AMD Secure Processor (ASP), to protect the RMP and prevent attacks that could manipulate it.

Vulnerability details: Researchers reported a cache-based side-channel that could allow an unprivileged user process on AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) systems to leak up to six bits of physical address information. The researchers also noted that this leakage does not have an immediate security impact.

AMD has determined that the leakage results from Reverse Map Table (RMP) entries being cached in the L1D and L2 caches. Given that at most six physical address bits are exposed, AMD concurs with the researchers that this leakage does not have an immediate security impact.

Ref: In the absence of an immediate fix from AMD, the only way to reduce the risk of cache-based side-channel attacks in SEV-SNP environments is to follow secure memory handling and system-level best practices.

Official announcement: Please see the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3036.html

Official Revision Date: 17-10-2025

Preface: SEV-SNP is a security technology for confidential computing that encrypts virtual machine memory. SEV-SNP protects memory contents and integrity, and its security model does not depend on the cache indexing method.

Background: While SEV-SNP provides strong memory encryption and integrity protections, it does not offer built-in hardware protections specifically for PIPT cachesagainst all forms of side-channel attacks. However, AMD has introduced optional mitigations and best practices to reduce exposure:

• SEV-SNP includes optional features to mitigate indirect branch predictor poisoning, which is a form of side-channel attack. This helps protect against speculative execution vulnerabilities like Spectre.
• SEV-ES and SEV-SNP encrypt CPU register states during VM exits, preventing leakage of sensitive data through register inspection.
• The Reverse Map Table (RMP) ensures that only the owner of a memory page can write to it. This prevents memory aliasing and replay attacks, which could otherwise be exploited via cache-based side channels.
• SEV-SNP uses Page Validation to ensure that guest pages map to only one physical memory page at a time, reducing the risk of inconsistent memory views that could be exploited.

Vulnerability details: Researchers have shared with AMD a paper titled “GhostFetch: Uncovering and Exploiting the Physical-Address-Indexed Prefetcher to Break AMD SEV-SNP” which describes a prefetcher-based hardware side channel attack.

In their paper the researchers describe a method of using shared prefetcher state to determine whether the virtual address of a load matches the expected address, or whether a load access pattern matches an expected stride.  Either check requires multiple runs but potentially results in loss of confidentiality if the targeted code has either a secret dependent branch or a load access pattern that is secret dependent.

AMD’s response:

AMD believes that the researchers have not identified any AMD prefetchers that have not already been disclosed in the Software Optimization Guide and did not identify any new security implications with AMD prefetchers.

Official announcement: Please see the link for details –

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7047.html