linux-kernel - RE: [RFC] thunderbolt: Automatically authorize PCIe tunnels when IOMMU is active

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] [day] [month] [year] [list]

Message-ID: <BL1PR12MB5157B030276D735F8C340609E2119@BL1PR12MB5157.namprd12.prod.outlook.com>
Date:   Wed, 16 Mar 2022 14:56:04 +0000
From:   "Limonciello, Mario" <Mario.Limonciello@....com>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>
CC:     Andreas Noever <andreas.noever@...il.com>,
        Michael Jamet <michael.jamet@...el.com>,
        Yehezkel Bernat <YehezkelShB@...il.com>,
        "open list:THUNDERBOLT DRIVER" <linux-usb@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: RE: [RFC] thunderbolt: Automatically authorize PCIe tunnels when
 IOMMU is active

[Public]

> > > > Actually I intentionally left that in the RFC patch, to only do this based
> off
> > > > of tb_acpi_may_tunnel_pcie, so I think that should still work as you
> > > described
> > > > if boot firmware turned off PCIe tunneling.
> > >
> > > Right but if the user still wants to disable it, like say you are
> > > travelling and you want to be sure that no PCIe devices get attached
> > > while your laptop is charging from a public "charging station" (whatever
> > > is the right term).
> >
> > So wouldn't you flip the default in BIOS setup to disable PCIe tunnels then
> for
> > this use case?
> 
> What if you are on Chromebook? Or something where this is not user
> configurable?
> 
> > Otherwise with how it is today you end up with the PCIe tunnel created in
> the
> > boot FW and then coming into the OS if it's the same path the tunnel stays
> > in place with no opportunity for userspace to authorize it, no?
> 
> The boot FW does not need to support CM capabilites nor does it need to
> provide the ACPI _OSC.

Ah right - my thoughts were entirely UEFI firmware centric.  Chromebooks don't
have BIOS setup, nor do they all have the USB4 _OSC.

Then yes I agree we do need to "keep" this authorization decision in userspace.