Re: [PATCH v3 00/36] thunderbolt: Software connection manager improvements

[Mika Westerberg]

On Mon, Apr 01, 2019 at 06:31:11AM +0200, Lukas Wunner wrote:
> On Thu, Mar 28, 2019 at 06:56:21PM +0200, Mika Westerberg wrote:
> > On Thu, Mar 28, 2019 at 03:17:57PM +0000, Mario.Limonciello@xxxxxxxx wrote:
> > > > From: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
> > > > Sent: Thursday, March 28, 2019 7:36 AM
> > > >   * Do not automatically create PCIe tunnels. Instead we implement "user"
> > > >     security level in the software connection manager as well taking
> > > >     advantage of the existing sysfs interfaces. This allows user to disable
> > > >     PCIe tunneling completely or implement different white listing
> > > >     policies. Major distros include bolt system daemon that takes care of
> > > >     this.
> > > 
> > > This is a bit unfortunate.  Is this because of IOMMU limitations in working
> > > with devices down the chain?
> > 
> > No, it just makes it possible to do things such as "disable all PCIe
> > tunneling", like the master switch we have in GNOME UI.
> 
> It appears to be a change in behavior though as PCIe tunnels are
> currently established automatically on Macs which don't use ICM.
> The change might be considered breaking userspace, not sure.

I don't think userspace is breaking here. The userspace interface we
provide is through sysfs and only change we do in this series that could
affect is in the patch 05. I Cc'd Mario and Christian just to make sure
fwupd and bolt still keep working (these are the two userspace
applications using the interface AFAIK).

I think you mean user experience instead. It should not affect because
if you run any major distro all the components including GNOME UI are
prepared to handle this.

> Also on macOS it's just plug and play without any need to configure
> whitelists or anything.

macOS does have whitelist too. If you plug in unsupported device you
don't get to use it and it is listed as "unsupported" in the system
report. I'm not sure if end users can tune the list.

In Linux side I would really like to make it possible to implement
whitelisting and disabling PCIe tunneling, and since we already have the
interface for that (the sysfs ABI) it only makes sense to use it. That
interface allows userspace to implement different kinds of policies from
disabling all PCIe tunneling to allowing everything (it can be done
using simple udev rule).