Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1966449ybh; Tue, 14 Jul 2020 11:52:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5N+dHTrlSV4pE/LFbPXBNLxlYixbxymEkPMFSxAFiDlNqO/NrJK483M+RWr6NSWk/3QXL X-Received: by 2002:a50:ee8d:: with SMTP id f13mr5753972edr.302.1594752778194; Tue, 14 Jul 2020 11:52:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594752778; cv=none; d=google.com; s=arc-20160816; b=mSUZsns6nZessLbAx1ygaFo2j1FL7BiYtZNHRfeNay4YO6ZV4WbVkzpwfZvuzgflgy 3k7E7HbaOaArol2wmx6wM4RQyMdO2e8kRViAWF2ygo4YljPvVkHeeFFYsT1+vFqn+6Gx WPAYqfuBhWBzmuzOPgOjr5GeLORwG+Tj/AAT1RgXjZNBVc5VegSeL3ni7zi//PxK/dvy MdeC79AkfI/tVHfPURgoSZgk+Sp/2LyyZtKXKVr83pSiJfWIFlCvvS+oV9c0RyTCPbe0 2wcVSKZs0eh7cEe0KBXf4qXpW6DtsT3JoInnVDg8lLEcepVSVkT8TMYWz2RGiFU08TtM cjqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=Rx8CUTJIrP0FhiFki6zDwcyIt56si85SDOqsYN0CmNU=; b=rCsWI20MaEFbZOfa7gS7HEYKOLwD36kGQWF8Rf6i0bjGKggw7nGFxavuMBNwzhBtUJ ghF0pLOo/6yQsWR0Cb5sab7SNb4nEPl+HYC8WJilAsD/Z+yiFH+nW6dQNGQYOKIG37Ng MyFGMtMIz1R5OxSJ/ey18Bg7NeUh2q630ofqFSPpiun5ZRjU8KHtHZ/mu1JsD4fK6uZg C/2IYQyx1cfci3tCLavXJNlx99KBQutWetCXnSPzpC0WpNbQwUMtgqlz1w8QDUr/XA2c kJsSskZBDHKwXzRA2dM0nXJrHrWPZshwpvoUkx5uo5KJSOL3i6s4PCLl7CPQg8GS6Mpl zMkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ZuHu3T62; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w6si11034168ejc.605.2020.07.14.11.52.34; Tue, 14 Jul 2020 11:52:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ZuHu3T62; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729539AbgGNStR (ORCPT + 99 others); Tue, 14 Jul 2020 14:49:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:44978 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730094AbgGNStP (ORCPT ); Tue, 14 Jul 2020 14:49:15 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6C8BA22AB9; Tue, 14 Jul 2020 18:49:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594752554; bh=lYrltIfxijH5Z0usjkpTShBJCrgEMq7QguhwwhPHI4k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZuHu3T62nEfYpwGu6ptcXs69LvsVx4Ypzr2uTk39pJ5lvLrnfZHq4RNvW5qRsOp/U 4ZBmgXmJKQuUg7IGt3qb5jgWNuCAjFe+z+Jg+8CBhgileox7+t5Mvf6B/bsTiyCiRn TUgS51EpIfswhxsamFj4CkC31IFbBiyqFuXUOCdQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Rajat Jain , Ashok Raj , Mika Westerberg , Lu Baolu , Joerg Roedel , Sasha Levin Subject: [PATCH 5.4 022/109] iommu/vt-d: Dont apply gfx quirks to untrusted devices Date: Tue, 14 Jul 2020 20:43:25 +0200 Message-Id: <20200714184106.591180922@linuxfoundation.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200714184105.507384017@linuxfoundation.org> References: <20200714184105.507384017@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rajat Jain [ Upstream commit 67e8a5b18d41af9298db5c17193f671f235cce01 ] 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 Reviewed-by: Ashok Raj Reviewed-by: Mika Westerberg Acked-by: Lu Baolu Link: https://lore.kernel.org/r/20200622231345.29722-4-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin --- 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 6366b5fbb3a46..cdc1f4736a116 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -5962,6 +5962,23 @@ static bool intel_iommu_is_attach_deferred(struct iommu_domain *domain, return dev->archdata.iommu == DEFER_DEVICE_DOMAIN_INFO; } +/* + * 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_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"); + return true; + } + return false; +} + const struct iommu_ops intel_iommu_ops = { .capable = intel_iommu_capable, .domain_alloc = intel_iommu_domain_alloc, @@ -5990,6 +6007,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; } @@ -6031,6 +6051,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. @@ -6061,6 +6084,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; @@ -6094,6 +6120,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 @@ -6103,6 +6135,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.25.1