linux-kernel - RE: [PATCH] thunderbolt: Stop using iommu

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BL1PR12MB515762E68F3A48A97EB2DC89E2119@BL1PR12MB5157.namprd12.prod.outlook.com>
Date:   Wed, 16 Mar 2022 17:24:38 +0000
From:   "Limonciello, Mario" <Mario.Limonciello@....com>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Robin Murphy <robin.murphy@....com>
CC:     "andreas.noever@...il.com" <andreas.noever@...il.com>,
        "michael.jamet@...el.com" <michael.jamet@...el.com>,
        "YehezkelShB@...il.com" <YehezkelShB@...il.com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        "hch@....de" <hch@....de>
Subject: RE: [PATCH] thunderbolt: Stop using iommu_present()

[Public]

> On Wed, Mar 16, 2022 at 02:49:09PM +0000, Robin Murphy wrote:
> > > What we want is to make sure the Tunneled PCIe ports get the full
> IOMMU
> > > protection. In case of the discrete above it is also fine if all the
> > > devices behind the PCIe root port get the full IOMMU protection. Note in
> > > the integrated all the devices are "siblings".
> >
> > Ah, OK, I wasn't aware that the NHI isn't even the right thing in the first
> > place :(
> >
> > Is there an easy way to get from the struct tb to a PCI device representing
> > the end of its relevant tunnel, or do we have a circular dependency
> problem
> > where the latter won't appear until we've authorised it (and thus the
> IOMMU
> > layer won't know about it yet either)?
> 
> The PCIe root ports (and the PCIe downstream ports) are there already
> even without "authorization".
> 
> There is a way to figure out the "tunneled" PCIe ports by looking at
> certain properties and we do that already actually. The BIOS has the
> following under these ports:
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> .microsoft.com%2Fen-us%2Fwindows-hardware%2Fdrivers%2Fpci%2Fdsd-
> for-pcie-root-ports%23identifying-externally-exposed-pcie-root-
> ports&amp;data=04%7C01%7Cmario.limonciello%40amd.com%7C0465d319a
> 6684335d9c208da07710e7c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7
> C0%7C637830479402895833%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am
> p;sdata=z6hpYGpj%2B%2BVvz9d6MXiO4N66PUm4zwhOdI%2Br6l3PjhQ%3D
> &amp;reserved=0
> 
> and the ports will have dev->external_facing set to 1. Perhaps looking
> at that field helps here?

External facing isn't a guarantee from the firmware though.  It's something we
all expect in practice, but I think it's better to look at the ones that are from
the _DSD usb4-host-interface to be safer.

Mika, you might not have seen it yet, but I sent a follow up diff in this thread
to Robin's patch.  If that looks good Robin can submit a v2 (or I'm happy to do
so as well as I confirmed it helps my original intent too).