linux-kernel - Re: [PATCH] iommu/vt-d: Add a fix for devices need extra dtlb flush

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 23 Nov 2022 13:03:52 +0800
From:   Baolu Lu <baolu.lu@...ux.intel.com>
To:     "Tian, Kevin" <kevin.tian@...el.com>,
        Robin Murphy <robin.murphy@....com>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
        Joerg Roedel <joro@...tes.org>
Cc:     baolu.lu@...ux.intel.com, Will Deacon <will@...nel.org>,
        David Woodhouse <dwmw2@...radead.org>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "Liu, Yi L" <yi.l.liu@...el.com>,
        "Luo, Yuzhang" <yuzhang.luo@...el.com>
Subject: Re: [PATCH] iommu/vt-d: Add a fix for devices need extra dtlb flush

On 2022/11/23 9:02, Tian, Kevin wrote:
>> From: Robin Murphy <robin.murphy@....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.

>>
> 
> ATS is disabled for such device hence no dtlb at all.
> 
> bool pci_ats_supported(struct pci_dev *dev)
> {
> 	if (!dev->ats_cap)
> 		return false;
> 
> 	return (dev->untrusted == 0);
> }
> 
> So above check doesn't make things worse. It's kind of meaningless
> but according to Baolu he wants that check in every quirk...

At some time in the future, the hardware may support kind of enhanced
ATS (or Secure ATS). At that time, above condition may be changed.

Best regards,
baolu