$159 of Hardware Breaks Confidential Computing: DDRop, Dropped DDR5 Writes, and Why Encryption Is Not Freshness

A small board sits between a server's CPU and one of its DDR5 memory modules. It behaves normally through boot, passes every integrity check the platform runs, and then, on command, starts throwing away writes. The memory encryption is still working. The attestation still verifies. The processor reads back data that is cryptographically valid, correctly authenticated, and several seconds out of date.

That is DDRop, presented by nine researchers from KU Leuven, ETH Zurich, Durham University and Google, published at CCS 2026 as DDRop: Active Memory Interposer Attacks on Confidential VMs by Dropping DDR5 Writes. Coordinated disclosure closed on 14 September 2026. The bill of materials is $159.

The interesting part is not the price. It is what the attack shows about the guarantee confidential computing actually sells you.

//Encryption Is Not Freshness

Intel TDX, Intel Scalable SGX and AMD SEV-SNP all encrypt memory. Some of them also authenticate it, so the CPU can tell that a cache line came back the way it was written and was not tampered with in transit.

Neither property answers a different question: is this the newest version of this cache line?

A ciphertext that was written ten seconds ago is still authentic. It decrypts. Its integrity check passes. It is a genuine value that the CPU itself produced, encrypted with the right key, for the right physical address. The only thing wrong with it is that it has been superseded, and nothing in the memory path records that fact. Recording it requires a version counter per cache line, kept somewhere the attacker cannot reach, and none of these platforms carry one on DDR5.

So if you can make a write disappear, the machine will happily read the previous value and have no way to know.

//How You Drop a Write in Hardware

The interposer is an analog switch board that sits in the RDIMM slot and passes the DDR5 signals through at native speed. No downclocking, no retraining tricks, no need to slow the bus into a range where cheap parts can keep up. The researchers say installation takes minutes.

The mechanism is parity. DDR5 command and address lines carry parity protection, and a DIMM that sees a parity error on an inbound command discards that command rather than acting on a possibly-corrupted address. That behaviour is a correctness feature. It exists so a glitched write never lands in the wrong place.

DDRop injects the error deliberately. The controller board, driven by a Teensy 4.1, watches for the target command and corrupts its parity, and the DIMM does exactly what the specification tells it to do: it throws the write away. The writeback never reaches the array. The next read returns whatever was there before.

The same primitive also lets the board swap chip selects, which is how the SEV-SNP case study gets its page-copying capability.

The bill of materials

At a ten-unit build quantity, per system: interposer PCB and stencil $45, interposer parts $30, controller PCB $4, controller parts $40, Teensy 4.1 $40. Total $159.

The repository ships the board files, the schematics, the Teensy firmware and the Python control scripts, plus separate attack directories for TDX, SGX and SEV-SNP, under an MIT licence. It also notes that without the physical boards you can still compile the software components and the attack binaries, which matters for anyone building detection rather than reproducing the attack.

//What It Actually Achieves

Three platforms, three different outcomes, all from the same write-dropping primitive.

Intel TDX. Injecting a malicious Secure Extended Page Table entry to reach victim ciphertext. Corrupting the TDCS structure to toggle a Trust Domain into debug mode, which succeeds with roughly 50% probability per attempt. Modifying MRTD measurements to spoof arbitrary attestation reports. That last one is the load-bearing failure: attestation is the mechanism by which a remote party decides whether to trust a confidential VM at all.

Intel Scalable SGX. Write suppression against Enclave Page Cache pages, demonstrated as a proof of concept.

AMD SEV-SNP. Plaintext page copying by abusing the page relocation API.

Across the case studies the paper reports a 100% success rate and deterministic behaviour. This is not a probabilistic side channel that needs thousands of trials to leak a key. When the board drops a command, it stays dropped.

Interleaving decides the blast radius

One interposer sits on one DIMM, and memory is interleaved across channels and subchannels, so a single board only covers part of any given page. On the Intel test system, with 16-way subchannel interleaving, roughly four cache lines per 4 KB page fall under the attacker's control. On the AMD system, with 2-way interleaving, about half the cache lines in a buffer are reachable.

That is a real constraint and it is also why the attacks are surgical rather than general. You do not get to rewrite a VM's memory. You get to pin four specific cache lines to their previous contents, which - if you have chosen the right four - is enough.

//The Detection That Falls Out For Free

This is the part most of the coverage skips, and it is the most useful thing in the paper for anyone who runs servers rather than attacks them.

Every dropped write raises a recoverable ECC error. The mechanism does not hide. Suppressing a writeback via a parity error leaves a correctable-error event behind, one per dropped command, on the memory controller.

Correctable ECC errors are normally ignored. They are common, they are benign in ones and twos, and most monitoring either does not collect them or alerts only on a threshold designed to catch a failing DIMM. An attack that generates them at a steady rate on one module, on a machine that is otherwise healthy, looks exactly like early DIMM degradation - until you notice it started the same week someone had physical access.

If you run confidential workloads on hardware you do not physically control, EDAC and machine-check counters per DIMM are cheap to collect and this is a concrete reason to collect them. It will not stop the attack. It removes the silence.

The other mitigations

The paper proposes several, and is honest that the software ones only raise the bar:

Timing the memory training sequence to detect the interposer's insertion delay, which the authors put at roughly 165 picoseconds one way. Runtime verification by writing known patterns into reserved DRAM and reading them back. Disabling memory-management APIs that are not needed, such as PAGE_SWAP_DISABLE on SEV-SNP, which removes the page relocation primitive the AMD attack depends on. Read-back verification after critical operations such as SEPT initialisation. Separate encryption keys for critical metadata structures, so corrupting TDCS is not the same problem as corrupting guest memory.

The real fix is architectural: cryptographic freshness alongside integrity. Intel has proposed cache line versioning for future platforms. The authors also point at authenticated encryption designs such as Ascon. None of that helps a server you have already bought.

//The Vendor Response, Read Plainly

Intel's announcement 2026-09-14-001 says the scenarios fall outside its standard threat model for confidential computing deployments, notes the attack is not remotely exploitable, and says it is evaluating additional architectural hardening and detection. No CVE.

AMD's AMD-SB-3048, same date, covers EPYC 4004, 4005, 8004, 9004 and 9005 and Instinct MI300A, and is blunter: the attack relies on a physical attack against the memory bus, which falls outside the published SEV-SNP threat model, and "AMD does not plan to assign a CVE or release mitigations in response to this report."

Both positions are defensible, and both are worth reading literally rather than as a brush-off. The threat model these technologies publish has always excluded an attacker with physical access to the motherboard. That is documented. The problem is not that the vendors changed their story; it is that the marketing around confidential computing is frequently read as your cloud provider cannot see inside your VM, and the threat model actually says your cloud provider's software cannot see inside your VM. Those are different sentences, and DDRop is what the gap between them looks like in hardware.

If your reason for using a confidential VM is regulatory or contractual - you need to be able to say the operator cannot read the data - then a documented, reproducible, $159 physical attack is directly relevant to that claim even if no vendor considers it a vulnerability. If your reason is defence against a compromised hypervisor, it changes very little.

//The Trajectory Is The Story

DDRop is the third in a line, from broadly the same research group:

BadRAM (December 2024, CVE-2024-21944), about $10 of hardware, spoofing SPD data to make a DIMM claim more capacity than it had and alias protected memory. Passive, and AMD issued firmware mitigations.

Battering RAM(IEEE S&P 2026), $47.62 in parts, an interposer that stays transparent through boot and every startup trust check, then flips to redirecting protected addresses. Arbitrary plaintext access on Scalable SGX, attestation broken on SEV-SNP.

DDRop (CCS 2026), $159, active command manipulation at native DDR5 speed, breaking freshness rather than address mapping.

Each step costs more and does more, and the repository for DDRop carries BadRAM as a submodule, which is a fair summary of how the work builds. The direction of travel matters more than any single result: the cost of a credible physical attack on confidential computing is measured in low hundreds of dollars and falling in capability-per-dollar, while the deployment model for these technologies assumes the hardware is somewhere you cannot reach.

//What To Take From This

If you buy confidential computing, read the threat model, not the datasheet. Physical access is excluded. Both vendors say so in writing. Decide whether that exclusion is compatible with the promise you are making to whoever is above you.

Collect per-DIMM correctable error counters. This attack is loud in a channel almost nobody watches. EDAC on Linux, machine-check banks, whatever your BMC exposes. Baseline them, alert on sustained anomalies against a single module.

Turn off memory-management features you do not use. PAGE_SWAP_DISABLE on SEV-SNP removes the primitive the AMD case study relies on. Attack surface you never enabled is the cheapest kind to remove.

Treat attestation as a claim about software, not about hardware. An attestation report signed on a machine with an interposer in it is a correctly signed report about a lie. That is not an implementation bug, it is the consequence of measuring memory that has no freshness guarantee.

//Sourcing and Uncertainty

Every technical figure above - the $159 bill of materials and its breakdown, the 165 ps delay estimate, the 50% success rate on TDCS debug-mode toggling, the interleaving figures, the 100% case study success rate, the list of attack outcomes per platform - comes from the DDRop paper and project site. The vendor positions and the quoted AMD sentence come from the two advisories, both dated 14 September 2026.

The BadRAM and Battering RAM figures come from those projects' own sites and coverage; BadRAM's CVE and AMD's firmware response are from the December 2024 disclosure.

The interpretation is mine: the reading of correctable ECC errors as a practical detection channel, the argument about the gap between how confidential computing is marketed and what its threat model says, and the framing of the three attacks as a cost trajectory. The paper notes the ECC side effect; positioning it as a monitoring recommendation is my inference, and it is untested here - I have no DDR5 server and no interposer, so I cannot tell you what the error rate looks like against a real baseline.

One thing I could not resolve: Intel's announcement does not name affected products, and discusses DDR5 RDIMM confidential computing deployments in general terms. AMD's bulletin does name specific families. Do not read Intel's silence as a narrower scope than the paper claims.