lkml.org 
[lkml]   [2019]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v8 7/7] iommu/vt-d: Use bounce buffer for untrusted devices
From
Date
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)
>

\
 
 \ /
  Last update: 2019-08-30 16:29    [W:0.076 / U:1.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site