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
Date: Wed, 16 Mar 2022 15:42:14 +0200 [thread overview]
Message-ID: <YjHpNloXEvPpv1In@lahna> (raw)
In-Reply-To: <BL1PR12MB5157349C626E3818B813D9A0E2119@BL1PR12MB5157.namprd12.prod.outlook.com>
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).
next prev parent reply other threads:[~2022-03-16 13:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-15 21:30 [RFC] thunderbolt: Automatically authorize PCIe tunnels when IOMMU is active Mario Limonciello
2022-03-16 6:30 ` Mika Westerberg
2022-03-16 13:06 ` Limonciello, Mario
2022-03-16 13:42 ` Mika Westerberg [this message]
2022-03-16 13:48 ` Limonciello, Mario
2022-03-16 14:39 ` Mika Westerberg
2022-03-16 14:56 ` Limonciello, Mario
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YjHpNloXEvPpv1In@lahna \
--to=mika.westerberg@linux.intel.com \
--cc=Mario.Limonciello@amd.com \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=michael.jamet@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox