From: Lu Baolu <baolu.lu@linux.intel.com>
To: David Laight <David.Laight@ACULAB.COM>,
David Woodhouse <dwmw2@infradead.org>,
Joerg Roedel <joro@8bytes.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Christoph Hellwig <hch@lst.de>
Cc: Juergen Gross <jgross@suse.com>,
"kevin.tian@intel.com" <kevin.tian@intel.com>,
Stefano Stabellini <sstabellini@kernel.org>,
"ashok.raj@intel.com" <ashok.raj@intel.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
"alan.cox@intel.com" <alan.cox@intel.com>,
Jonathan Corbet <corbet@lwn.net>,
Robin Murphy <robin.murphy@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"pengfei.xu@intel.com" <pengfei.xu@intel.com>,
Ingo Molnar <mingo@redhat.com>,
"jacob.jun.pan@intel.com" <jacob.jun.pan@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
"mika.westerberg@linux.intel.com"
<mika.westerberg@linux.intel.com>
Subject: Re: [PATCH v8 7/7] iommu/vt-d: Use bounce buffer for untrusted devices
Date: Mon, 2 Sep 2019 15:15:35 +0800 [thread overview]
Message-ID: <90de3797-d961-a3e5-36c9-d8328a3faab0@linux.intel.com> (raw)
In-Reply-To: <4dee1bcef8474ebb95a7826a58bb72aa@AcuMS.aculab.com>
Hi David,
On 8/30/19 9:39 PM, 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?
>
> I'd expect to see something for dma_alloc_coherent() (etc)
> that tries to give the driver page sized buffers.
Bounce page won't be used if driver request page sized buffers.
>
> 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).
Yes, agreed. One possible solution is to add a dma attribution and the
device driver could hint that the buffer under mapping is part of a page
sized buffer and iommu driver don't need to use bounce buffer for it.
This is in the todo list. We need to figure out which device driver
really needs this.
>
> Since you have to trust the driver, why not actually trust it?
>
In thunderbolt case, we trust driver, but we don't trust the hot-added
devices.
Best regards,
Baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
prev parent reply other threads:[~2019-09-02 7:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-30 7:17 [PATCH v8 0/7] iommu: Bounce page for untrusted devices Lu Baolu
2019-08-30 7:17 ` [PATCH v8 1/7] PCI: Add dev_is_untrusted helper Lu Baolu
2019-08-30 7:17 ` [PATCH v8 2/7] swiotlb: Split size parameter to map/unmap APIs Lu Baolu
2019-08-30 7:17 ` [PATCH v8 3/7] swiotlb: Zero out bounce buffer for untrusted device Lu Baolu
2019-08-30 7:31 ` Christoph Hellwig
2019-09-02 1:58 ` Lu Baolu
2019-09-02 7:26 ` Christoph Hellwig
2019-08-30 7:17 ` [PATCH v8 4/7] iommu/vt-d: Check whether device requires bounce buffer Lu Baolu
2019-08-30 7:17 ` [PATCH v8 5/7] iommu/vt-d: Don't switch off swiotlb if bounce page is used Lu Baolu
2019-08-30 7:17 ` [PATCH v8 6/7] iommu/vt-d: Add trace events for device dma map/unmap Lu Baolu
2019-08-30 13:53 ` Steven Rostedt
2019-09-02 2:13 ` Lu Baolu
2019-08-30 7:17 ` [PATCH v8 7/7] iommu/vt-d: Use bounce buffer for untrusted devices Lu Baolu
2019-08-30 13:39 ` David Laight
2019-08-30 14:27 ` Robin Murphy
2019-09-02 7:15 ` Lu Baolu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=90de3797-d961-a3e5-36c9-d8328a3faab0@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=David.Laight@ACULAB.COM \
--cc=alan.cox@intel.com \
--cc=ashok.raj@intel.com \
--cc=bhelgaas@google.com \
--cc=boris.ostrovsky@oracle.com \
--cc=corbet@lwn.net \
--cc=dwmw2@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@intel.com \
--cc=jgross@suse.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=mingo@redhat.com \
--cc=pengfei.xu@intel.com \
--cc=robin.murphy@arm.com \
--cc=rostedt@goodmis.org \
--cc=sstabellini@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).