Messages in this thread | | | From | "Tian, Kevin" <> | Subject | RE: [PATCH] iommu/vt-d: Add a fix for devices need extra dtlb flush | Date | Wed, 23 Nov 2022 05:18:55 +0000 |
| |
> 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.
| |