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]
Message-ID: <20190401074401.GO3622@lahna.fi.intel.com>
Date:   Mon, 1 Apr 2019 10:44:01 +0300
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     Mario.Limonciello@...l.com, linux-kernel@...r.kernel.org,
        michael.jamet@...el.com, YehezkelShB@...il.com,
        andreas.noever@...il.com, andriy.shevchenko@...ux.intel.com,
        ckellner@...hat.com
Subject: Re: [PATCH v3 00/36] thunderbolt: Software connection manager
 improvements

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@...l.com wrote:
> > > > From: Mika Westerberg <mika.westerberg@...ux.intel.com>
> > > > 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).

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ