[RFC] thunderbolt: Automatically authorize PCIe tunnels when IOMMU is active

[Mario Limonciello]

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.

This is further confused because a pre-OS CM may authorize PCIe tunnels
and the Linux USB4 CM will re-use tunnels if the paths discovered are the
same. This means if you plug in a dock pre-boot it works in Linux
immediately, but if you plug it in after boot you need to authorize it with
userspace.

All the hand waving malarkey should be unnecessary when the IOMMU
translation layer is active.
* First detect that the firmware has allowed PCIe tunnels to be created.
* Then check if an IOMMU domain is assigned to the NHI.
  - If it is, set TBT security level to "NONE".
  - If it is not, leave things as before.
* Lastly when a port is scanned via `tb_scan_port`, check the security
  level.
* If it was set as "NONE", create the PCIe tunnel and update the
  'authorized' attribute to reflect this.

Link: https://lore.kernel.org/linux-iommu/20220315162455.5190-1-mario.limonciello@xxxxxxx/T/#mbe71d35c27bb91f6f9781eba7676d38ca467f6d5
Signed-off-by: Mario Limonciello <mario.limonciello@xxxxxxx>
---
Remaining items to be done/investigated/discussed:
 * Documentation updates for this
 * Is this a good enough method to check IOMMU is active?
 * Should the IOMMU check be on PCIe root port for tunneling instead
   of the router? If so, need to discover it via the device link
   (possibly at time of device link creation).
 * Maybe create a TBT new security level definition "iommu" that
   functionally behaves same to "none" to make things clearer to userspace
   how the device was authorized.
 * Drop iommu_dma_protection attribute?
 drivers/thunderbolt/tb.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
index cbd0ad85ffb1..eaa8429e0156 100644
--- a/drivers/thunderbolt/tb.c
+++ b/drivers/thunderbolt/tb.c
@@ -6,6 +6,7 @@
  * Copyright (C) 2019, Intel Corporation
  */
 
+#include <linux/iommu.h>
 #include <linux/slab.h>
 #include <linux/errno.h>
 #include <linux/delay.h>
@@ -18,6 +19,8 @@
 
 #define TB_TIMEOUT	100 /* ms */
 
+static int tb_tunnel_pci(struct tb *tb, struct tb_switch *sw);
+
 /**
  * struct tb_cm - Simple Thunderbolt connection manager
  * @tunnel_list: List of active tunnels
@@ -690,6 +693,16 @@ static void tb_scan_port(struct tb_port *port)
 	if (tcm->hotplug_active && tb_tunnel_usb3(sw->tb, sw))
 		tb_sw_warn(sw, "USB3 tunnel creation failed\n");
 
+	/*
+	 * Create PCIe tunnels if security has been turned off
+	 * (such as by IOMMU translation enabled)
+	 */
+	if (port->sw->tb->security_level == TB_SECURITY_NONE) {
+		if (tb_tunnel_pci(port->sw->tb, sw))
+			tb_sw_warn(sw, "PCIe tunnel creation failed\n");
+		else
+			sw->authorized = 1;
+	}
 	tb_add_dp_resources(sw);
 	tb_scan_switch(sw);
 }
@@ -1702,7 +1715,8 @@ struct tb *tb_probe(struct tb_nhi *nhi)
 		return NULL;
 
 	if (tb_acpi_may_tunnel_pcie())
-		tb->security_level = TB_SECURITY_USER;
+		tb->security_level = iommu_get_domain_for_dev(&nhi->pdev->dev) ?
+			TB_SECURITY_NONE : TB_SECURITY_USER;
 	else
 		tb->security_level = TB_SECURITY_NOPCIE;
 
-- 
2.34.1