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: Thu, 16 May 2024 13:03:15 +0300
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: Lukas Wunner <lukas@...ner.de>
Cc: Esther Shimanovich <eshimanovich@...omium.org>,
	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

On Thu, May 16, 2024 at 11:30:17AM +0300, Mika Westerberg wrote:
> Hi,
> 
> On Wed, May 15, 2024 at 10:35:22PM +0200, Lukas Wunner wrote:
> > On Wed, May 15, 2024 at 02:53:54PM -0400, Esther Shimanovich wrote:
> > > 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
> > 
> > That means that for some reason, the PCI devices are not associated with
> > the Thunderbolt ports.  Could you add this to the command line:
> > 
> >   thunderbolt.dyndbg ignore_loglevel log_buf_len=10M
> > 
> > and this to your kernel config:
> > 
> >   CONFIG_DYNAMIC_DEBUG=y
> > 
> > You should see "... is associated with ..." messages in dmesg.
> > This did work for Mika during his testing with recent Thunderbolt chips.
> > I amended the patches after his testing but wouldn't expect that to
> > cause issues.
> > 
> > @Mika, would you mind re-testing if you've got cycles to spare?
> 
> Sure, I'll try this today and update.

Okay now tried with your latest branch on Meteor Lake-P (integrated
Thunderbolt). I do get these:

[   12.911728] thunderbolt 0000:00:0d.2: 0:8: associated with 0000:00:07.0
[   12.911732] thunderbolt 0000:00:0d.2: 0:9: associated with 0000:00:07.1
..
[   13.250242] thunderbolt 0000:00:0d.3: 0:8: associated with 0000:00:07.2
[   13.250245] thunderbolt 0000:00:0d.3: 0:9: associated with 0000:00:07.3

The adapters 8 and 9 are PCIe as expected

# tbadapters -r 0 -a 8 -a 9
 8: PCIe Down                     Disabled  
 9: PCIe Down                     Disabled  

# tbadapters -d1 -r 0 -a 8 -a 9
 8: PCIe Down                     Disabled  
 9: PCIe Down                     Disabled  

And the 07.[0-3] are the PCIe Thunderbolt Root Ports:

# lspci
..
00:07.0 PCI bridge: Intel Corporation Meteor Lake-P Thunderbolt 4 PCI Express Root Port #0 (rev 10)
00:07.1 PCI bridge: Intel Corporation Meteor Lake-P Thunderbolt 4 PCI Express Root Port #1 (rev 10)
00:07.2 PCI bridge: Intel Corporation Meteor Lake-P Thunderbolt 4 PCI Express Root Port #2 (rev 10)
00:07.3 PCI bridge: Intel Corporation Meteor Lake-P Thunderbolt 4 PCI Express Root Port #3 (rev 10)
..