3 ms·
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 mal
by jstanley 6y ago
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?
- monocasa 6y agoCribbing 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. https://lwn.net/ml/linux-kernel/d7043239-12cf-3636-4726-2e3b90917dc6@gmail.com/ https://lwn.net/ml/linux-kernel/d7043239-12cf-3636-4726-2e3b... So that paragraph from the article is at best extremely confusing.
- temac 6y agoOn 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.
- diegocg 6y agoHardware 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.
- monocasa 6y agoRight, 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.
- als0 6y ago> 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.
- ajross 6y agoBuggy 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. But yes: it's not hardware isolation.
- monocasa 6y agoI would think that adding an abstraction layer like this would increase the number of bugs, not reduce them.
- jcelerier 6y agoWhy ? More code doesn't mean more bugs at all
- monocasa 6y agoI 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.