[PATCH 0/2] Add Apple T2 NHI device links

[PATCH 0/2] Add Apple T2 NHI device links

[Atharva Tiwari]

This series adds a cached flag to detect Apple T2 systems, then uses it
to create device links for the Thunderbolt NHI.

Atharva Tiwari (2):
  treewide: Add a flag to detect the Apple T2 chip
  thunderbolt: Add device links for Apple T2 NHI

 arch/x86/pci/fixup.c                          | 10 ++++
 drivers/thunderbolt/tb.c                      | 49 +++++++++++++++++++
 include/linux/platform_data/x86/apple.h       |  5 ++
 security/integrity/platform_certs/load_uefi.c | 38 +++-----------
 4 files changed, 72 insertions(+), 30 deletions(-)

-- 
2.43.0

[PATCH 1/2] treewide: Add a flag to detect the Apple T2 chip

[Atharva Tiwari]

Add a flag to detect Apple T2 chips on Intel Macs.
Cache the result to avoid repeated checks. That will
be used in upcoming patches.

Signed-off-by: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
---
 arch/x86/pci/fixup.c                          | 10 +++++
 include/linux/platform_data/x86/apple.h       |  5 +++
 security/integrity/platform_certs/load_uefi.c | 38 ++++---------------
 3 files changed, 23 insertions(+), 30 deletions(-)

diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index b301c6c8df75..fbd204ca4c6d 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -7,6 +7,7 @@
 #include <linux/delay.h>
 #include <linux/dmi.h>
 #include <linux/pci.h>
+#include <linux/platform_data/x86/apple.h>
 #include <linux/suspend.h>
 #include <linux/vgaarb.h>
 #include <asm/amd/node.h>
@@ -995,6 +996,15 @@ static void asus_disable_nvme_d3cold(struct pci_dev *pdev)
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x9a09, asus_disable_nvme_d3cold);
 
+bool has_t2_chip;
+EXPORT_SYMBOL(has_t2_chip);
+
+static void apple_has_t2_chip(struct pci_dev *pdev)
+{
+	has_t2_chip = true;
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_APPLE, 0x1801, apple_has_t2_chip);
+
 #ifdef CONFIG_SUSPEND
 /*
  * Root Ports on some AMD SoCs advertise PME_Support for D3hot and D3cold, but
diff --git a/include/linux/platform_data/x86/apple.h b/include/linux/platform_data/x86/apple.h
index 079e816c3c21..a2ab63bd1eac 100644
--- a/include/linux/platform_data/x86/apple.h
+++ b/include/linux/platform_data/x86/apple.h
@@ -6,8 +6,13 @@
  * x86_apple_machine - whether the machine is an x86 Apple Macintosh
  */
 extern bool x86_apple_machine;
+/**
+ * has_t2_chip - whether the machine has the Apple T2 chip
+ */
+extern bool has_t2_chip;
 #else
 #define x86_apple_machine false
+#define has_t2_chip false
 #endif
 
 #endif
diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
index c0d6948446c3..da57ac322e72 100644
--- a/security/integrity/platform_certs/load_uefi.c
+++ b/security/integrity/platform_certs/load_uefi.c
@@ -3,42 +3,16 @@
 #include <linux/kernel.h>
 #include <linux/sched.h>
 #include <linux/cred.h>
-#include <linux/dmi.h>
 #include <linux/err.h>
 #include <linux/efi.h>
 #include <linux/slab.h>
 #include <linux/ima.h>
+#include <linux/platform_data/x86/apple.h>
 #include <keys/asymmetric-type.h>
 #include <keys/system_keyring.h>
 #include "../integrity.h"
 #include "keyring_handler.h"
 
-/*
- * On T2 Macs reading the db and dbx efi variables to load UEFI Secure Boot
- * certificates causes occurrence of a page fault in Apple's firmware and
- * a crash disabling EFI runtime services. The following quirk skips reading
- * these variables.
- */
-static const struct dmi_system_id uefi_skip_cert[] = {
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro15,1") },
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro15,2") },
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro15,3") },
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro15,4") },
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro16,1") },
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro16,2") },
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro16,3") },
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro16,4") },
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookAir8,1") },
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookAir8,2") },
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookAir9,1") },
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "Macmini8,1") },
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacPro7,1") },
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "iMac20,1") },
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "iMac20,2") },
-	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "iMacPro1,1") },
-	{ }
-};
-
 /*
  * Look to see if a UEFI variable called MokIgnoreDB exists and return true if
  * it does.
@@ -165,10 +139,14 @@ static int __init load_uefi_certs(void)
 	unsigned long dbsize = 0, dbxsize = 0, mokxsize = 0;
 	efi_status_t status;
 	int rc = 0;
-	const struct dmi_system_id *dmi_id;
 
-	dmi_id = dmi_first_match(uefi_skip_cert);
-	if (dmi_id) {
+	/*
+	 * On T2 Macs reading the db and dbx efi variables to load UEFI Secure Boot
+	 * certificates causes occurrence of a page fault in Apple's firmware and
+	 * a crash disabling EFI runtime services. The following quirk skips reading
+	 * these variables.
+	 */
+	if (has_t2_chip) {
 		pr_err("Reading UEFI Secure Boot Certs is not supported on T2 Macs.\n");
 		return false;
 	}
-- 
2.43.0

[PATCH 2/2] thunderbolt: Add device links for Apple T2 NHI

[Atharva Tiwari]

From: Andre Eikmeyer <andre@negmaster.com>

Thunderbolt NHI on T2 Macs (2018-2020). The NHI and its
associated PCIe root ports all sit directly on the root complex
with no upstream port. Apple's ACPI tables name Thunderbolt root
ports as TRP0, TRP1, etc. Find them and create device links back
to the NHI so that PCIe tunnels can be re-established after sleep.

Co-developed-by: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
Signed-off-by: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>

Signed-off-by: Andre Eikmeyer <andre@negmaster.com>
---
 drivers/thunderbolt/tb.c | 49 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
index c69c323e6952..26529141573a 100644
--- a/drivers/thunderbolt/tb.c
+++ b/drivers/thunderbolt/tb.c
@@ -6,6 +6,7 @@
  * Copyright (C) 2019, Intel Corporation
  */
 
+#include <linux/acpi.h>
 #include <linux/slab.h>
 #include <linux/errno.h>
 #include <linux/delay.h>
@@ -3310,6 +3311,54 @@ static bool tb_apple_add_links(struct tb_nhi *nhi)
 	if (!x86_apple_machine)
 		return false;
 
+	/* On T2 Macs. the root ports are stored in ACPI as TRP0,
+	 * TRP1, etc. Find them and create device links
+	 * so that PCIe tunnels can be re-established after
+	 * sleep.
+	 */
+	if (has_t2_chip) {
+		struct acpi_device *adev;
+		unsigned int slot, func;
+		const struct device_link *link;
+		const char *bid;
+
+		for (slot = 0; slot < 32; slot++) {
+			for (func = 0; func < 8; func++) {
+				pdev = pci_get_slot(nhi->pdev->bus, PCI_DEVFN(slot, func));
+				if (!pdev)
+					continue;
+
+				if (!pci_is_pcie(pdev) || pci_pcie_type(pdev) !=
+						PCI_EXP_TYPE_ROOT_PORT)
+					goto put_pdev;
+
+				adev = ACPI_COMPANION(&pdev->dev);
+				if (!adev)
+					goto put_pdev;
+
+				bid = acpi_device_bid(adev);
+				if (!bid || strncmp(bid, "TRP", 3) != 0)
+					goto put_pdev;
+
+				link = device_link_add(&pdev->dev, &nhi->pdev->dev,
+						DL_FLAG_AUTOREMOVE_SUPPLIER |
+						DL_FLAG_PM_RUNTIME);
+				if (link) {
+					dev_dbg(&nhi->pdev->dev, "created link from %s\n",
+						dev_name(&pdev->dev));
+					ret = true;
+				} else
+					dev_warn(&nhi->pdev->dev,
+						"device link creation from %s failed\n",
+						dev_name(&pdev->dev));
+
+put_pdev:
+	pci_dev_put(pdev);
+			}
+		}
+		return ret;
+	}
+
 	switch (nhi->pdev->device) {
 	case PCI_DEVICE_ID_INTEL_LIGHT_RIDGE:
 	case PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C:
-- 
2.43.0

Re: [PATCH 2/2] thunderbolt: Add device links for Apple T2 NHI

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The boolean variable `ret` is returned uninitialized when `has_t2_chip` is true and no device links are successfully created.
--

--- Patch [2]: [PATCH 2/2] thunderbolt: Add device links for Apple T2 NHI ---
Note: The format of this report has been altered to provide a free-form summary
of the findings rather than inline diff quoting, due to recitation restrictions
on the original patch code.

commit 02f82ba0cab274de03252dcd3722c98f27a73abf
Author: Andre Eikmeyer <andre@negmaster.com>
thunderbolt: Add device links for Apple T2 NHI

This commit adds support for Thunderbolt NHI on T2 Macs by searching for root
ports in ACPI named TRP0, TRP1, etc. It creates device links back to the NHI
so that PCIe tunnels can be re-established after sleep.

[Severity: High]
Could this return an uninitialized value?

In tb_apple_add_links(), the boolean variable ret is declared without an
initial value. If the system has a T2 chip, the code enters a nested loop
searching for PCIe root ports to link. If no root ports match the required
ACPI prefix, or if device link creation fails for all found ports, the loops
complete and the function returns ret without ever having assigned it.

If the uninitialized stack value evaluates to true, might this cause the
caller to incorrectly assume device links were successfully established,
potentially skipping necessary fallback paths like tb_acpi_add_links?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260719180308.1398-1-atharvatiwarilinuxdev@gmail.com?part=2

Re: [PATCH 1/2] treewide: Add a flag to detect the Apple T2 chip

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Spoofable PCI device check allows local attackers to bypass UEFI Secure Boot revocations.
- [Medium] T2 Macs will suffer an EFI firmware crash if PCI enumeration is bypassed or disabled.
- [Low] Linking fails with an undefined reference to `has_t2_chip` on x86 architectures when `CONFIG_PCI` is disabled.
- [Low] The globally exported variable `has_t2_chip` uses a dangerously generic name.
--

--- Patch [1]: [PATCH 1/2] treewide: Add a flag to detect the Apple T2 chip ---
commit 371f6a2037c381d85697cd4a6b5cede313505414
Author: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>

treewide: Add a flag to detect the Apple T2 chip

This patch adds a flag to detect Apple T2 chips using a PCI early fixup.
It caches the result and replaces the existing DMI-based quirk in the EFI
certificate loading code to avoid repeated checks.

> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c

[ ... ]

> @@ -995,6 +996,15 @@ static void asus_disable_nvme_d3cold(struct pci_dev *pdev)
>  }
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x9a09, asus_disable_nvme_d3cold);
>  
> +bool has_t2_chip;
> +EXPORT_SYMBOL(has_t2_chip);

[Severity: Low]
Since arch/x86/pci/fixup.c is only compiled when CONFIG_PCI is enabled, will
this cause a link-time build failure on x86 if a kernel is configured with
CONFIG_PCI=n and CONFIG_LOAD_UEFI_KEYS=y?

The declaration in include/linux/platform_data/x86/apple.h is active for all
x86 builds, so the missing definition would only be caught at link time.

[Severity: Low]
Is has_t2_chip too generic of a name for a globally exported symbol?

Exporting such a generic name to the global namespace might increase the risk
of symbol collisions with other components or out-of-tree modules.

> +
> +static void apple_has_t2_chip(struct pci_dev *pdev)
> +{
> +	has_t2_chip = true;
> +}
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_APPLE, 0x1801, apple_has_t2_chip);

[Severity: High]
Can this unconditional PCI fixup be spoofed by an external hotplug device?

If an attacker connects a malicious PCIe device (such as via Thunderbolt)
that spoofs this Vendor and Device ID before boot, has_t2_chip will be set
globally.

This would cause load_uefi_certs() to skip loading the dbx revocation list,
potentially allowing revoked, malicious kexec payloads or modules to bypass
Secure Boot.

[Severity: Medium]
What happens to actual T2 Macs if the kernel is booted with pci=off or if
PCI enumeration fails?

If the PCI subsystem does not initialize, this fixup will never run and
has_t2_chip will remain false.

This would cause load_uefi_certs() to attempt reading the db and dbx UEFI
variables, triggering a page fault in Apple's firmware and crashing EFI
runtime services on these machines.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260719180308.1398-1-atharvatiwarilinuxdev@gmail.com?part=1