iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v3] iommu/vt-d: Don't apply gfx quirks to untrusted devices
@ 2020-06-02 23:26 Rajat Jain via iommu
  2020-06-02 23:28 ` Raj, Ashok
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Rajat Jain via iommu @ 2020-06-02 23:26 UTC (permalink / raw)
  To: David Woodhouse, Lu Baolu, Joerg Roedel, iommu, linux-kernel,
	Mika Westerberg, Ashok Raj, lalithambika.krishnakumar
  Cc: tbroch, rajatxjain, pmalani, mnissler, bleung, Rajat Jain, zsm, levinale

Currently, an external malicious PCI device can masquerade the VID:PID
of faulty gfx devices, and thus apply iommu quirks to effectively
disable the IOMMU restrictions for itself.

Thus we need to ensure that the device we are applying quirks to, is
indeed an internal trusted device.

Signed-off-by: Rajat Jain <rajatja@google.com>
Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
---
v3: - Separate out the warning mesage in a function to be called from
      other places. Change the warning string as suggested.
v2: - Change the warning print strings.
    - Add Lu Baolu's acknowledgement.

 drivers/iommu/intel-iommu.c | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index ef0a5246700e5..dc859f02985a0 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -6185,6 +6185,23 @@ intel_iommu_domain_set_attr(struct iommu_domain *domain,
 	return ret;
 }
 
+/*
+ * Check that the device does not live on an external facing PCI port that is
+ * marked as untrusted. Such devices should not be able to apply quirks and
+ * thus not be able to bypass the IOMMU restrictions.
+ */
+static bool risky_device(struct pci_dev *pdev)
+{
+	if (pdev->untrusted) {
+		pci_warn(pdev,
+			 "Skipping IOMMU quirk for dev (%04X:%04X) on untrusted"
+			 " PCI link. Please check with your BIOS/Platform"
+			 " vendor about this\n", pdev->vendor, pdev->device);
+		return true;
+	}
+	return false;
+}
+
 const struct iommu_ops intel_iommu_ops = {
 	.capable		= intel_iommu_capable,
 	.domain_alloc		= intel_iommu_domain_alloc,
@@ -6214,6 +6231,9 @@ const struct iommu_ops intel_iommu_ops = {
 
 static void quirk_iommu_igfx(struct pci_dev *dev)
 {
+	if (risky_device(dev))
+		return;
+
 	pci_info(dev, "Disabling IOMMU for graphics on this chipset\n");
 	dmar_map_gfx = 0;
 }
@@ -6255,6 +6275,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163D, quirk_iommu_igfx);
 
 static void quirk_iommu_rwbf(struct pci_dev *dev)
 {
+	if (risky_device(dev))
+		return;
+
 	/*
 	 * Mobile 4 Series Chipset neglects to set RWBF capability,
 	 * but needs it. Same seems to hold for the desktop versions.
@@ -6285,6 +6308,9 @@ static void quirk_calpella_no_shadow_gtt(struct pci_dev *dev)
 {
 	unsigned short ggc;
 
+	if (risky_device(dev))
+		return;
+
 	if (pci_read_config_word(dev, GGC, &ggc))
 		return;
 
@@ -6318,6 +6344,12 @@ static void __init check_tylersburg_isoch(void)
 	pdev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x3a3e, NULL);
 	if (!pdev)
 		return;
+
+	if (risky_device(pdev)) {
+		pci_dev_put(pdev);
+		return;
+	}
+
 	pci_dev_put(pdev);
 
 	/* System Management Registers. Might be hidden, in which case
@@ -6327,6 +6359,11 @@ static void __init check_tylersburg_isoch(void)
 	if (!pdev)
 		return;
 
+	if (risky_device(pdev)) {
+		pci_dev_put(pdev);
+		return;
+	}
+
 	if (pci_read_config_dword(pdev, 0x188, &vtisochctrl)) {
 		pci_dev_put(pdev);
 		return;
-- 
2.27.0.rc2.251.g90737beb825-goog

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH v3] iommu/vt-d: Don't apply gfx quirks to untrusted devices
  2020-06-02 23:26 [PATCH v3] iommu/vt-d: Don't apply gfx quirks to untrusted devices Rajat Jain via iommu
@ 2020-06-02 23:28 ` Raj, Ashok
  2020-06-02 23:49 ` Prashant Malani via iommu
  2020-06-03  5:30 ` Mika Westerberg
  2 siblings, 0 replies; 7+ messages in thread
From: Raj, Ashok @ 2020-06-02 23:28 UTC (permalink / raw)
  To: Rajat Jain
  Cc: tbroch, rajatxjain, pmalani, zsm, linux-kernel,
	lalithambika.krishnakumar, iommu, mnissler, Ashok Raj, bleung,
	levinale, David Woodhouse, Mika Westerberg

On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> Currently, an external malicious PCI device can masquerade the VID:PID
> of faulty gfx devices, and thus apply iommu quirks to effectively
> disable the IOMMU restrictions for itself.
> 
> Thus we need to ensure that the device we are applying quirks to, is
> indeed an internal trusted device.
> 
> Signed-off-by: Rajat Jain <rajatja@google.com>
> Acked-by: Lu Baolu <baolu.lu@linux.intel.com>

With these changes

Reviewed-by: Ashok Raj <ashok.raj@intel.com>

> ---
> v3: - Separate out the warning mesage in a function to be called from
>       other places. Change the warning string as suggested.
> v2: - Change the warning print strings.
>     - Add Lu Baolu's acknowledgement.
> 
>  drivers/iommu/intel-iommu.c | 37 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
> 
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index ef0a5246700e5..dc859f02985a0 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -6185,6 +6185,23 @@ intel_iommu_domain_set_attr(struct iommu_domain *domain,
>  	return ret;
>  }
>  
> +/*
> + * Check that the device does not live on an external facing PCI port that is
> + * marked as untrusted. Such devices should not be able to apply quirks and
> + * thus not be able to bypass the IOMMU restrictions.
> + */
> +static bool risky_device(struct pci_dev *pdev)
> +{
> +	if (pdev->untrusted) {
> +		pci_warn(pdev,
> +			 "Skipping IOMMU quirk for dev (%04X:%04X) on untrusted"
> +			 " PCI link. Please check with your BIOS/Platform"
> +			 " vendor about this\n", pdev->vendor, pdev->device);
> +		return true;
> +	}
> +	return false;
> +}
> +
>  const struct iommu_ops intel_iommu_ops = {
>  	.capable		= intel_iommu_capable,
>  	.domain_alloc		= intel_iommu_domain_alloc,
> @@ -6214,6 +6231,9 @@ const struct iommu_ops intel_iommu_ops = {
>  
>  static void quirk_iommu_igfx(struct pci_dev *dev)
>  {
> +	if (risky_device(dev))
> +		return;
> +
>  	pci_info(dev, "Disabling IOMMU for graphics on this chipset\n");
>  	dmar_map_gfx = 0;
>  }
> @@ -6255,6 +6275,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163D, quirk_iommu_igfx);
>  
>  static void quirk_iommu_rwbf(struct pci_dev *dev)
>  {
> +	if (risky_device(dev))
> +		return;
> +
>  	/*
>  	 * Mobile 4 Series Chipset neglects to set RWBF capability,
>  	 * but needs it. Same seems to hold for the desktop versions.
> @@ -6285,6 +6308,9 @@ static void quirk_calpella_no_shadow_gtt(struct pci_dev *dev)
>  {
>  	unsigned short ggc;
>  
> +	if (risky_device(dev))
> +		return;
> +
>  	if (pci_read_config_word(dev, GGC, &ggc))
>  		return;
>  
> @@ -6318,6 +6344,12 @@ static void __init check_tylersburg_isoch(void)
>  	pdev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x3a3e, NULL);
>  	if (!pdev)
>  		return;
> +
> +	if (risky_device(pdev)) {
> +		pci_dev_put(pdev);
> +		return;
> +	}
> +
>  	pci_dev_put(pdev);
>  
>  	/* System Management Registers. Might be hidden, in which case
> @@ -6327,6 +6359,11 @@ static void __init check_tylersburg_isoch(void)
>  	if (!pdev)
>  		return;
>  
> +	if (risky_device(pdev)) {
> +		pci_dev_put(pdev);
> +		return;
> +	}
> +
>  	if (pci_read_config_dword(pdev, 0x188, &vtisochctrl)) {
>  		pci_dev_put(pdev);
>  		return;
> -- 
> 2.27.0.rc2.251.g90737beb825-goog
> 
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v3] iommu/vt-d: Don't apply gfx quirks to untrusted devices
  2020-06-02 23:26 [PATCH v3] iommu/vt-d: Don't apply gfx quirks to untrusted devices Rajat Jain via iommu
  2020-06-02 23:28 ` Raj, Ashok
@ 2020-06-02 23:49 ` Prashant Malani via iommu
  2020-06-03  0:23   ` Rajat Jain
  2020-06-03  5:30 ` Mika Westerberg
  2 siblings, 1 reply; 7+ messages in thread
From: Prashant Malani via iommu @ 2020-06-02 23:49 UTC (permalink / raw)
  To: Rajat Jain
  Cc: tbroch, Ashok Raj, rajatxjain, zsm, linux-kernel,
	lalithambika.krishnakumar, iommu, mnissler, bleung, levinale,
	David Woodhouse, Mika Westerberg

Hi Rajat,

On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> Currently, an external malicious PCI device can masquerade the VID:PID
> of faulty gfx devices, and thus apply iommu quirks to effectively
> disable the IOMMU restrictions for itself.
> 
> Thus we need to ensure that the device we are applying quirks to, is
> indeed an internal trusted device.
> 
> Signed-off-by: Rajat Jain <rajatja@google.com>
> Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
> ---
> v3: - Separate out the warning mesage in a function to be called from
>       other places. Change the warning string as suggested.
> v2: - Change the warning print strings.
>     - Add Lu Baolu's acknowledgement.
> 
>  drivers/iommu/intel-iommu.c | 37 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
> 
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index ef0a5246700e5..dc859f02985a0 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -6185,6 +6185,23 @@ intel_iommu_domain_set_attr(struct iommu_domain *domain,
>  	return ret;
>  }
>  
> +/*
> + * Check that the device does not live on an external facing PCI port that is
> + * marked as untrusted. Such devices should not be able to apply quirks and
> + * thus not be able to bypass the IOMMU restrictions.
> + */
> +static bool risky_device(struct pci_dev *pdev)
> +{
> +	if (pdev->untrusted) {
> +		pci_warn(pdev,
> +			 "Skipping IOMMU quirk for dev (%04X:%04X) on untrusted"
> +			 " PCI link. Please check with your BIOS/Platform"
> +			 " vendor about this\n", pdev->vendor, pdev->device);
> +		return true;
> +	}
> +	return false;
minor suggestion: Perhaps you could use a guard clause here? It would save you
a level of indentation, and possibly allow better string splitting
(e.g keeping "untrusted PCI" together). So something like:

if (!pdev->untrusted)
	return false;

pci_warn(...);

I also hear the column limit warning is now for 100 chars [1], though
I'm not sure how it's being handled in this file.

Best regards,

-Prashant

[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/process/coding-style.rst?id=bdc48fa11e46f867ea4d75fa59ee87a7f48be144

> +}
> +
>  const struct iommu_ops intel_iommu_ops = {
>  	.capable		= intel_iommu_capable,
>  	.domain_alloc		= intel_iommu_domain_alloc,
> @@ -6214,6 +6231,9 @@ const struct iommu_ops intel_iommu_ops = {
>  
>  static void quirk_iommu_igfx(struct pci_dev *dev)
>  {
> +	if (risky_device(dev))
> +		return;
> +
>  	pci_info(dev, "Disabling IOMMU for graphics on this chipset\n");
>  	dmar_map_gfx = 0;
>  }
> @@ -6255,6 +6275,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163D, quirk_iommu_igfx);
>  
>  static void quirk_iommu_rwbf(struct pci_dev *dev)
>  {
> +	if (risky_device(dev))
> +		return;
> +
>  	/*
>  	 * Mobile 4 Series Chipset neglects to set RWBF capability,
>  	 * but needs it. Same seems to hold for the desktop versions.
> @@ -6285,6 +6308,9 @@ static void quirk_calpella_no_shadow_gtt(struct pci_dev *dev)
>  {
>  	unsigned short ggc;
>  
> +	if (risky_device(dev))
> +		return;
> +
>  	if (pci_read_config_word(dev, GGC, &ggc))
>  		return;
>  
> @@ -6318,6 +6344,12 @@ static void __init check_tylersburg_isoch(void)
>  	pdev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x3a3e, NULL);
>  	if (!pdev)
>  		return;
> +
> +	if (risky_device(pdev)) {
> +		pci_dev_put(pdev);
> +		return;
> +	}
> +
>  	pci_dev_put(pdev);
>  
>  	/* System Management Registers. Might be hidden, in which case
> @@ -6327,6 +6359,11 @@ static void __init check_tylersburg_isoch(void)
>  	if (!pdev)
>  		return;
>  
> +	if (risky_device(pdev)) {
> +		pci_dev_put(pdev);
> +		return;
> +	}
> +
>  	if (pci_read_config_dword(pdev, 0x188, &vtisochctrl)) {
>  		pci_dev_put(pdev);
>  		return;
> -- 
> 2.27.0.rc2.251.g90737beb825-goog
> 
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v3] iommu/vt-d: Don't apply gfx quirks to untrusted devices
  2020-06-02 23:49 ` Prashant Malani via iommu
@ 2020-06-03  0:23   ` Rajat Jain
  2020-06-03  0:32     ` Prashant Malani via iommu
  0 siblings, 1 reply; 7+ messages in thread
From: Rajat Jain @ 2020-06-03  0:23 UTC (permalink / raw)
  To: Prashant Malani
  Cc: tbroch, Ashok Raj, zsm, levinale, Linux Kernel Mailing List,
	lalithambika.krishnakumar, iommu, mnissler, bleung, Rajat Jain,
	David Woodhouse, Mika Westerberg

On Tue, Jun 2, 2020 at 4:49 PM Prashant Malani <pmalani@google.com> wrote:
>
> Hi Rajat,

Hi Prashant, thanks for taking a look.

>
> On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> > Currently, an external malicious PCI device can masquerade the VID:PID
> > of faulty gfx devices, and thus apply iommu quirks to effectively
> > disable the IOMMU restrictions for itself.
> >
> > Thus we need to ensure that the device we are applying quirks to, is
> > indeed an internal trusted device.
> >
> > Signed-off-by: Rajat Jain <rajatja@google.com>
> > Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
> > ---
> > v3: - Separate out the warning mesage in a function to be called from
> >       other places. Change the warning string as suggested.
> > v2: - Change the warning print strings.
> >     - Add Lu Baolu's acknowledgement.
> >
> >  drivers/iommu/intel-iommu.c | 37 +++++++++++++++++++++++++++++++++++++
> >  1 file changed, 37 insertions(+)
> >
> > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> > index ef0a5246700e5..dc859f02985a0 100644
> > --- a/drivers/iommu/intel-iommu.c
> > +++ b/drivers/iommu/intel-iommu.c
> > @@ -6185,6 +6185,23 @@ intel_iommu_domain_set_attr(struct iommu_domain *domain,
> >       return ret;
> >  }
> >
> > +/*
> > + * Check that the device does not live on an external facing PCI port that is
> > + * marked as untrusted. Such devices should not be able to apply quirks and
> > + * thus not be able to bypass the IOMMU restrictions.
> > + */
> > +static bool risky_device(struct pci_dev *pdev)
> > +{
> > +     if (pdev->untrusted) {
> > +             pci_warn(pdev,
> > +                      "Skipping IOMMU quirk for dev (%04X:%04X) on untrusted"
> > +                      " PCI link. Please check with your BIOS/Platform"
> > +                      " vendor about this\n", pdev->vendor, pdev->device);
> > +             return true;
> > +     }
> > +     return false;
> minor suggestion: Perhaps you could use a guard clause here? It would save you
> a level of indentation, and possibly allow better string splitting
> (e.g keeping "untrusted PCI" together). So something like:
>
> if (!pdev->untrusted)
>         return false;

I personally have found double negation expressions always confusing,
even if negation is part of the variable. (For e.g. I have found I
need to be always stop and convince myself that:

"if (!pdev->untrusted)"
    <do something>

conceptually implies

"if (pdev->trusted)".
    <do something>

So I tend to keep negations to minimum. In this case, it doesn't buy
us much either, so I'd prefer to keep it the same unless there are
more opinions on this. OTOH I don't mind changing it too if you feel
strongly about this.

Thanks,

Rajat


>
> pci_warn(...);
>
> I also hear the column limit warning is now for 100 chars [1], though
> I'm not sure how it's being handled in this file.
>
> Best regards,
>
> -Prashant
>
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/process/coding-style.rst?id=bdc48fa11e46f867ea4d75fa59ee87a7f48be144
>
> > +}
> > +
> >  const struct iommu_ops intel_iommu_ops = {
> >       .capable                = intel_iommu_capable,
> >       .domain_alloc           = intel_iommu_domain_alloc,
> > @@ -6214,6 +6231,9 @@ const struct iommu_ops intel_iommu_ops = {
> >
> >  static void quirk_iommu_igfx(struct pci_dev *dev)
> >  {
> > +     if (risky_device(dev))
> > +             return;
> > +
> >       pci_info(dev, "Disabling IOMMU for graphics on this chipset\n");
> >       dmar_map_gfx = 0;
> >  }
> > @@ -6255,6 +6275,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163D, quirk_iommu_igfx);
> >
> >  static void quirk_iommu_rwbf(struct pci_dev *dev)
> >  {
> > +     if (risky_device(dev))
> > +             return;
> > +
> >       /*
> >        * Mobile 4 Series Chipset neglects to set RWBF capability,
> >        * but needs it. Same seems to hold for the desktop versions.
> > @@ -6285,6 +6308,9 @@ static void quirk_calpella_no_shadow_gtt(struct pci_dev *dev)
> >  {
> >       unsigned short ggc;
> >
> > +     if (risky_device(dev))
> > +             return;
> > +
> >       if (pci_read_config_word(dev, GGC, &ggc))
> >               return;
> >
> > @@ -6318,6 +6344,12 @@ static void __init check_tylersburg_isoch(void)
> >       pdev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x3a3e, NULL);
> >       if (!pdev)
> >               return;
> > +
> > +     if (risky_device(pdev)) {
> > +             pci_dev_put(pdev);
> > +             return;
> > +     }
> > +
> >       pci_dev_put(pdev);
> >
> >       /* System Management Registers. Might be hidden, in which case
> > @@ -6327,6 +6359,11 @@ static void __init check_tylersburg_isoch(void)
> >       if (!pdev)
> >               return;
> >
> > +     if (risky_device(pdev)) {
> > +             pci_dev_put(pdev);
> > +             return;
> > +     }
> > +
> >       if (pci_read_config_dword(pdev, 0x188, &vtisochctrl)) {
> >               pci_dev_put(pdev);
> >               return;
> > --
> > 2.27.0.rc2.251.g90737beb825-goog
> >
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v3] iommu/vt-d: Don't apply gfx quirks to untrusted devices
  2020-06-03  0:23   ` Rajat Jain
@ 2020-06-03  0:32     ` Prashant Malani via iommu
  0 siblings, 0 replies; 7+ messages in thread
From: Prashant Malani via iommu @ 2020-06-03  0:32 UTC (permalink / raw)
  To: Rajat Jain
  Cc: tbroch, Ashok Raj, zsm, levinale, Linux Kernel Mailing List,
	lalithambika.krishnakumar, iommu, mnissler, bleung, Rajat Jain,
	David Woodhouse, Mika Westerberg

(Trimming text)

On Wed, Jun 03, 2020 at 12:23:48AM +0000, Rajat Jain wrote:
> On Tue, Jun 2, 2020 at 4:49 PM Prashant Malani <pmalani@google.com> wrote:
> >
> > Hi Rajat,
> 
> Hi Prashant, thanks for taking a look.
> 
> >
> > On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> > > +static bool risky_device(struct pci_dev *pdev)
> > > +{
> > > +     if (pdev->untrusted) {
> > > +             pci_warn(pdev,
> > > +                      "Skipping IOMMU quirk for dev (%04X:%04X) on untrusted"
> > > +                      " PCI link. Please check with your BIOS/Platform"
> > > +                      " vendor about this\n", pdev->vendor, pdev->device);
> > > +             return true;
> > > +     }
> > > +     return false;
> > minor suggestion: Perhaps you could use a guard clause here? It would save you
> > a level of indentation, and possibly allow better string splitting
> > (e.g keeping "untrusted PCI" together). So something like:
> >
> > if (!pdev->untrusted)
> >         return false;
> 
> I personally have found double negation expressions always confusing,
> even if negation is part of the variable. (For e.g. I have found I
> need to be always stop and convince myself that:
> 
> "if (!pdev->untrusted)"
>     <do something>
> 
> conceptually implies
> 
> "if (pdev->trusted)".
>     <do something>
> 
> So I tend to keep negations to minimum. In this case, it doesn't buy
> us much either, so I'd prefer to keep it the same unless there are
> more opinions on this. OTOH I don't mind changing it too if you feel
> strongly about this.

Ordinarily, I'd agree with you regarding double-negatives.

However, in this case the condition phrasing is so brief ("not untrusted") that I'd
argue the indentation savings outweigh possible interpretation issues.

That said, I don't have a strong opinion here, so will defer to the maintainer's preference.

Best,

> 
> Thanks,
> 
> Rajat
> 
> 
> >
> > pci_warn(...);
> >
> > I also hear the column limit warning is now for 100 chars [1], though
> > I'm not sure how it's being handled in this file.
> >
> > Best regards,
> >
> > -Prashant
> >
> > [1]:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/process/coding-style.rst?id=bdc48fa11e46f867ea4d75fa59ee87a7f48be144
> >
> > > +}
> > > +
> > >  const struct iommu_ops intel_iommu_ops = {
> > >       .capable                = intel_iommu_capable,
> > >       .domain_alloc           = intel_iommu_domain_alloc,
> > > @@ -6214,6 +6231,9 @@ const struct iommu_ops intel_iommu_ops = {
> > >
> > >  static void quirk_iommu_igfx(struct pci_dev *dev)
> > >  {
> > > +     if (risky_device(dev))
> > > +             return;
> > > +
> > >       pci_info(dev, "Disabling IOMMU for graphics on this chipset\n");
> > >       dmar_map_gfx = 0;
> > >  }
> > > @@ -6255,6 +6275,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163D, quirk_iommu_igfx);
> > >
> > >  static void quirk_iommu_rwbf(struct pci_dev *dev)
> > >  {
> > > +     if (risky_device(dev))
> > > +             return;
> > > +
> > >       /*
> > >        * Mobile 4 Series Chipset neglects to set RWBF capability,
> > >        * but needs it. Same seems to hold for the desktop versions.
> > > @@ -6285,6 +6308,9 @@ static void quirk_calpella_no_shadow_gtt(struct pci_dev *dev)
> > >  {
> > >       unsigned short ggc;
> > >
> > > +     if (risky_device(dev))
> > > +             return;
> > > +
> > >       if (pci_read_config_word(dev, GGC, &ggc))
> > >               return;
> > >
> > > @@ -6318,6 +6344,12 @@ static void __init check_tylersburg_isoch(void)
> > >       pdev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x3a3e, NULL);
> > >       if (!pdev)
> > >               return;
> > > +
> > > +     if (risky_device(pdev)) {
> > > +             pci_dev_put(pdev);
> > > +             return;
> > > +     }
> > > +
> > >       pci_dev_put(pdev);
> > >
> > >       /* System Management Registers. Might be hidden, in which case
> > > @@ -6327,6 +6359,11 @@ static void __init check_tylersburg_isoch(void)
> > >       if (!pdev)
> > >               return;
> > >
> > > +     if (risky_device(pdev)) {
> > > +             pci_dev_put(pdev);
> > > +             return;
> > > +     }
> > > +
> > >       if (pci_read_config_dword(pdev, 0x188, &vtisochctrl)) {
> > >               pci_dev_put(pdev);
> > >               return;
> > > --
> > > 2.27.0.rc2.251.g90737beb825-goog
> > >
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v3] iommu/vt-d: Don't apply gfx quirks to untrusted devices
  2020-06-02 23:26 [PATCH v3] iommu/vt-d: Don't apply gfx quirks to untrusted devices Rajat Jain via iommu
  2020-06-02 23:28 ` Raj, Ashok
  2020-06-02 23:49 ` Prashant Malani via iommu
@ 2020-06-03  5:30 ` Mika Westerberg
  2020-06-03 13:03   ` Rajat Jain via iommu
  2 siblings, 1 reply; 7+ messages in thread
From: Mika Westerberg @ 2020-06-03  5:30 UTC (permalink / raw)
  To: Rajat Jain
  Cc: tbroch, pmalani, Ashok Raj, rajatxjain, zsm, linux-kernel,
	lalithambika.krishnakumar, iommu, mnissler, bleung, levinale,
	David Woodhouse

On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> +static bool risky_device(struct pci_dev *pdev)
> +{
> +	if (pdev->untrusted) {
> +		pci_warn(pdev,
> +			 "Skipping IOMMU quirk for dev (%04X:%04X) on untrusted"
> +			 " PCI link. Please check with your BIOS/Platform"
> +			 " vendor about this\n", pdev->vendor, pdev->device);

You should not break user visible strings like this. It makes grepping
for them harder (see also CodingStyle). You can write it like this instead:

	pci_info(pdev, "Skipping IOMMU quirk for dev (%04X:%04X) on untrusted PCI link\n",
		 pdev->vendor, pdev->device);
	pci_info(pdev, "Please check with your BIOS/Platform vendor about this\n");

Also I guess pci_info() might be better here after all. Your call :)

Rest of the patch looks good to me.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v3] iommu/vt-d: Don't apply gfx quirks to untrusted devices
  2020-06-03  5:30 ` Mika Westerberg
@ 2020-06-03 13:03   ` Rajat Jain via iommu
  0 siblings, 0 replies; 7+ messages in thread
From: Rajat Jain via iommu @ 2020-06-03 13:03 UTC (permalink / raw)
  To: Mika Westerberg
  Cc: Todd Broch, Prashant Malani, Ashok Raj, Rajat Jain, Zubin Mithra,
	Linux Kernel Mailing List, Krishnakumar, Lalithambika, iommu,
	Mattias Nissler, Benson Leung, Alex Levin, David Woodhouse

On Tue, Jun 2, 2020 at 10:30 PM Mika Westerberg
<mika.westerberg@intel.com> wrote:
>
> On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> > +static bool risky_device(struct pci_dev *pdev)
> > +{
> > +     if (pdev->untrusted) {
> > +             pci_warn(pdev,
> > +                      "Skipping IOMMU quirk for dev (%04X:%04X) on untrusted"
> > +                      " PCI link. Please check with your BIOS/Platform"
> > +                      " vendor about this\n", pdev->vendor, pdev->device);
>
> You should not break user visible strings like this. It makes grepping
> for them harder (see also CodingStyle). You can write it like this instead:
>
>         pci_info(pdev, "Skipping IOMMU quirk for dev (%04X:%04X) on untrusted PCI link\n",
>                  pdev->vendor, pdev->device);
>         pci_info(pdev, "Please check with your BIOS/Platform vendor about this\n");
>
> Also I guess pci_info() might be better here after all. Your call :)

Done, sent the updated patch.

Thanks,

Rajat

>
> Rest of the patch looks good to me.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-06-03 13:04 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-02 23:26 [PATCH v3] iommu/vt-d: Don't apply gfx quirks to untrusted devices Rajat Jain via iommu
2020-06-02 23:28 ` Raj, Ashok
2020-06-02 23:49 ` Prashant Malani via iommu
2020-06-03  0:23   ` Rajat Jain
2020-06-03  0:32     ` Prashant Malani via iommu
2020-06-03  5:30 ` Mika Westerberg
2020-06-03 13:03   ` Rajat Jain via iommu

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