linux-kernel - Re: [PATCH v5] PCI: Detect and trust built-in Thunderbolt chips

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]

Message-ID: <20241030113108.GT275077@black.fi.intel.com>
Date: Wed, 30 Oct 2024 13:31:08 +0200
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: Lukas Wunner <lukas@...ner.de>
Cc: Bjorn Helgaas <helgaas@...nel.org>,
	Esther Shimanovich <eshimanovich@...omium.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Rajat Jain <rajatja@...gle.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Mario Limonciello <mario.limonciello@....com>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	iommu@...ts.linux.dev, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5] PCI: Detect and trust built-in Thunderbolt chips

On Wed, Oct 30, 2024 at 12:11:33PM +0100, Lukas Wunner wrote:
> On Tue, Oct 29, 2024 at 07:15:24PM -0500, Bjorn Helgaas wrote:
> > I asked on the v4 patch whether we really need to make all this
> > ACPI specific, and I'm still curious about that, since we don't
> > actually use any ACPI interfaces directly.
> 
> The patch works around a deficiency in a Microsoft spec which is
> specifically for ACPI-based systems, not devicetree-based systems:
> 
>    "ACPI Interface: Device Specific Data (_DSD) for PCIe Root Ports
>     In Windows 10 (Version 1803), new ACPI _DSD methods have been added
>     to support Modern Standby and PCI hot plug scenarios."
> 
>     https://learn.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports
> 
> The deficiency is that Microsoft says the ExternalFacingPort property
> must be below the Root Port...
> 
>    "This ACPI object enables the operating system to identify externally
>     exposed PCIe hierarchies, such as Thunderbolt. This object must be
>     implemented in the Root Port ACPI device scope."
> 
> ...but on the systems in question, external-facing ports do not
> originate from the Root Port, but from Downstream Ports.
> So there's the Root Port (with the external facing property),
> below that an Upstream Port and below that a Downstream Port
> (which is the actual external facing port).
> 
> I'm not sure if Windows on ARM systems use ACPI or devicetree.
> I'm also not sure whether the Qualcomm SnapDragon SoCs they use
> have Thunderbolt built-in, in which case they won't need a
> discrete Thunderbolt controller.  If they don't use discrete
> Thunderbolt controllers or if they don't use ACPI, they can't
> exhibit the problem.
> 
> In any case I haven't heard of any Windows on ARM systems being
> affected by the issue.

Well they can do whatever they want without us knowing ;-) This problem
does not happen even in x86 Windows probably because they do something
similar than this patch.

> So it boils down to:  Should we compile the quirk in just in case
> ARM-based ACPI systems with discrete Thunderbolt controllers and
> problematic ACPI tables show up, or should we constrain it to x86,
> which is the only known architecture that actually needs it right now.
> 
> My recommendation would be the latter because it's easy to move
> code around in the tree, should other arches become affected,
> but in the meantime we save memory and compile time on anything
> not x86.

IMHO this should be made generic enough that allows device tree based
systems to take advantage of this right from the get-go. Note also there
is already "external-facing" device tree property that matches the ACPI
one defined in Documentation/devicetree/bindings/pci/pci.txt.