https://dl.acm.org/doi/pdf/10.1145/3230543.3230560 "For 64B DMA Reads it drops by almost 70% and even for 256B DMAs the drop is still a significant 30%".
There is crack the PC open physical access and just connect a device to a readily available connection access. With the later the adversary doesn't even need physical access himself, he just needs an unwary victim.
Smartphones had been plagued by something as simple as a public charging station getting compromised when Android was configured to just grant access to the file system and debug interface without requiring user confirmation. Before that Windows stopped auto playing software because it was used to infect systems from compromised devices.
Wikipedia seems to state no OS has managed to do so (as of 2019). Thunderbolt had been around since 2011.
> Intel stopped using IOMMU support on CPUs for product segmentation by the time Thunderbolt 3 arrived
So it couldn't possibly be made secure before 2015 and still wont be secure until $UNIVERSE_HEATDEATHDATE .
You're wildly misunderstanding things. Up to 2015, it was possible to build a new PC that lacked the necessary hardware features, primarily by choosing one of Intel's enthusiast-oriented overclockable CPU models (which used to have the IOMMU disabled for product segmentation reasons). But it was still very much possible to get all the necessary hardware features by selecting the next slower speed grade of the same chip, or by buying almost any pre-built system equipped with Thunderbolt ports. And since then, it's been almost impossible to build a PC that lacks the necessary hardware security features, because pretty much the only Intel CPUs still in production that lack IOMMU capabilities are Atom parts which aren't socketed and probably aren't used in any Thunderbolt-capable machines.
> Wikipedia seems to state no OS has managed to do so (as of 2019). Thunderbolt had been around since 2011.
You should read more carefully, and preferably follow the link to the source paper. That paper points out how Mac OS X started using the IOMMU to protect against DMA attacks in 2012, Linux and FreeBSD likewise have such capabilities, Windows pretty much doesn't (no longer true).
The point of that paper cited on Wikipedia was to show that when operating systems poke holes in the IOMMU protection to allow certain devices to perform DMA, it's possible to open up a more exploitable hole than you might expect. In particular, data structures may need to be rearranged to align with the 4kB page protection granularity, or else information that should remain inaccessible to peripherals may be exposed alongside legitimate DMA payload. And it's also possible for a malicious device to spoof the device IDs of a trusted device type and be granted access by default, but that's a class of vulnerability that exists for plain old USB, too.
So as I originally stated, the IOMMU is the hardware feature needed to block DMA attacks. But it's only effective when used properly by the OS. That's not trivial—but also not impossible.
That doesn't seem obvious to me. Is there evidence it wasn't just binning?
Features like HyperThreading or IOMMU are integral to the design of functional units that aren't optional. Those features aren't implemented as separate physical regions of silicon that take up non-trivial space, so it's very unlikely that a defect could break HyperThreading without breaking the entire CPU core, or that a defect could break IOMMU functionality without breaking the entire PCIe root complex. Disabling features like this does not meaningfully change the fraction of dies that pass quality control.
The IOMMU in particular is probably not going to be affected by overclocking, because it's probably in the same clock domain as the rest of the PCIe IO stuff, and that clock domain doesn't usually get overclocked when the CPU or DRAM is overclocked. So there's no reason to expect IOMMU functionality to affect what CPU clock speed a given die can reach.
In a most rudimentary implementation, a device doing DMA is physically wired to the main memory in parallel with CPU. The device will set something like `data, addr, CS, WR = 0xCAFE, 0x1000, TRUE, TRUE` and send a clock pulse. Then when CPU comes back to check address `0x1000`, the data `0xCAFE` is magically “there”, so programs on CPU don’t have to waste cycles polling the device to get the value. Naturally, some arbitration is necessary because trying to change bus states from both sides will mess things up.
Above was probably the case until 1980s or 90s, and DMA in modern days instead goes through bus masters and memory controllers. Since it’s not going directly to physical RAM anymore, such controllers can be configured in such ways as to prevent unwanted accesses.
But it’s more of “can be used to protect against”, not “won’t be possible if done correctly”.
Go look up what IOMMU means. We're not talking about a feature inside an individual CPU core, but in the PCIe Root Complex that implements DMA capabilities in the first place; it's the thing that sits between peripheral devices and the DRAM controller. That functionality is on the CPU die these days.