From: Lukas Wunner <lukas@wunner.de>
To: Esther Shimanovich <eshimanovich@chromium.org>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
"Rajat Jain" <rajatja@google.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
"Mario Limonciello" <mario.limonciello@amd.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
iommu@lists.linux.dev,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] PCI: Detect and trust built-in Thunderbolt chips
Date: Sun, 25 Aug 2024 16:42:18 +0200 [thread overview]
Message-ID: <ZstCyti3FHZIeFO8@wunner.de> (raw)
In-Reply-To: <20240823-trust-tbt-fix-v4-1-c6f1e3bdd9be@chromium.org>
On Fri, Aug 23, 2024 at 04:53:16PM +0000, Esther Shimanovich wrote:
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> +static bool pcie_has_usb4_host_interface(struct pci_dev *pdev)
> +{
> + struct fwnode_handle *fwnode;
> +
> + /*
> + * For USB4, the tunneled PCIe root or downstream ports are marked
> + * with the "usb4-host-interface" ACPI property, so we look for
> + * that first. This should cover most cases.
> + */
> + fwnode = fwnode_find_reference(dev_fwnode(&pdev->dev),
> + "usb4-host-interface", 0);
This is all ACPI only, so it should either be #ifdef'ed to CONFIG_ACPI
or moved to drivers/pci/pci-acpi.c.
Alternatively, it could be moved to arch/x86/pci/ because ACPI can also
be enabled on arm64 or riscv but the issue seems to only affect x86.
> static void set_pcie_untrusted(struct pci_dev *dev)
> {
> - struct pci_dev *parent;
> + struct pci_dev *parent = pci_upstream_bridge(dev);
>
> + if (!parent)
> + return;
> /*
> - * If the upstream bridge is untrusted we treat this device
> + * If the upstream bridge is untrusted we treat this device as
> * untrusted as well.
> */
> - parent = pci_upstream_bridge(dev);
> - if (parent && (parent->untrusted || parent->external_facing))
> + if (parent->untrusted)
> dev->untrusted = true;
> +
> + if (pcie_is_tunneled(dev)) {
> + pci_dbg(dev, "marking as untrusted\n");
> + dev->untrusted = true;
> + }
> }
I think you want to return in the "if (parent->untrusted)" case
because there's no need to double-check pcie_is_tunneled(dev)
if you've already determined that the device is untrusted.
> static void pci_set_removable(struct pci_dev *dev)
> {
> struct pci_dev *parent = pci_upstream_bridge(dev);
>
> + if (!parent)
> + return;
> /*
> - * We (only) consider everything downstream from an external_facing
> + * We (only) consider everything tunneled below an external_facing
> * device to be removable by the user. We're mainly concerned with
> * consumer platforms with user accessible thunderbolt ports that are
> * vulnerable to DMA attacks, and we expect those ports to be marked by
> @@ -1657,9 +1784,13 @@ static void pci_set_removable(struct pci_dev *dev)
> * accessible to user / may not be removed by end user, and thus not
> * exposed as "removable" to userspace.
> */
> - if (parent &&
> - (parent->external_facing || dev_is_removable(&parent->dev)))
> + if (dev_is_removable(&parent->dev))
> + dev_set_removable(&dev->dev, DEVICE_REMOVABLE);
> +
> + if (pcie_is_tunneled(dev)) {
> + pci_dbg(dev, "marking as removable\n");
> dev_set_removable(&dev->dev, DEVICE_REMOVABLE);
> + }
> }
Same here, return in the "if (dev_is_removable(&parent->dev))" case.
Thanks,
Lukas
next prev parent reply other threads:[~2024-08-25 14:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-23 16:53 [PATCH v4] PCI: Detect and trust built-in Thunderbolt chips Esther Shimanovich
2024-08-23 21:12 ` Bjorn Helgaas
2024-08-24 4:26 ` Mika Westerberg
2024-08-24 16:20 ` Bjorn Helgaas
2024-08-26 4:31 ` Mika Westerberg
2024-08-28 21:05 ` Esther Shimanovich
2024-09-30 18:23 ` Esther Shimanovich
2024-08-25 14:42 ` Lukas Wunner [this message]
2024-08-28 21:15 ` Esther Shimanovich
2024-08-29 9:32 ` Lukas Wunner
2024-10-23 20:58 ` Bjorn Helgaas
2024-10-23 21:06 ` Bjorn Helgaas
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=ZstCyti3FHZIeFO8@wunner.de \
--to=lukas@wunner.de \
--cc=bhelgaas@google.com \
--cc=eshimanovich@chromium.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mika.westerberg@linux.intel.com \
--cc=rafael.j.wysocki@intel.com \
--cc=rajatja@google.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).