Security Highlight: Why Confidential Compute Isn’t Easy – Breaking Down the BadRAM Vulnerability

Modern cloud environments depend on encryption to protect sensitive data, with full-disk and network encryption being standard practices. However, safeguarding data during computation remains a challenge. Confidential Computing, as defined by the Confidential Computing Consortium, protects data in use by performing computation in a hardware-based, attested Trusted Execution Environment (TEE). An essential aspect of this protection involves shielding memory from tampering, even by a malicious hypervisor. Recent research by Jesse De Meulemeester et al., titled BadRAM: Practical Memory Aliasing Attacks on Trusted Execution Environments (see https://badram.eu), reveals vulnerabilities in AMD’s TEE caused by manipulated DRAM modules. The study demonstrates how aliasing can compromise memory integrity, re-enabling previously mitigated attacks. In response, AMD has introduced firmware updates to detect aliasing during boot, as outlined in their security bulletin.

Trusted Execution Environments and Memory Protection

Trusted Execution Environments such as AMD SEV and Intel SGX are designed to minimize the Trusted Computing Base (TCB) by removing the hypervisor from the TCB. This approach ensures that even if the hypervisor is compromised, the integrity and confidentiality of virtual machines (VMs) or enclaves remain intact. These technologies depend on memory encryption to protect data written to DRAM and include integrity and replay protection mechanisms to detect unauthorized changes or reuse of encrypted memory. The TEE ensures the per-VM keys are only accessible when the VM executes.

However, as demonstrated in the 2018 publication SEVered: Subverting AMD's Virtual Machine Encryption by Mathias Morbitzer et al, a malicious hypervisor could bypass memory encryption. First, a malicious hypervisor profiles a server program inside a victim VM to identify where its communication buffers are located. The hypervisor then remaps pages it wants to decrypt in place of the communication buffers, and performs a request to the server program. It will then receive the communication buffer contents, which are the victim’s decrypted memory contents.

AMD’s SEV-SNP mitigates such attacks by introducing Secure Nested Paging (SNP), which defends against hypervisor-based attacks on page tables. The Reverse Map Table (RMP [sic]) in SEV-SNP ensures that page mappings remain consistent and cannot be manipulated maliciously, preventing attacks like SEVered.

The Mechanics of the BadRAM Attack

The BadRAM research uncovered a method to re-enable the SEVered attacks by manipulating the Serial Presence Detect (SPD) EEPROM found on DIMM memory modules. This EEPROM stores critical configuration data, such as information about the DRAM’s banks, rows, and size. The SPD can be reprogrammed, replaced, or emulated to misrepresent the actual size of the DRAM. In some cases, certain DIMM manufacturers allow software-based reprogramming of the SPD because there are no write locks on the EEPROM’s pages. During platform boot, the BIOS reads the SPD data and uses it to configure the system’s memory controller, including setting the DRAM size.

By doubling the reported memory size in the SPD, attackers can trick the memory controller into using an additional address bit. This extra bit is ignored by the physical DRAM, resulting in memory aliasing where each bit in the DRAM can be accessed through two distinct physical addresses. Although the aliasing relationship is not always straightforward due to non-cryptographic memory scrambling by the controller, the researchers demonstrated that it can be reverse-engineered using a relatively simple algorithm.

Once the two physical addresses for each aliased bit are identified, the researchers employed operating system configuration to prevent the system from attempting to use the entirety of the “doubled” memory. This ensures the system can boot normally while allowing access to each bit via two separate physical addresses.

Normally, SEV-SNP prevents malicious modifications of the RMP. Having access to all bits through the aliased address space enables attackers to directly manipulate the RMP. Using these aliased addresses, they can bypass RMP protections and reintroduce page remapping, effectively re-enabling the SEVered attacks. Furthermore, the researchers demonstrated that they could access the security processor’s private RAM, which, although encrypted, lacks replay protection. This access can be exploited to undermine VM attestation by swapping out a modified VM firmware hash with a valid one, tricking the attestation process. As a result, the integrity of remote attestation is compromised.

Mitigations and AMD’s Response

AMD has responded to these findings by introducing firmware updates that detect memory aliasing during boot. The researchers show this detection is effective by testing on Intel platforms. Intel’s Scalable SGX and TDX include boot-time alias checks, using the Alias Checking Trusted Module (ACTM) to detect and prevent memory aliasing. Because classic Intel SGX does not have boot-time alias checks, but does have cryptographic integrity and replay protections, there is a remaining weakness: an attacker that can cause aliasing can still observe ciphertext changes in DRAM. This is a side channel that can result in further attacks. The researchers also mention Arm’s Confidential Compute Architecture (CCA), which is not yet commercially available, but should adopt comparable alias detection mechanisms to avoid BadRAM vulnerability.

The Root of the Vulnerability

The root vulnerability exploited by BadRAM lies in untrusted data from the SPD being used by the BIOS to configure the memory controller. Both the SPD and BIOS serve as potential points of compromise. While some DIMMs allow permanent write locks on the SPD, others leave it writable, even from software. Additionally, attackers could spoof SPD data within the BIOS, bypassing the need for physical access. These weaknesses highlight the importance of validating memory configurations independently of untrusted components.

The Broader Implications of BadRAM

This vulnerability highlights the inherent complexity of designing a Trusted Execution Environment (TEE) within a processor that traditionally relies on fully trusted components, such as the BIOS, its firmware, and the hypervisor. Fortunately, BadRAM does not expose a fundamental architectural flaw in the TEE design but rather reveals an oversight in how untrusted components like the SPD are handled. This oversight is addressable through firmware patches and additional safeguards.

It is worth noting that micro-architectural side-channel or covert-channel attacks are not necessarily discovered by this. To address these, a significant effort is needed: all shared resources in the processor need to be identified, and properly cleared at runtime to avoid leakage.

Recommendations

To structurally address vulnerabilities such as BadRAM, there is a responsibility on both the vendor of software or hardware components that are part of the Trusted Computing Base, as well as certifiers or reviewers. The recommendation is the age-old: identify your attack surface, and verify that each input is non-malicious at runtime.

limit