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

[sashiko-bot@kernel.org]

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