Messages in this thread | | | Subject | Re: [PATCH v8 7/7] iommu/vt-d: Use bounce buffer for untrusted devices | From | Robin Murphy <> | Date | Fri, 30 Aug 2019 15:27:54 +0100 |
| |
On 30/08/2019 14:39, David Laight wrote: > From: Lu Baolu >> Sent: 30 August 2019 08:17 > >> The Intel VT-d hardware uses paging for DMA remapping. >> The minimum mapped window is a page size. The device >> drivers may map buffers not filling the whole IOMMU >> window. This allows the device to access to possibly >> unrelated memory and a malicious device could exploit >> this to perform DMA attacks. To address this, the >> Intel IOMMU driver will use bounce pages for those >> buffers which don't fill whole IOMMU pages. > > Won't this completely kill performance?
Yes it will.
Though hopefully by now we're all well aware that speed and security being inversely proportional is the universal truth of modern computing.
> I'd expect to see something for dma_alloc_coherent() (etc) > that tries to give the driver page sized buffers.
Coherent DMA already works in PAGE_SIZE units under the covers (at least in the DMA API implementations relevant here) - that's not an issue. The problem is streaming DMA, where we have to give the device access to, say, some pre-existing 64-byte data packet, from right in the middle of who knows what else. Since we do not necessarily have control over the who knows what else, the only universally-practical way to isolate the DMA data is to copy it away to some safe sanitised page which we *do* control, and make the actual DMA accesses target that.
> Either that or the driver could allocate page sized buffers > even though it only passes fragments of these buffers to > the dma functions (to avoid excessive cache invalidates).
Where, since we can't easily second-guess users' systems, "the driver" turns out to be every DMA-capable driver, every subsystem-level buffer manager, every userspace application which could possibly make use of some kind of zero-copy I/O call...
Compared to a single effectively-transparent implementation in a single place at the lowest level with a single switch for the user to turn it on or off depending on how security-critical their particular system is, I know which approach I'd rather review, maintain and rely on.
Robin.
> Since you have to trust the driver, why not actually trust it? > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) >
| |