linux-kernel - Re: [PATCH v4] PCI: Relabel JHL6540 on Lenovo X1 Carbon 7,8

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, 15 May 2024 14:53:54 -0400
From: Esther Shimanovich <eshimanovich@...omium.org>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: Lukas Wunner <lukas@...ner.de>, Mario Limonciello <mario.limonciello@....com>, 
	Dmitry Torokhov <dmitry.torokhov@...il.com>, Bjorn Helgaas <bhelgaas@...gle.com>, 
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Rajat Jain <rajatja@...gle.com>
Subject: Re: [PATCH v4] PCI: Relabel JHL6540 on Lenovo X1 Carbon 7,8

I tried both patches!

Build with Lukas's commits:

On Wed, May 8, 2024 at 1:23 AM Lukas Wunner <lukas@...ner.de> wrote:
>
> On Wed, May 01, 2024 at 06:23:28PM -0400, Esther Shimanovich wrote:
> > On Sat, Apr 27, 2024 at 3:17AM Lukas Wunner <lukas@...ner.de> wrote:
> > That is correct, when the user-visible issue occurs, no driver is
> > bound to the NHI and XHCI. The discrete JHL chip is not permitted to
> > attach to the external-facing root port because of the security
> > policy, so the NHI and XHCI are not seen by the computer.
>
> Could you rework your patch to only rectify the NHI's and XHCI's
> device properties and leave the bridges untouched?

So I tried a build with that patch, but it never reached the
tb_pci_fixup function, even when NHI and XHCI were both labeled as
fixed and external facing in the quirk.
Also, I don't see where you distinguish between an integrated
Thunderbolt PCIe root port and a root port with no thunderbolt
functionality built in. Could you point that out to me?

I'm not sure how your patch protects against the following case
scenario I described earlier:
> Let's say we have a TigerLake CPU, which has integrated
> Thunderbolt/USB4 capabilities:
>
> TigerLake_ThunderboltCPU -> USB-C Port
> This device also has the ExternalFacingPort property in ACPI and lacks
> the usb4-host-interface property in the ACPI.
>
> My worry is that someone could take an Alpine Ridge Chip Thunderbolt
> Dock and attach it to the TigerLake CPU
>
> TigerLake_ThunderboltCPU -> USB-C Port -> AlpineRidge_Dock
>
> If that were to happen, this quirk would incorrectly label the Alpine
> Ridge Dock as "fixed" instead of "removable".



Build with Mika's Patch:

On Sat, May 11, 2024 at 1:43 AM Mika Westerberg
<mika.westerberg@...ux.intel.com> wrote:
>
> On Sat, May 11, 2024 at 07:38:32AM +0300, Mika Westerberg wrote:
> > They are not integrated Thunderbolt PCIe root ports.m
>
> For the clarity, Intel integrated Thunderbolt 3 controller first in Ice
> Lake, then Thunderbolt 4 controller in Tiger Lake and forward (Alder
> Lake, Raptor Lake, Meteor Lake). Anything else, including Comet Lake and
> the like are using discrete controllers such as Alpine Ridge, Titan
> Ridge (both Thunderbolt 3) and Maple Ridge (Thunderbolt 4), and Barlow
> Ridge (Thunderbolt 5) where the controller is either soldered on the
> motherboard or connected to a PCIe slot.

Thanks for the explanation!
This patch worked smoothly on the device I tried. I'd be happy to go
forward with this patch, and test it on more devices.
Is that fine? Or should I try something else on the build I made with
Lukas's commits?