All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Mario Limonciello <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 08:30:04 +0200	[thread overview]
Message-ID: <YjGD7N++F+ioISHb@lahna> (raw)
In-Reply-To: <20220315213008.5357-1-mario.limonciello@amd.com>

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.

  reply	other threads:[~2022-03-16  6:30 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 [this message]
2022-03-16 13:06   ` Limonciello, Mario
2022-03-16 13:42     ` Mika Westerberg
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=YjGD7N++F+ioISHb@lahna \
    --to=mika.westerberg@linux.intel.com \
    --cc=YehezkelShB@gmail.com \
    --cc=andreas.noever@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.