DDRop Breaks Intel TDX With a $159 Board: What It Actually Changes If You Rent Confidential GPUs

On 14 September 2026, researchers from KU Leuven, ETH Zurich, Durham University and Google published DDRop. It is the kind of result that makes a vendor in our position choose between two reflexes: stay quiet, or write the thing down before a customer does. We publish attestation evidence for a living, so this is the second option.

What DDRop actually does

The attacker needs two things: software control of the host, and a few minutes of physical access to insert a custom interposer board between the processor and a DDR5 module. The board works by forcing an error on the command bus and then cutting the wire the memory module uses to report that error, so the module silently discards the write and the processor is never told it failed. The root cause is that neither Intel TDX nor AMD SEV-SNP guarantees memory freshness: old encrypted data can be replayed as if it were current. Once fitted, the whole attack is driven from software.

Three results were demonstrated against TDX. Dropping writes during page table initialisation gave the researchers full control of a protected VM, able to map its memory onto any physical address. Dropping other writes let them read a victim VM’s private memory and switch it into debug mode, which copies memory out in plaintext. And the one that matters most for anyone buying on attestation: they overwrote the launch measurement a VM uses to prove to a remote customer that it booted in a known, trusted state.

The nuance worth knowing, because it is the only place a provider configuration changes the answer: the first two only work in TDX’s default logical integrity mode, and the optional cryptographic integrity mode blocks them. The attestation forgery, the researchers argue, still works under the stronger mode, because that write happens inside the attacker’s own VM and under its own key. On AMD SEV-SNP the impact is narrower: dropping writes during page relocation let them copy one victim page into another, and the debug and attestation attacks are TDX-specific.

What the vendors said, and why it matters

Intel’s response is that physical interposer attacks of this kind fall outside the protection provided by its memory encryption, and that it does not plan to assign such attacks a CVE. It describes the research as out of scope, but not out of mind. AMD’s response is that the attack requires physical access and therefore falls outside the published threat model for SEV and SNP. Neither company has offered mitigation guidance or a timeline.

That is not evasion, it is the documented threat model, and it has been the documented threat model all along. The problem is that an entire marketing layer, ours included until this week, has been rounding “the hypervisor cannot read your memory” up to “nobody can, not even someone with physical access”. We had that exact sentence on this site. It came down the day we read the paper, along with nine other formulations of the same overclaim, and the architecture article now states the limit in the same breath as the guarantee.

What we measured inside our own VMs

The same day, we booted one of our Confidential VMs and looked at what a tenant can actually observe, because the interesting question after DDRop is whether you can tell which integrity mode your host runs. The short answer is no, and any provider who claims otherwise should be asked to name the host setting.

# Ce que l'invite peut reellement voir, mesure le 17/09/2026
# sur une de nos VM confidentielles (RTX PRO 6000 Blackwell, 3,80 $/h)

$ uname -r
6.8.0-110-generic

$ sudo dmesg | grep -iE "tdx|encryption"
[    0.000000] tdx: Guest detected
[   10.848643] Memory Encryption Features active: Intel TDX
[   32.003287] systemd[1]: Detected confidential virtualization tdx

# Le rapport TD, via l'interface noyau standard (configfs TSM)
$ ls /sys/kernel/config/tsm/report      # present, quote de 5247 octets

# Les attributs de la Trust Domain, extraits du quote v4
td_attributes  = 0x0000000010000000
  DEBUG = 0            <-- la TD n'est PAS en mode debug
  SEPT_VE_DISABLE = 1
tee_tcb_svn    = 05030400...

# Ce que l'invite ne peut PAS voir : le mode d'integrite memoire
# (logical vs cryptographic). C'est un reglage de la plateforme hote,
# il n'existe aucun champ pour ca dans le rapport TD.

So a tenant can confirm that TDX is active, that the Trust Domain is not in debug mode (which is what the second attack flips), and that the quote comes from the stock kernel interface rather than from something the provider wrote. A tenant cannot confirm the memory integrity mode. We have asked our infrastructure operator in writing and will publish the answer here when we have it, because an unverified “we run cryptographic integrity” from any provider, us included, is worth nothing.

The honest version of the pitch

Here is how we describe the boundary now, and we think every confidential cloud should describe it the same way. A TEE with tenant-side attestation removes four parties from your trust base: the hypervisor, the host operating system, the other tenants on the machine, and a remote attacker. You verify that removal yourself, against Intel and NVIDIA, on a nonce you chose, with an open-source verifier rather than our word. What remains in your trust base is the physical security of the building and the supply chain of the hardware. That is a small, nameable, auditable residue. It is not zero, and anyone telling you it is zero is selling.

Compare it with the alternative rather than with perfection. On a normal GPU cloud, your model and your data sit in plaintext in VRAM and any administrator with a console reads them: no interposer, no physical access, no research team from four universities. DDRop moves the cost of an attack on a confidential VM from “have credentials” to “have credentials and get inside the rack”. That is a large move, and it is the move you are paying for.

What it should change is your paperwork. If you are assembling a DPIA, an Article 32 file, or EU AI Act Article 15 evidence, describe the boundary as a software boundary, name the physical assumption explicitly, and do not quote a vendor sentence that claims physical attackers are covered. An auditor who finds that limit in your own file trusts the rest of it more. An auditor who finds it in a research paper after you told them otherwise trusts nothing.