All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: "Limonciello, Mario" <Mario.Limonciello@amd.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
	"michael.jamet@intel.com" <michael.jamet@intel.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"YehezkelShB@gmail.com" <YehezkelShB@gmail.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"andreas.noever@gmail.com" <andreas.noever@gmail.com>,
	"hch@lst.de" <hch@lst.de>
Subject: Re: [PATCH] thunderbolt: Stop using iommu_present()
Date: Thu, 17 Mar 2022 08:30:10 +0200	[thread overview]
Message-ID: <YjLVcnl1qfdoDf48@lahna> (raw)
In-Reply-To: <BL1PR12MB5157380CD6FD9EB83E76CBB0E2119@BL1PR12MB5157.namprd12.prod.outlook.com>

Hi Mario,

On Wed, Mar 16, 2022 at 06:34:51PM +0000, Limonciello, Mario wrote:
> > Might it be reasonable for the Thunderbolt core to check early on if any
> > tunnelled ports are not marked as external facing, and if so just tell
> > the user that iommu_dma_protection is off the table and anything they
> > authorise is at their own risk?
> > 
> > Robin.
> 
> How about in iommu_dma_protection_show to just check that all the device
> links to the NHI are marked as untrusted?

Actually this does not work either because we have pre-USB4 systems out
there that are using firmware based connection manager and do not set
the "device links" (as it is only needed for USB4 software based
connection manager systems).

So only thing we can use is the ->external_facing (and ->untrusted) as
those exists in all these systems (well assuming the BIOS provided them
but this is Microsoft requirement in the same way with the DMAR bit).

[For those who are not familiar with the connection manager, it is the
 software or firmware that actually creates the tunnels over the
 Thunderbolt/USB4 fabric. In Intel systems up to Alder Lake it used to be
 firmware based, and from Alder Lake and beyond it is software based
 meaning that the Linux Thunderbolt driver creates the tunnels. Apple
 systems have been software based from the beginnning.]

WARNING: multiple messages have this Message-ID (diff)
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: "Limonciello, Mario" <Mario.Limonciello@amd.com>
Cc: "michael.jamet@intel.com" <michael.jamet@intel.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"andreas.noever@gmail.com" <andreas.noever@gmail.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"YehezkelShB@gmail.com" <YehezkelShB@gmail.com>,
	Robin Murphy <robin.murphy@arm.com>, "hch@lst.de" <hch@lst.de>
Subject: Re: [PATCH] thunderbolt: Stop using iommu_present()
Date: Thu, 17 Mar 2022 08:30:10 +0200	[thread overview]
Message-ID: <YjLVcnl1qfdoDf48@lahna> (raw)
In-Reply-To: <BL1PR12MB5157380CD6FD9EB83E76CBB0E2119@BL1PR12MB5157.namprd12.prod.outlook.com>

Hi Mario,

On Wed, Mar 16, 2022 at 06:34:51PM +0000, Limonciello, Mario wrote:
> > Might it be reasonable for the Thunderbolt core to check early on if any
> > tunnelled ports are not marked as external facing, and if so just tell
> > the user that iommu_dma_protection is off the table and anything they
> > authorise is at their own risk?
> > 
> > Robin.
> 
> How about in iommu_dma_protection_show to just check that all the device
> links to the NHI are marked as untrusted?

Actually this does not work either because we have pre-USB4 systems out
there that are using firmware based connection manager and do not set
the "device links" (as it is only needed for USB4 software based
connection manager systems).

So only thing we can use is the ->external_facing (and ->untrusted) as
those exists in all these systems (well assuming the BIOS provided them
but this is Microsoft requirement in the same way with the DMAR bit).

[For those who are not familiar with the connection manager, it is the
 software or firmware that actually creates the tunnels over the
 Thunderbolt/USB4 fabric. In Intel systems up to Alder Lake it used to be
 firmware based, and from Alder Lake and beyond it is software based
 meaning that the Linux Thunderbolt driver creates the tunnels. Apple
 systems have been software based from the beginnning.]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  parent reply	other threads:[~2022-03-17  6:30 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-16 11:25 [PATCH] thunderbolt: Stop using iommu_present() Robin Murphy
2022-03-16 11:25 ` Robin Murphy
2022-03-16 12:45 ` Mika Westerberg
2022-03-16 12:45   ` Mika Westerberg
2022-03-16 14:49   ` Robin Murphy
2022-03-16 14:49     ` Robin Murphy
2022-03-16 17:18     ` Mika Westerberg
2022-03-16 17:18       ` Mika Westerberg
2022-03-16 17:24       ` Limonciello, Mario
2022-03-16 17:24         ` Limonciello, Mario via iommu
2022-03-16 17:37         ` Mika Westerberg
2022-03-16 17:37           ` Mika Westerberg
2022-03-16 17:49           ` Robin Murphy
2022-03-16 17:49             ` Robin Murphy
2022-03-16 17:53             ` Limonciello, Mario
2022-03-16 17:53               ` Limonciello, Mario via iommu
2022-03-16 18:08               ` Limonciello, Mario
2022-03-16 18:08                 ` Limonciello, Mario via iommu
2022-03-16 18:22               ` Robin Murphy
2022-03-16 18:22                 ` Robin Murphy
2022-03-16 18:34                 ` Limonciello, Mario
2022-03-16 18:34                   ` Limonciello, Mario via iommu
2022-03-16 19:17                   ` Robin Murphy
2022-03-16 19:17                     ` Robin Murphy
2022-03-16 19:25                     ` Limonciello, Mario
2022-03-16 19:25                       ` Limonciello, Mario via iommu
2022-03-17  8:08                     ` Mika Westerberg
2022-03-17  8:08                       ` Mika Westerberg
2022-03-17 13:42                       ` Robin Murphy
2022-03-17 13:42                         ` Robin Murphy
2022-03-17 14:21                         ` Mika Westerberg
2022-03-17 14:21                           ` Mika Westerberg
2022-03-17  6:30                   ` Mika Westerberg [this message]
2022-03-17  6:30                     ` Mika Westerberg
2022-03-16 14:49   ` Limonciello, Mario
2022-03-16 14:49     ` Limonciello, Mario via iommu

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=YjLVcnl1qfdoDf48@lahna \
    --to=mika.westerberg@linux.intel.com \
    --cc=Mario.Limonciello@amd.com \
    --cc=YehezkelShB@gmail.com \
    --cc=andreas.noever@gmail.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=michael.jamet@intel.com \
    --cc=robin.murphy@arm.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.