Thunderbolt, and the USB-C ports that carry it, support direct memory access, DMA for short. A DMA-capable device can read and write your computer's memory directly, without asking the operating system's permission each time, which is exactly why external GPUs and high-speed storage over Thunderbolt perform as well as they do. The CPU isn't a bottleneck in the middle of every transfer.
That's also the entire attack surface. A peripheral that can write to memory directly can, in principle, write to memory it has no business touching. And a peripheral that can read memory directly can read whatever is sitting there, including things like disk encryption keys that are held in RAM while the machine is unlocked or even while it's asleep.
Thunderclap, 2019
Researchers from the University of Cambridge, Rice University, and SRI International published Thunderclap in 2019, demonstrating that a malicious Thunderbolt peripheral, something as unassuming-looking as a charger or a dock, could read sensitive memory contents from a plugged-in machine within seconds, even on systems that had some DMA protections enabled but not configured strictly enough to stop it. The point wasn't a single unpatched bug. It was that the trust model for Thunderbolt peripherals assumed a level of good faith that a truly malicious device has no reason to honor.
Thunderspy, 2020
Björn Ruytenberg at Eindhoven University of Technology followed up in 2020 with Thunderspy, which went further: it could bypass Thunderbolt's security levels entirely, including on a locked or sleeping machine, by reprogramming the controller firmware to make an untrusted device appear as a device the user had already approved. Disk encryption didn't save the machine either, because the attack could extract keys held in memory rather than needing to break the encryption itself. The disclosure noted that the attack required physical access for as little as five minutes, with inexpensive hardware, and left no trace in the operating system's logs afterward.
Why disk encryption alone doesn't stop this
Full-disk encryption protects data at rest, when the machine is off and the key hasn't been loaded into memory yet. Once you unlock the machine, the key has to live in RAM to actually decrypt anything you're working on. A DMA attack targets that window, not the encrypted disk itself.
What Changed Since
Both disclosures pushed real fixes. Windows shipped Kernel DMA Protection, which routes Thunderbolt and USB-C devices through an IOMMU that restricts what memory a peripheral can actually reach, on hardware that supports it. Linux has equivalent IOMMU-based protections available, though historically not always enabled by default depending on distribution and kernel version. Apple's Thunderbolt implementation has included VT-d-based protections for years. The Thunderbolt 4 specification itself made DMA protection a mandatory requirement rather than an optional configuration, closing off the class of machines that shipped with the capability present but switched off.
| Layer | What it protects against |
|---|---|
| Full-disk encryption | Data at rest, machine powered off, key not yet in memory |
| Lock screen | Casual access through the OS's normal UI, not the hardware port |
| Kernel DMA Protection / IOMMU | What a connected peripheral can actually reach in memory |
| Thunderbolt 4 mandatory DMA protection | Whether the protection above is even optional on a given machine |
Not Every USB-C Port Carries This Risk Equally
Plain USB, the protocol most keyboards, mice, and flash drives speak even when the physical connector is USB-C, never granted DMA by design. The CPU mediates every transfer, which is slower but keeps a peripheral from touching memory it wasn't handed explicitly. The DMA exposure described above is specific to Thunderbolt and to USB4, the newer standard that folds Thunderbolt-style tunneling into the USB-C connector. The confusing part for most people is that Thunderbolt, USB4, and plain USB 3.x all now show up on the same identical-looking port, so there's no way to tell by looking at a laptop which protocol a given USB-C port actually speaks, or whether DMA is in play for a given accessory. Checking your machine's specification sheet for which ports are Thunderbolt or USB4-capable is the only reliable way to know where this risk actually applies.
What Still Depends on You
Firmware and OS mitigations close the general case. They don't change the fact that this class of attack requires physical access, which is the same category of risk covered in our piece on evil maid attacks: anyone with a few unsupervised minutes with your hardware has more options than the lock screen suggests. If your threat model includes that kind of physical access, whether from a border crossing, a hotel room, or a shared workspace, the practical steps are the same ones that apply to any physical-access risk: fully power off the machine rather than leaving it asleep, since sleep mode keeps encryption keys resident in memory in a way a full shutdown doesn't; disable unused Thunderbolt or USB-C ports in firmware settings when traveling with data you can't afford to lose; and confirm Kernel DMA Protection or your OS's equivalent is actually enabled rather than assuming it is by default.
External GPUs and Docks Aren't the Enemy
None of this is an argument against Thunderbolt itself, which is a genuinely useful standard for anyone running an external GPU, a high-bandwidth dock, or fast external storage. The point of walking through Thunderclap and Thunderspy in detail isn't to make the port sound cursed. It's that the security model for a long time rested on an assumption, that a device physically plugged in deserves broad memory access by default, which turned out not to hold once researchers built a device specifically designed to violate it. The fix wasn't to remove DMA, since removing it would undo the performance benefit the whole standard exists for. The fix was to put a narrower gate, the IOMMU, between the peripheral and memory it has no legitimate reason to touch.
Related reading: our coverage of cold boot attacks and RAM forensics covers a different way memory contents can be extracted after the fact, and our rundown of BadUSB attacks covers the older, protocol-level version of "the port trusts the device more than it should."
Originally published at havenmessenger.com
