Re: [PATCH v8 7/7] iommu/vt-d: Use bounce buffer for untrusted devices

Robin Murphy
2019-08-30T14:28:02Z

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)
>