linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: "Tian, Kevin" <kevin.tian@intel.com>,
	Baolu Lu <baolu.lu@linux.intel.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	Joerg Roedel <joro@8bytes.org>
Cc: Will Deacon <will@kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	"Raj, Ashok" <ashok.raj@intel.com>,
	"Liu, Yi L" <yi.l.liu@intel.com>,
	"Luo, Yuzhang" <yuzhang.luo@intel.com>
Subject: Re: [PATCH] iommu/vt-d: Add a fix for devices need extra dtlb flush
Date: Wed, 23 Nov 2022 11:32:44 +0000	[thread overview]
Message-ID: <53678e27-1bbc-a7e8-a1b0-0427fc0e5b62@arm.com> (raw)
In-Reply-To: <BN9PR11MB527642B1DA920C78742036FD8C0C9@BN9PR11MB5276.namprd11.prod.outlook.com>

On 2022-11-23 05:18, Tian, Kevin wrote:
>> From: Baolu Lu <baolu.lu@linux.intel.com>
>> Sent: Wednesday, November 23, 2022 1:04 PM
>>
>> On 2022/11/23 9:02, Tian, Kevin wrote:
>>>> From: Robin Murphy <robin.murphy@arm.com>
>>>> Sent: Wednesday, November 23, 2022 1:49 AM
>>>>
>>>>> +
>>>>> +/* Impacted QAT device IDs ranging from 0x4940 to 0x4943 */
>>>>> +#define BUGGY_QAT_DEVID_MASK 0x494c
>>>>> +static bool dev_needs_extra_dtlb_flush(struct pci_dev *pdev)
>>>>> +{
>>>>> +	if (pdev->vendor != PCI_VENDOR_ID_INTEL)
>>>>> +		return false;
>>>>> +
>>>>> +	if ((pdev->device & 0xfffc) != BUGGY_QAT_DEVID_MASK)
>>>>> +		return false;
>>>>> +
>>>>> +	if (risky_device(pdev))
>>>>> +		return false;
>>>>
>>>> Hmm, I'm not sure that that makes much sense to me - what privilege can
>>>> the device gain from being told to invalidate things twice? Why would we
>>>> want to implicitly *allow* a device to potentially keep using a stale
>>>> translation if for some bizarre reason firmware has marked it as
>>>> external, surely that's worse?
>>
>>   From the perspective of IOMMU, any quirk is only applicable to trusted
>> devices. If the IOMMU driver detects that a quirk is being applied to an
>> untrusted device, it is already buggy or malicious. The IOMMU driver
>> should let the users know by:
>>
>> 	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");
>>
>> and stop applying any quirk.
>>
> 
> A quirk usually relaxes something then you want it only on trusted devices.
> 
> but the quirk in this patch is trying to fix a vulnerability. In concept it's
> weird to skip it on untrusted devices. This iiuc was the part causing confusion
> to Robin.

Right, it's that reasoning in general that seems bogus to me. Clearly 
any quirk that effectively grants additional privileges, like an 
identity mapping quirk, should not be applied to untrusted external 
devices which may be spoofing an affected VID/DID to gain that 
privilege, but not all quirks imply privilege. If, say, a WiFI 
controller needs something innocuous like a DMA alias or address width 
quirk to function correctly, it will still need that regardless of 
whether it's soldered to a motherboard or to a removable expansion card, 
and it would do nobody any good to deny correct functionality based on 
that unnecessary distinction. Yes, I appreciate that in practice many of 
those kind of quirks will be applied in other layers anyway, but I still 
think it's wrong to make a sweeping assumption that all IOMMU-level 
quirks are precious treasure not to be shared with outsiders, rather 
than assess their impact individually. The detriment in this case is 
small (just needless code churn), but even that's still not nothing.

Thanks,
Robin.

  reply	other threads:[~2022-11-23 11:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-22  3:45 [PATCH] iommu/vt-d: Add a fix for devices need extra dtlb flush Jacob Pan
2022-11-22 16:52 ` Ashok Raj
2022-11-28 16:13   ` Jacob Pan
2022-11-22 17:49 ` Robin Murphy
2022-11-23  1:02   ` Tian, Kevin
2022-11-23  5:03     ` Baolu Lu
2022-11-23  5:18       ` Tian, Kevin
2022-11-23 11:32         ` Robin Murphy [this message]
2022-11-24  2:52           ` Baolu Lu
2022-11-28 16:02             ` Jacob Pan

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=53678e27-1bbc-a7e8-a1b0-0427fc0e5b62@arm.com \
    --to=robin.murphy@arm.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux.dev \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    --cc=yuzhang.luo@intel.com \
    /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).