> Using this kind of bounce-buffering offers some benefit on its own. Your editor, who has written device drivers in the past, would never have committed such an error, but it is not unheard of for driver bugs to result in a device performing DMA when the rest of the system thinks it should be idle. Having memory buffers seemingly randomly overwritten in unreproducible ways can (again, your editor relies on the word of others for this) result in corrupt data, painful debugging sessions, and excessive alcohol use. By separating the buffer used by the device from the buffer used by the kernel, restricted DMA can mitigate many of the more unpleasant effects of this sort of bug.
In case you're wondering how this is a security feature...
> Readers may be wondering, though, how the use of the swiotlb will protect the system against a malicious or compromised device; such devices may well ignore polite requests to restrict their DMA activities to the designated area, after all. The answer is that it will not protect systems from this type of attack — at least, not on its own.
...it isn't.
This is obviously useful otherwise nobody would be working on it, but I don't really understand what this is defending against. Is it just so that buggy drivers/hardware don't cause so much trouble?
Buggy drivers and device firmware do indeed cause a ton of trouble. This looks to me like it's reducing the attack surface in a very reasonable way. A driver written to this API is likely to be much more robust than one that deals with raw memory itself.
I mean, most data we have shows a linear relationship between more code and more bugs.
And it's just more to get wrong. Say a differing idea about buffer alignment that just happens to work without this abstraction, but isn't called out. Or a million other things.
Cribbing from the comments on the original article, this does still seem to depend on hardware support to be helpful, but doesn't require an IOMMU. Doing things like reducing the size of the PCIE controller's aperture into RAM, or using ARM's Secure/Nonsecure modes in a cute on way some chips can give you a simple base+bounds restriction for all DMA, that's still beneficial but not really a full MMU.
On existing hardware it is mostly useless from a security point of view, but if you design new hardware it is way simpler to have per device physical base+lenght limits than a full featured IOMMU. This is to be restricted to somehow light embedded devices though. For a generalist expensible computer it would not make sense.
> Is it just so that buggy drivers/hardware don't cause so much trouble?
Yes, it's intended to reduce the impact of buggy drivers. A driver itself could have a transient bug that corrupts kernel memory of some other subsystem. Or an attacker can trick a vulnerable driver into performing a DMA transaction to a sensitive area of memory.
Hardware hasn't historically been seen as a security boundary. A buggy driver has always been able to take over your computer and crash it by fiddling with the hardware.
Right, but the question is what are these extra memcpys getting you then other than using up your CPU just to bounce bytes around?
And the answer is that there exists hardware today that can help restrict DMA access to main RAM, but take the form of base+bounds primitives rather than a full MMU. This appears to be in support of that.
>"One way to address this problem is to place an I/O memory-management unit (IOMMU) between devices and memory. The kernel programs the IOMMU to allow access to a specific region of memory; the IOMMU then keeps devices from straying outside of that region."
Future To-Do: Find or create an open-hardware, open-source FPGA IOMMU...
(Also, such a device could be used to trap/log errant (out of range) device DMA requests...)
lol