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, 2 May 2024 13:07:40 +0300
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: Mario Limonciello <mario.limonciello@....com>
Cc: Esther Shimanovich <eshimanovich@...omium.org>,
	Lukas Wunner <lukas@...ner.de>,
	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 02, 2024 at 04:54:56AM -0500, Mario Limonciello wrote:
> On 5/1/2024 23:38, Mika Westerberg wrote:
> > Hi,
> > 
> > On Wed, May 01, 2024 at 06:23:28PM -0400, Esther Shimanovich wrote:
> > > I don’t have this device available at my office. I just saw that
> > > StarTech sells a universal laptop docking station with chipset-id
> > > Intel - Alpine Ridge DSL6540. Then I looked up the device, and found
> > > it here: https://linux-hardware.org/?id=pci:8086-1577-8086-0000
> > > 
> > > Therefore, I concluded that the DSL6540 has an NHI component.
> > 
> > Okay understood. Yes Alpine Ridge can be both host and device router. In
> > device configuration such as the above it does not expose NHI. If it is
> > host as in the above list you shared then it includes one.
> 
> There are different PCI IDs for AR for host vs device though, right?

No they are the same. Well I think Titan Ridge has different for device.

Here's my system with AR host and AR dock:

06:00.0 0604: 8086:15d3 (rev 02)
07:00.0 0604: 8086:15d3 (rev 02)
07:01.0 0604: 8086:15d3 (rev 02)
07:02.0 0604: 8086:15d3 (rev 02)
07:04.0 0604: 8086:15d3 (rev 02)
08:00.0 0880: 8086:15d2 (rev 02)

09:00.0 0604: 8086:15d3 (rev 02)
0a:00.0 0604: 8086:15d3 (rev 02)
0a:01.0 0604: 8086:15d3 (rev 02)
0a:02.0 0604: 8086:15d3 (rev 02)
0a:03.0 0604: 8086:15d3 (rev 02)
0a:04.0 0604: 8086:15d3 (rev 02)

> But I guess that could technically be spoofed.
> Is there a fixed PCI ID for the RP used to tunnel for host AR?

No, I don't think so. The Root Port can be anything even non-Intel.

> If so you could special case that anything connected to that PCI ID for RP
> used to tunnel isn't trusted.

None of the PCIe tunnels are trusted. We have IOMMU already in place
that blocks accesses outside. Also it is not possible to have anoter
host router in a domain because:

* The connection manager in the real host router needs to enumerate the
  device router before any tunnels can be established.

* Once it does that it has TopologyID > 0 so it is not a host router and
  cannot receive packets with CM bit set in the route string.

* If it still exposes a PCIe endpoint with NHI that is behind a PCIe
  tunnel from the host router PCIe downstream port so it is behind the full IOMMU
  mappings (as these ports are "external_facing").

Yes if there is such PCIe device the Thunderbolt driver may attach to it
but I don't see what the harm would be since it cannot really affect the
topology (except maybe trying to crash the driver by sending unexpected
replies, or so).