lkml.org 
[lkml]   [2022]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [RFC] thunderbolt: Automatically authorize PCIe tunnels when IOMMU is active
Date
[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?

\
 
 \ /
  Last update: 2022-09-17 16:17    [W:0.453 / U:1.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site