Preface: AMD EPYC processors are extensively used for High-Performance Computing (HPC) clusters, powering some of the world’s most advanced supercomputers. They are specifically engineered to handle compute-intensive tasks such as scientific simulations, weather forecasting, and complex molecular modelling.

Background: AMD Infinity Guard is a suite of security features built directly into the silicon of the AMD EPYC processor. While it interacts with and protects firmware, its foundation is hardware-based. When AMD Infinity Guard forms Secure Encrypted Virtualization (SEV), the encryption keys are not stored on an external hard disk or in standard bare-metal memory. Instead, they are kept entirely within the processor’s hardware. The actual data belonging to your virtual machine is stored in the system’s “bare-metal” RAM (DRAM), but it is fully encrypted.

In a traditional setup, the hypervisor has “God mode”—it can see everything. With AMD SEV-SNP, the hardware creates a Trusted Execution Environment (TEE) where the hypervisor is demoted to a simple “data mover” that is cryptographically blocked from the VM’s secrets.

Ref: CounterSEVeillance is a novel side-channel attack that targets AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging), a technology designed to protect confidential virtual machines (VMs) from a malicious hypervisor. Unlike previous attacks that might manipulate the VM’s state, CounterSEVeillance is primarily a passive side-channel attack, making it difficult to detect. 

Official article details

Summary: Researchers from Universities of Durham and of Luebeck have reported a way for a malicious hypervisor to monitor performance counters and potentially recover data from a guest VM. 

Affected Products and Mitigation: Performance counters are not protected by Secure Encrypted Virtualization (SEV, SEV-ES, or SEV-SNP).  AMD has defined support for performance counter virtualization in APM Vol 2, section 15.39. Performance Monitoring Counters (PMC) virtualization, available on AMD products starting with AMD EPYC™ 9005 Series Processors, is designed to protect performance counters from the type of monitoring described by the researchers.

For processors released prior to AMD EPYC™ 9005 Series Processors, AMD recommends software developers employ existing best practices, including avoiding secret-dependent data access or control flows where appropriate to help mitigate this potential vulnerability.

Official announcement: Please refer to the link for details –

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

Preface: AMD 7000 series (7-series) processors are extensively used to build High Performance Clusters (HPC). AMD provides 7-series solutions for both enterprise-grade and consumer/prosumer levels:

• AMD EPYC™ 7002 and 7003 Series: These server-grade processors (codenamed “Rome” and “Milan”) are specifically designed for commercial and scientific HPC. They offer up to 64 cores per socket, high memory bandwidth (8 channels), and extensive PCIe Gen4 lanes to reduce data bottlenecks.
• AMD Ryzen™ 7000 Series: While typically consumer CPUs, they are often used for “personal HPC” or small-scale clusters due to their high clock speeds and performance-per-dollar for specialized parallel computing tasks.

Background: The “Readback CRC Bus” refers to the internal logic path or mechanism in FPGAs (especially AMD/Xilinx devices) used to perform readback cyclic redundancy checks.

This is not a physical external “bus,” but a key component of the configuration logic, primarily used to ensure the data integrity of the FPGA’s internal configuration memory. Its core functions.

Academic studies and AMD’s bulletin describe attacks where researchers collect near‑infrared photon emissions that escape from transistor switching events on the FPGA die.

This depends on silicon’s bandgap (~1.1 eV ⇒ transparent above ~1100 nm). Because of this:

• Visible light cannot pass through silicon.
• Near‑IR and SWIR (1.1–2.3 µm) passes through with relatively low attenuation.
• The plastic/epoxy package is often more opaque, so attacking from the backside of a thinned die is normal.

The reason backside emissions are detectable:

• switching transistors emit very weak photons,
• silicon becomes transparent above ~1100 nm,
• the backside offers a direct path to the active circuitry after thinning,
• the metallization layers on the front side block light.

This is the same principle used in IRIS inspection methods, which also rely on silicon’s IR transparency for imaging.

Technical Summary: By leveraging a physical optical side channel, an attacker could recover plaintext configuration data from encrypted bitstreams. AMD recommends maintaining good physical security practices and keeping  systems closed unless needed for maintenance and repairs by authorized personnel.

 Affected Products and Mitigation: The testing by the academics was done on AMD Xilinx 7 series FPGAs. This is a physical back side attack and is outside of the threat model for AMD 7-series FPGAs.

Official announcement: Please refer to the link for more details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-8022.html

Preface: The MI3xx series (specifically the AMD Instinct MI300 and MI350 series) is designed and manufactured by AMD. These chips are not traditional graphics cards for gaming; they are high-performance GPU accelerators specifically designed for Generative AI, large-scale AI training, and High-Performance Computing (HPC).

Background: In the AMD Instinct MI300A architecture, the cache is technically known as the MALL (Memory Attached Last Level) cache. While “MIG” is a term commonly associated with NVIDIA’s Multi-Instance GPU technology, the MI300A’s shared last-level cache is officially branded as the AMD Infinity Cache.

Is L3/Limited-Level Cache (LLC) shared across all cores?

• GPU L3/Infinity Cache (MALL)
• Shared across all clients (CPU & GPU).
• The MI300A features a massive 256 MB shared Last-Level Cache (LLC), often called the AMD Infinity Cache or MALL (Memory Attached Last Level).

This specific cache is located on the I/O Die (IOD) and sits beyond the coherence point, meaning it is accessible by both the 24 CPU cores and the 228 GPU Compute Units.

• The MI300A uses a truly shared last‑level cache (MALL).
• Shared caches always raise the theoretical possibility of side channels.
• But only if an attacker can cause and observe measurable eviction‑based interference.
• AMD claims their virtualization model prevents this for GPU workloads.

Ref: NVIDIA H100 GPUs with Multi-Instance GPU (MIG) enabled provide full hardware-level isolation, ensuring that each partitioned “GPU Instance” (GI) has its own dedicated high-bandwidth memory (HBM3), compute cores, and L2 cache. Each MIG instance has its own independent path through the memory system, including dedicated cross-switch ports, L2 cache groups, memory controllers, and DRAM address buses. Many cache-based side-channel attacks rely heavily on the time delays (latency differences) associated with accessing memory in the L2 (or L3/LLC) cache.

Security Focus: The researchers shared with AMD a report titled “Behind Bars: A Side-Channel Attack on NVIDIA H100 MIG Cache Partitioning Using Memory Barriers”.

Based on MI3XX GPU architectural analysis, AMD has determined that the Guest VM-initiated operations of kernel launch related memory operations only impact the local XCD partition spatially allocated to the Guest VM and do not result in any observable interference on any other Guest VM load operations. Therefore, AMD does not believe that the reported vulnerability exists within the MI3XX GPU designs.

Official announcement: Please refer to the link for more details –

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