Re: [PATCH v9 0/5] iommu: Bounce page for untrusted devices
On Tue, Sep 10, 2019 at 04:53:23PM +0200, Joerg Roedel wrote: > On Fri, Sep 06, 2019 at 02:14:47PM +0800, Lu Baolu wrote: > > Lu Baolu (5): > > swiotlb: Split size parameter to map/unmap APIs > > iommu/vt-d: Check whether device requires bounce buffer > > iommu/vt-d: Don't switch off swiotlb if bounce page is used > > iommu/vt-d: Add trace events for device dma map/unmap > > iommu/vt-d: Use bounce buffer for untrusted devices > > > > .../admin-guide/kernel-parameters.txt | 5 + > > drivers/iommu/Kconfig | 1 + > > drivers/iommu/Makefile| 1 + > > drivers/iommu/intel-iommu.c | 310 +- > > drivers/iommu/intel-trace.c | 14 + > > drivers/xen/swiotlb-xen.c | 8 +- > > include/linux/swiotlb.h | 8 +- > > include/trace/events/intel_iommu.h| 106 ++ > > kernel/dma/direct.c | 2 +- > > kernel/dma/swiotlb.c | 30 +- > > 10 files changed, 449 insertions(+), 36 deletions(-) > > create mode 100644 drivers/iommu/intel-trace.c > > create mode 100644 include/trace/events/intel_iommu.h > > Applied, thanks. Please un-apply the swiotlb until the WARN_ON gets fixed. Or alternatively squash the fix once that is done. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v9 0/5] iommu: Bounce page for untrusted devices
On Fri, Sep 06, 2019 at 02:14:47PM +0800, Lu Baolu wrote: > Lu Baolu (5): > swiotlb: Split size parameter to map/unmap APIs > iommu/vt-d: Check whether device requires bounce buffer > iommu/vt-d: Don't switch off swiotlb if bounce page is used > iommu/vt-d: Add trace events for device dma map/unmap > iommu/vt-d: Use bounce buffer for untrusted devices > > .../admin-guide/kernel-parameters.txt | 5 + > drivers/iommu/Kconfig | 1 + > drivers/iommu/Makefile| 1 + > drivers/iommu/intel-iommu.c | 310 +- > drivers/iommu/intel-trace.c | 14 + > drivers/xen/swiotlb-xen.c | 8 +- > include/linux/swiotlb.h | 8 +- > include/trace/events/intel_iommu.h| 106 ++ > kernel/dma/direct.c | 2 +- > kernel/dma/swiotlb.c | 30 +- > 10 files changed, 449 insertions(+), 36 deletions(-) > create mode 100644 drivers/iommu/intel-trace.c > create mode 100644 include/trace/events/intel_iommu.h Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v9 0/5] iommu: Bounce page for untrusted devices
The Thunderbolt vulnerabilities are public and have a nice name as Thunderclap [1] [3] nowadays. This patch series aims to mitigate those concerns. An external PCI device is a PCI peripheral device connected to the system through an external bus, such as Thunderbolt. What makes it different is that it can't be trusted to the same degree as the devices build into the system. Generally, a trusted PCIe device will DMA into the designated buffers and not overrun or otherwise write outside the specified bounds. But it's different for an external device. The minimum IOMMU mapping granularity is one page (4k), so for DMA transfers smaller than that a malicious PCIe device can access the whole page of memory even if it does not belong to the driver in question. This opens a possibility for DMA attack. For more information about DMA attacks imposed by an untrusted PCI/PCIe device, please refer to [2]. This implements bounce buffer for the untrusted external devices. The transfers should be limited in isolated pages so the IOMMU window does not cover memory outside of what the driver expects. Previously (v3 and before), we proposed an optimisation to only copy the head and tail of the buffer if it spans multiple pages, and directly map the ones in the middle. Figure 1 gives a big picture about this solution. swiotlb System IOVA bounce page Memory .-. .-..-. | | | || | | | | || | buffer_start .-. .-..-. | |->| |***>| | | | | | swiotlb| | | | | | mapping| | IOMMU Page '-' '-''-' Boundary | | | | | | | | | | | | | |>| | | |IOMMU mapping| | | | | | IOMMU Page .-. .-. Boundary | | | | | | | | | |>| | | | IOMMU mapping | | | | | | | | | | IOMMU Page .-. .-..-. Boundary | | | || | | | | || | | |->| |***>| | buffer_end '-' '-' swiotlb'-' | | | | mapping| | | | | || | '-' '-''-' Figure 1: A big view of iommu bounce page As Robin Murphy pointed out, this ties us to using strict mode for TLB maintenance, which may not be an overall win depending on the balance between invalidation bandwidth vs. memcpy bandwidth. If we use standard SWIOTLB logic to always copy the whole thing, we should be able to release the bounce pages via the flush queue to allow 'safe' lazy unmaps. So since v4 we start to use the standard swiotlb logic. swiotlb System IOVA bounce page Memory buffer_start .-. .-..-. | | | || | | | | || | | | | |.-.physical | |->| | -->| |_start | |iommu | | swiotlb| | | | map | | map | | IOMMU Page .-. .-.'-' Boundary | | | || | | | | || | | |->| || | | |iommu | || | | | map | || | | | | || | IOMMU Page .-. .-..-. Boundary | | | || | | |->| || | | |iommu | || | | | map | || | | |
