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]

Date:   Wed, 16 Mar 2022 13:06:24 +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

[AMD Official Use Only]



> -----Original Message-----
> From: Mika Westerberg <mika.westerberg@...ux.intel.com>
> Sent: Wednesday, March 16, 2022 01:30
> To: Limonciello, Mario <Mario.Limonciello@....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
> 
> 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.