Re: [PATCH v4 6/9] iommu/vt-d: Check whether device requires bounce buffer

[Lu Baolu]

Hi,

On 6/11/19 12:08 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Jun 03, 2019 at 09:16:17AM +0800, Lu Baolu wrote:
> > This adds a helper to check whether a device needs to use bounce
> > buffer. It also provides a boot time option to disable the bounce
> > buffer. Users can use this to prevent the iommu driver from using
> > the bounce buffer for performance gain.
> >
> > Cc: Ashok Raj <ashok.raj@xxxxxxxxx> Cc: Jacob Pan
> > <jacob.jun.pan@xxxxxxxxxxxxxxx> Cc: Kevin Tian
> > <kevin.tian@xxxxxxxxx> Signed-off-by: Lu Baolu
> > <baolu.lu@xxxxxxxxxxxxxxx> Tested-by: Xu Pengfei
> > <pengfei.xu@xxxxxxxxx> Tested-by: Mika Westerberg
> > <mika.westerberg@xxxxxxxxx> --- 
> > Documentation/admin-guide/kernel-parameters.txt | 5 +++++ 
> > drivers/iommu/intel-iommu.c                     | 6 ++++++ 2 files
> > changed, 11 insertions(+)
> >
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > b/Documentation/admin-guide/kernel-parameters.txt index
> > 138f6664b2e2..65685c6e53e4 100644 ---
> > a/Documentation/admin-guide/kernel-parameters.txt +++
> > b/Documentation/admin-guide/kernel-parameters.txt @@ -1728,6
> > +1728,11 @@ Note that using this option lowers the security 
> > provided by tboot because it makes the system vulnerable to DMA
> > attacks. +		nobounce [Default off] +			Do not use the bounce buffer
> > for untrusted devices like +			the Thunderbolt devices. This will
> > treat the untrusted
>
> My brain has sometimes a hard time parsing 'Not' and 'un'. Could this
> be:
>
> Disable bounce buffer for unstrusted devices ..?

Fair enough.

> And perhaps call it 'noswiotlb' ? Not everyone knows that SWIOTLB =
> bounce buffer.

As I said in previous thread, swiotlb is not only used for BOUNCE_PAGE
case, but also used by direct dma APIs. Will it cause confusion?

Anyway, I have no strong feeling to use 'nobounce' or 'noswiotlb'. It's
a driver specific switch for debugging purpose. People suggested that we
should move this switch into pci module, but I heard that it's more
helpful to implement per-device switch for "trusted' or "untrusted".
So I kept this untouched in this version.

> > +			devices as the trusted ones, hence might expose security +
> > risks of DMA attacks.
> >
> > intel_idle.max_cstate=	[KNL,HW,ACPI,X86] 0	disables intel_idle and
> > fall back on acpi_idle. diff --git a/drivers/iommu/intel-iommu.c
> > b/drivers/iommu/intel-iommu.c index 235837c50719..41439647f75d
> > 100644 --- a/drivers/iommu/intel-iommu.c +++
> > b/drivers/iommu/intel-iommu.c @@ -371,6 +371,7 @@ static int
> > dmar_forcedac; static int intel_iommu_strict; static int
> > intel_iommu_superpage = 1; static int iommu_identity_mapping; 
> > +static int intel_no_bounce;
>
> intel_swiotlb_on = 1 ?
>
> > #define IDENTMAP_ALL		1 #define IDENTMAP_GFX		2 @@ -384,6 +385,8 @@
> > EXPORT_SYMBOL_GPL(intel_iommu_gfx_mapped); static
> > DEFINE_SPINLOCK(device_domain_lock); static
> > LIST_HEAD(device_domain_list);
> >
> > +#define device_needs_bounce(d) (!intel_no_bounce &&
> > dev_is_untrusted(d)) + /* * Iterate over elements in
> > device_domain_list and call the specified * callback @fn against
> > each element. @@ -466,6 +469,9 @@ static int __init
> > intel_iommu_setup(char *str) printk(KERN_INFO "Intel-IOMMU: not
> > forcing on after tboot. This could expose security risk for
> > tboot\n"); intel_iommu_tboot_noforce = 1; +		} else if
> > (!strncmp(str, "nobounce", 8)) { +			pr_info("Intel-IOMMU: No
> > bounce buffer. This could expose security risks of DMA
> > attacks\n");
>
> Again, Intel-IOMMU: No SWIOTLB. T.. blah blah'
>
> Asking for this as doing 'dmesg | grep SWIOTLB' will expose nicely
> all the SWIOTLB invocations..

Yes. Will refine this.

Best regards,
Baolu