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

Message-ID: <BL1PR12MB5157719E9A5C0EEBB652141BE2119@BL1PR12MB5157.namprd12.prod.outlook.com>
Date:   Wed, 16 Mar 2022 13:48:49 +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]

> > > IOMMU is active
> > >
> > > Hi Mario,
> > >
> > > On Tue, Mar 15, 2022 at 04:30:08PM -0500, Mario Limonciello wrote:
> > > > Historically TBT3 in Linux used "Thunderbolt security levels" as a primary
> > > > means of "security" against DMA attacks. This mean that users would
> need
> > > to
> > > > ack any device plugged in via userspace.  In ~2018 machines started to
> use
> > > > the IOMMU for protection, but instead of dropping security levels a
> > > > convoluted flow was introduced:
> > > > * User hotplugs device
> > > > * Driver discovers supported tunnels
> > > > * Driver emits a uevent to userspace that a PCIe tunnel is present
> > > > * Userspace reads 'iommu_dma_protection' attribute (which currently
> > > >   indicates an Intel IOMMU is present and was enabled pre-boot not
> that
> > > >   it's active "now")
> > > > * Based on that value userspace then authorizes automatically or
> prompts
> > > >   the user like how security level based support worked.
> > >
> > > There are legitimate reasons to disable PCIe tunneling even if the
> IOMMU
> > > bits are in place. The ACPI _OSC allows the boot firmware to do so and
> > > our "security levels" allows the userspace policy to do the same. I
> > > would not like to change that unless absolutely necessary.
> >
> > 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?

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?