On Sat, Apr 27, 2024 at 07:35:33AM +0200, Lukas Wunner wrote: > On Fri, Apr 26, 2024 at 07:52:07AM +0300, Mika Westerberg wrote: > > On Thu, Apr 25, 2024 at 05:16:24PM -0400, Esther Shimanovich wrote: > > > I did find one example of a docking station that uses the DSL6540 > > > chip, which has PCI IDs defined in include/linux/pci_ids.h: > > > #define PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_4C_NHI 0x1577 > > > #define PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_4C_BRIDGE 0x1578 > > > It seems like it has an NHI, despite being in an external, removable > > > docking station. This appears to contradict what you say about only > > > having "NHI" on a host router. I am assuming that by host router, you > > > mean the fixed discrete, fixed thunderbolt chip, or the thunderbolt > > > controller upstream to the root port. Please correct me if I got > > > anything wrong! > > > > So it goes same way with other discrete chips from Intel at least. It is > > the same silicon but the NHI is disabled on device routers. > > > > That said, it is entirely possible for a "malicious" device to pretend > > to have one so we need to be careful. > > If a device (accidentally or maliciously) exposes an NHI, the thunderbolt > driver will try to bind to it. > > Do we take any precautions to prevent that? Not at the moment but it will be behind the IOMMU so it cannot access any other memory that what is reserved for it. > AFAICS we'd be allocating a duplicate root_switch with route 0. > Seems dangerous if two driver instances talk to the same Root Switch. I don't think it even works because it cannot have topology ID of 0 if it is a device router which it is in this case since it is being first enumerated by the "real" host. That said we have not tested this either so can be 100% sure.
