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: <ZyIwg0nNb_eVzRaz@wunner.de>
Date: Wed, 30 Oct 2024 14:11:31 +0100
From: Lukas Wunner <lukas@...ner.de>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
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 01:31:08PM +0200, Mika Westerberg wrote:
> On Wed, Oct 30, 2024 at 12:11:33PM +0100, Lukas Wunner wrote:
> > 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.

I meant Linux on "Windows on ARM" machines. :)

This article claims that UEFI+ACPI is used to boot Windows,
but Qualcomm recommends devicetree is used for Linux:

https://www.heise.de/en/news/Snapdragon-X-notebooks-Ditch-Windows-Install-Linux-9781461.html


> > 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.

The workaround implemented by Esther's patch (only) becomes necessary
because OEMs followed Microsoft's spec blindly and put the property
below the Root Port, instead of the Downstream Port.

Devicetree-based systems are not bound by Microsoft's spec, so do not
*have* to fall into the same trap.

Thanks,

Lukas