Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Wed, 16 Mar 2022 15:42:14 +0200
From:   Mika Westerberg <mika.westerberg@linux.intel.com>
To:     "Limonciello, Mario" <Mario.Limonciello@amd.com>
Cc:     Andreas Noever <andreas.noever@gmail.com>,
        Michael Jamet <michael.jamet@intel.com>,
        Yehezkel Bernat <YehezkelShB@gmail.com>,
        "open list:THUNDERBOLT DRIVER" <linux-usb@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] thunderbolt: Automatically authorize PCIe tunnels when
 IOMMU is active
Message-ID: <YjHpNloXEvPpv1In@lahna>
References: <20220315213008.5357-1-mario.limonciello@amd.com>
 <YjGD7N++F+ioISHb@lahna>
 <BL1PR12MB5157349C626E3818B813D9A0E2119@BL1PR12MB5157.namprd12.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BL1PR12MB5157349C626E3818B813D9A0E2119@BL1PR12MB5157.namprd12.prod.outlook.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Precedence: bulk

On Wed, Mar 16, 2022 at 01:06:24PM +0000, Limonciello, Mario wrote:
> [AMD Official Use Only]
> 
> 
> 
> > -----Original Message-----
> > From: Mika Westerberg <mika.westerberg@linux.intel.com>
> > Sent: Wednesday, March 16, 2022 01:30
> > To: Limonciello, Mario <Mario.Limonciello@amd.com>
> > Cc: Andreas Noever <andreas.noever@gmail.com>; Michael Jamet
> > <michael.jamet@intel.com>; Yehezkel Bernat <YehezkelShB@gmail.com>;
> > open list:THUNDERBOLT DRIVER <linux-usb@vger.kernel.org>; open list
> > <linux-kernel@vger.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.

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).