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

Preface: The vulnerability described in AMD-SB-7038 is based on a general microarchitectural behavior: memory reordering and out-of-order execution. These techniques are used by all major CPU vendors (Intel, ARM, etc.) to improve performance.

Background: The bulletin describes a research paper titled “MEMORY DISORDER: Memory Re-orderings as a Timerless Side-channel.”

Key points from AMD’s disclosure:

Nature of the issue:
Researchers demonstrated that memory re-orderings in CPUs and GPUs can be exploited as a timerless side-channel attack.
This means attackers can infer activity in other processes by observing subtle memory ordering patterns—without using timing measurements.

Impact:

• Potential for covert channels (secret communication between processes).
• Possible application fingerprinting (detecting what app is running).
• No direct data corruption or privilege escalation, but information leakage risk.

Scope:

• Applies to mainstream processors, including AMD CPUs and GPUs.
• It’s informational, not an emergency patch scenario. AMD classifies it as low severity because exploitation requires local access and advanced techniques.

Vulnerability details: Please refer to the link for details –

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

AMD-SB-7038 is about information leakage via subtle ordering patterns, not about allowing other processes to access memory during waits.

The vulnerability is about memory reordering being observable as a side-channel, not about direct memory access.

Remark: The attacker doesn’t need precise timing; they can infer ordering by observing cache state or contention.

In conclusion, this is a problem common to the entire industry, not unique to AMD. It is not due to any unique defects in its hardware.

Published: 2025-10-24

Preface: The Australian government has utilized Bouncy Castle cryptography APIs. Specifically, the Australian Government’s AUSKey project, which was a system for securely accessing government online services, used the Bouncy Castle libraries as its basis for Java cryptography.

Bouncy Castle is a widely-used open-source cryptographic API available for Java and C#, developed and maintained by the Legion of the Bouncy Castle Inc., a registered Australian charitable organization. It is known for its FIPS-certified modules, which meet a recognized government standard for cryptographic modules.

Background: The objective of the Bouncy Castle cryptography project is to provide a comprehensive set of open-source APIs for Java and C# that implement cryptographic algorithms and protocols to build secure applications. It aims to offer a wide range of security features, including those for public key infrastructure, digital signatures, authentication, secure communication, and FIPS-certified cryptographic modules for applications requiring a high level of compliance. 

While the javax.crypto.Cipher class and the JCA/JCE frameworks provide the core for cryptographic operations in Java, the Bouncy Castle cryptography library is often needed for below reasons: 

Extended Algorithm Support: Bouncy Castle offers a broader range of cryptographic algorithms and modes compared to the default JCE providers, including advanced algorithms like elliptic curve cryptography (ECC) which may not be fully or natively supported by the standard JCE.

Implementation of Emerging Standards: Bouncy Castle frequently incorporates implementations of newer cryptographic standards and protocols before they are fully integrated into the standard JCE, allowing developers to utilize cutting-edge security features.

CVE details: Further issues have shown up in high-core environments with Java 21 and BC-FJA 2.1.1. It appears under very high loads the scheduling of the disposal thread is such that it only gets called rarely, or at least not soon enough. The issue has been fixed by introducing the use of reachability-fencing. This available in Java 9 and later, so Java 8 is still using the disposal daemon as before has been changed to reduce friction (synchronized has been introduced where some friction is still required). A new property has also been added “org.bouncycastle.native.cleanup_priority” which can be set to “min”, “normal”, or “high” (default “min”) in case disposal thread scheduling will be beneficial for Java 8 as well.

Official announcement: Please see the link for details –

https://www.tenable.com/cve/CVE-2025-12194

https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902025%E2%80%9012194