* Re: [PATCH v3 1/2] treewide: Add a flag to detect the Apple T2 chip
From: Jarkko Sakkinen @ 2026-07-21 10:57 UTC (permalink / raw)
To: Atharva Tiwari
Cc: Bjorn Helgaas, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Andreas Noever, Mika Westerberg,
Yehezkel Bernat, Hans de Goede, Ilpo Järvinen, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Paul Moore,
James Morris, Serge E. Hallyn, linux-pci, linux-kernel, linux-usb,
platform-driver-x86, linux-integrity, keyrings,
linux-security-module
In-Reply-To: <20260721063412.11588-2-atharvatiwarilinuxdev@gmail.com>
On Tue, Jul 21, 2026 at 02:34:06AM -0400, Atharva Tiwari wrote:
> 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/kernel/quirks.c | 105 ++++++++++++++++++
> include/linux/platform_data/x86/apple.h | 5 +
> .../platform_certs/keyring_handler.h | 8 --
> security/integrity/platform_certs/load_uefi.c | 38 ++-----
> 4 files changed, 118 insertions(+), 38 deletions(-)
>
> diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
> index a92f18db9610..300d6436060d 100644
> --- a/arch/x86/kernel/quirks.c
> +++ b/arch/x86/kernel/quirks.c
> @@ -664,8 +664,113 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x2083, quirk_intel_purley_xeon_ras
> bool x86_apple_machine;
> EXPORT_SYMBOL(x86_apple_machine);
>
> +bool has_apple_t2_chip;
> +EXPORT_SYMBOL(has_apple_t2_chip);
> +
> +static const struct dmi_system_id apple_t2_devices[] __initconst = {
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,1"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,2"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,3"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,4"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,1"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,2"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,3"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,4"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir8,1"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir8,2"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir9,1"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Macmini8,1"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacPro7,1"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "iMac20,1"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "iMac20,2"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "iMacPro1,1"),
> + },
> + },
> + { }
> +};
> +
> void __init early_platform_quirks(void)
> {
> x86_apple_machine = dmi_match(DMI_SYS_VENDOR, "Apple Inc.") ||
> dmi_match(DMI_SYS_VENDOR, "Apple Computer, Inc.");
> +
> + has_apple_t2_chip = dmi_check_system(apple_t2_devices);
> }
> diff --git a/include/linux/platform_data/x86/apple.h b/include/linux/platform_data/x86/apple.h
> index 079e816c3c21..47b27dceab18 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_apple_t2_chip - whether the machine has the Apple T2 chip
> + */
> +extern bool has_apple_t2_chip;
> #else
> #define x86_apple_machine false
> +#define has_apple_t2_chip false
> #endif
>
> #endif
> diff --git a/security/integrity/platform_certs/keyring_handler.h b/security/integrity/platform_certs/keyring_handler.h
> index f92895cc50f6..a355f4400179 100644
> --- a/security/integrity/platform_certs/keyring_handler.h
> +++ b/security/integrity/platform_certs/keyring_handler.h
> @@ -45,11 +45,3 @@ efi_element_handler_t get_handler_for_code_signing_keys(const efi_guid_t *sig_ty
> efi_element_handler_t get_handler_for_dbx(const efi_guid_t *sig_type);
>
> #endif
> -
> -#ifndef UEFI_QUIRK_SKIP_CERT
> -#define UEFI_QUIRK_SKIP_CERT(vendor, product) \
> - .matches = { \
> - DMI_MATCH(DMI_BOARD_VENDOR, vendor), \
> - DMI_MATCH(DMI_PRODUCT_NAME, product), \
> - },
> -#endif
> diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
> index c0d6948446c3..b4096d4c828d 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_apple_t2_chip) {
> pr_err("Reading UEFI Secure Boot Certs is not supported on T2 Macs.\n");
> return false;
> }
> --
> 2.43.0
>
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v2 1/2] treewide: Add a flag to detect the Apple T2 chip
From: Jarkko Sakkinen @ 2026-07-21 10:56 UTC (permalink / raw)
To: Atharva Tiwari
Cc: Bjorn Helgaas, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Andreas Noever, Mika Westerberg,
Yehezkel Bernat, Hans de Goede, Ilpo Järvinen, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Paul Moore,
James Morris, Serge E. Hallyn, linux-pci, linux-kernel, linux-usb,
platform-driver-x86, linux-integrity, keyrings,
linux-security-module
In-Reply-To: <20260721054506.11871-2-atharvatiwarilinuxdev@gmail.com>
On Tue, Jul 21, 2026 at 01:45:01AM -0400, Atharva Tiwari wrote:
> 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/kernel/quirks.c | 105 ++++++++++++++++++
> include/linux/platform_data/x86/apple.h | 5 +
> security/integrity/platform_certs/load_uefi.c | 38 ++-----
> 3 files changed, 118 insertions(+), 30 deletions(-)
>
> diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
> index a92f18db9610..74b29738d404 100644
> --- a/arch/x86/kernel/quirks.c
> +++ b/arch/x86/kernel/quirks.c
> @@ -664,8 +664,113 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x2083, quirk_intel_purley_xeon_ras
> bool x86_apple_machine;
> EXPORT_SYMBOL(x86_apple_machine);
>
> +bool has_apple_t2_chip;
> +EXPORT_SYMBOL(has_apple_t2_chip);
> +
> +static const struct dmi_system_id apple_t2_devices[] = {
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,1"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,2"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,3"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,4"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,1"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,2"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,3"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,4"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir8,1"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir8,2"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir9,1"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Macmini8,1"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacPro7,1"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "iMac20,1"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "iMac20,2"),
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "iMacPro1,1"),
> + },
> + },
> + { }
> +};
> +
> void __init early_platform_quirks(void)
> {
> x86_apple_machine = dmi_match(DMI_SYS_VENDOR, "Apple Inc.") ||
> dmi_match(DMI_SYS_VENDOR, "Apple Computer, Inc.");
> +
> + has_apple_t2_chip = dmi_check_system(apple_t2_devices);
> }
> diff --git a/include/linux/platform_data/x86/apple.h b/include/linux/platform_data/x86/apple.h
> index 079e816c3c21..50bbcc5134fc 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_apple_t2_chip - whether the machine has the Apple T2 chip
> + */
> +extern bool has_apple_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..b4096d4c828d 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_apple_t2_chip) {
> pr_err("Reading UEFI Secure Boot Certs is not supported on T2 Macs.\n");
> return false;
> }
> --
> 2.43.0
>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v3 2/2] thunderbolt: Add device links for Apple T2 NHI
From: Ilpo Järvinen @ 2026-07-21 9:03 UTC (permalink / raw)
To: Atharva Tiwari
Cc: Andre Eikmeyer, Bjorn Helgaas, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Andreas Noever,
Mika Westerberg, Yehezkel Bernat, Hans de Goede, Jarkko Sakkinen,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, linux-pci, LKML,
linux-usb, platform-driver-x86, linux-integrity, keyrings,
linux-security-module
In-Reply-To: <20260721063412.11588-3-atharvatiwarilinuxdev@gmail.com>
On Tue, 21 Jul 2026, Atharva Tiwari wrote:
> 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 | 51 +++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
> index c69c323e6952..0cdffcf577cd 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>
> @@ -3305,11 +3306,59 @@ static const struct tb_cm_ops tb_cm_ops = {
> static bool tb_apple_add_links(struct tb_nhi *nhi)
> {
> struct pci_dev *upstream, *pdev;
This file seems to have a pre-existing lack of pci.h include, please add
it now when doing pci related code.
> - bool ret;
> + bool ret = false;
>
> 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_apple_t2_chip && IS_ENABLED(CONFIG_ACPI)) {
> + 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 (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));
Please only use balanced braces.
> +
> +put_pdev:
> + pci_dev_put(pdev);
I think you can use __free() with it and avoid the label. You cannot then
reuse the existing pdev variable for it but declare it in this block while
you assign to it.
This line would be misaligned anyway but better get rid of goto logic
anyway.
> + }
> + }
> + return ret;
> + }
> +
> switch (nhi->pdev->device) {
> case PCI_DEVICE_ID_INTEL_LIGHT_RIDGE:
> case PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C:
>
--
i.
^ permalink raw reply
* [PATCH v3 2/2] thunderbolt: Add device links for Apple T2 NHI
From: Atharva Tiwari @ 2026-07-21 6:34 UTC (permalink / raw)
Cc: Atharva Tiwari, Andre Eikmeyer, Bjorn Helgaas, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Andreas Noever, Mika Westerberg, Yehezkel Bernat, Hans de Goede,
Ilpo Järvinen, Jarkko Sakkinen, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Paul Moore, James Morris,
Serge E. Hallyn, linux-pci, linux-kernel, linux-usb,
platform-driver-x86, linux-integrity, keyrings,
linux-security-module
In-Reply-To: <20260721063412.11588-1-atharvatiwarilinuxdev@gmail.com>
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 | 51 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
index c69c323e6952..0cdffcf577cd 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>
@@ -3305,11 +3306,59 @@ static const struct tb_cm_ops tb_cm_ops = {
static bool tb_apple_add_links(struct tb_nhi *nhi)
{
struct pci_dev *upstream, *pdev;
- bool ret;
+ bool ret = false;
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_apple_t2_chip && IS_ENABLED(CONFIG_ACPI)) {
+ 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 (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
^ permalink raw reply related
* [PATCH v3 1/2] treewide: Add a flag to detect the Apple T2 chip
From: Atharva Tiwari @ 2026-07-21 6:34 UTC (permalink / raw)
Cc: Atharva Tiwari, Bjorn Helgaas, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Andreas Noever,
Mika Westerberg, Yehezkel Bernat, Hans de Goede,
Ilpo Järvinen, Jarkko Sakkinen, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Paul Moore, James Morris,
Serge E. Hallyn, linux-pci, linux-kernel, linux-usb,
platform-driver-x86, linux-integrity, keyrings,
linux-security-module
In-Reply-To: <20260721063412.11588-1-atharvatiwarilinuxdev@gmail.com>
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/kernel/quirks.c | 105 ++++++++++++++++++
include/linux/platform_data/x86/apple.h | 5 +
.../platform_certs/keyring_handler.h | 8 --
security/integrity/platform_certs/load_uefi.c | 38 ++-----
4 files changed, 118 insertions(+), 38 deletions(-)
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index a92f18db9610..300d6436060d 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -664,8 +664,113 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x2083, quirk_intel_purley_xeon_ras
bool x86_apple_machine;
EXPORT_SYMBOL(x86_apple_machine);
+bool has_apple_t2_chip;
+EXPORT_SYMBOL(has_apple_t2_chip);
+
+static const struct dmi_system_id apple_t2_devices[] __initconst = {
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,2"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,3"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,4"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,2"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,3"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,4"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir8,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir8,2"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir9,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Macmini8,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacPro7,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "iMac20,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "iMac20,2"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "iMacPro1,1"),
+ },
+ },
+ { }
+};
+
void __init early_platform_quirks(void)
{
x86_apple_machine = dmi_match(DMI_SYS_VENDOR, "Apple Inc.") ||
dmi_match(DMI_SYS_VENDOR, "Apple Computer, Inc.");
+
+ has_apple_t2_chip = dmi_check_system(apple_t2_devices);
}
diff --git a/include/linux/platform_data/x86/apple.h b/include/linux/platform_data/x86/apple.h
index 079e816c3c21..47b27dceab18 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_apple_t2_chip - whether the machine has the Apple T2 chip
+ */
+extern bool has_apple_t2_chip;
#else
#define x86_apple_machine false
+#define has_apple_t2_chip false
#endif
#endif
diff --git a/security/integrity/platform_certs/keyring_handler.h b/security/integrity/platform_certs/keyring_handler.h
index f92895cc50f6..a355f4400179 100644
--- a/security/integrity/platform_certs/keyring_handler.h
+++ b/security/integrity/platform_certs/keyring_handler.h
@@ -45,11 +45,3 @@ efi_element_handler_t get_handler_for_code_signing_keys(const efi_guid_t *sig_ty
efi_element_handler_t get_handler_for_dbx(const efi_guid_t *sig_type);
#endif
-
-#ifndef UEFI_QUIRK_SKIP_CERT
-#define UEFI_QUIRK_SKIP_CERT(vendor, product) \
- .matches = { \
- DMI_MATCH(DMI_BOARD_VENDOR, vendor), \
- DMI_MATCH(DMI_PRODUCT_NAME, product), \
- },
-#endif
diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
index c0d6948446c3..b4096d4c828d 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_apple_t2_chip) {
pr_err("Reading UEFI Secure Boot Certs is not supported on T2 Macs.\n");
return false;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v3 0/2] Add Apple T2 NHI device links
From: Atharva Tiwari @ 2026-07-21 6:34 UTC (permalink / raw)
Cc: Atharva Tiwari, Bjorn Helgaas, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Andreas Noever,
Mika Westerberg, Yehezkel Bernat, Hans de Goede,
Ilpo Järvinen, Jarkko Sakkinen, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Paul Moore, James Morris,
Serge E. Hallyn, linux-pci, linux-kernel, linux-usb,
platform-driver-x86, linux-integrity, keyrings,
linux-security-module
This series adds a cached flag to detect Apple T2 systems, then uses it
to create device links for the Thunderbolt NHI.
Changes in v3:
- Fix build errors with non-x86 machines
- Used __initconst for apple_t2_devices
- Removed UEFI_QUIRK_SKIP_CERT as its unused now
- Used IS_ENABLED(CONFIG_ACPI) in tb_apple_add_links for the T2 part
- Removed !bid check to remove warning with -Waddress
Changes in v2:
- Used a less generic name for has_t2_chip
- Used DMI instead of PCI for has_apple_t2_chip to avoid PCI problems
- Initialized ret in tb_apple_add_links
Link to v2:
https://lore.kernel.org/all/20260721054506.11871-1-atharvatiwarilinuxdev@gmail.com/
Link to v1:
https://lore.kernel.org/all/20260719180308.1398-1-atharvatiwarilinuxdev@gmail.com/
Atharva Tiwari (2):
treewide: Add a flag to detect the Apple T2 chip
thunderbolt: Add device links for Apple T2 NHI
arch/x86/kernel/quirks.c | 105 ++++++++++++++++++
drivers/thunderbolt/tb.c | 51 ++++++++-
include/linux/platform_data/x86/apple.h | 5 +
.../platform_certs/keyring_handler.h | 8 --
security/integrity/platform_certs/load_uefi.c | 38 ++-----
5 files changed, 168 insertions(+), 39 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v2 2/2] thunderbolt: Add device links for Apple T2 NHI
From: Atharva Tiwari @ 2026-07-21 5:45 UTC (permalink / raw)
Cc: Atharva Tiwari, Andre Eikmeyer, Bjorn Helgaas, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Andreas Noever, Mika Westerberg, Yehezkel Bernat, Hans de Goede,
Ilpo Järvinen, Jarkko Sakkinen, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Paul Moore, James Morris,
Serge E. Hallyn, linux-pci, linux-kernel, linux-usb,
platform-driver-x86, linux-integrity, keyrings,
linux-security-module
In-Reply-To: <20260721054506.11871-1-atharvatiwarilinuxdev@gmail.com>
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 | 51 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
index c69c323e6952..ca47bfbcefdf 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>
@@ -3305,11 +3306,59 @@ static const struct tb_cm_ops tb_cm_ops = {
static bool tb_apple_add_links(struct tb_nhi *nhi)
{
struct pci_dev *upstream, *pdev;
- bool ret;
+ bool ret = false;
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_apple_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
^ permalink raw reply related
* [PATCH v2 1/2] treewide: Add a flag to detect the Apple T2 chip
From: Atharva Tiwari @ 2026-07-21 5:45 UTC (permalink / raw)
Cc: Atharva Tiwari, Bjorn Helgaas, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Andreas Noever,
Mika Westerberg, Yehezkel Bernat, Hans de Goede,
Ilpo Järvinen, Jarkko Sakkinen, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Paul Moore, James Morris,
Serge E. Hallyn, linux-pci, linux-kernel, linux-usb,
platform-driver-x86, linux-integrity, keyrings,
linux-security-module
In-Reply-To: <20260721054506.11871-1-atharvatiwarilinuxdev@gmail.com>
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/kernel/quirks.c | 105 ++++++++++++++++++
include/linux/platform_data/x86/apple.h | 5 +
security/integrity/platform_certs/load_uefi.c | 38 ++-----
3 files changed, 118 insertions(+), 30 deletions(-)
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index a92f18db9610..74b29738d404 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -664,8 +664,113 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x2083, quirk_intel_purley_xeon_ras
bool x86_apple_machine;
EXPORT_SYMBOL(x86_apple_machine);
+bool has_apple_t2_chip;
+EXPORT_SYMBOL(has_apple_t2_chip);
+
+static const struct dmi_system_id apple_t2_devices[] = {
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,2"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,3"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro15,4"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,2"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,3"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,4"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir8,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir8,2"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir9,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Macmini8,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacPro7,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "iMac20,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "iMac20,2"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "iMacPro1,1"),
+ },
+ },
+ { }
+};
+
void __init early_platform_quirks(void)
{
x86_apple_machine = dmi_match(DMI_SYS_VENDOR, "Apple Inc.") ||
dmi_match(DMI_SYS_VENDOR, "Apple Computer, Inc.");
+
+ has_apple_t2_chip = dmi_check_system(apple_t2_devices);
}
diff --git a/include/linux/platform_data/x86/apple.h b/include/linux/platform_data/x86/apple.h
index 079e816c3c21..50bbcc5134fc 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_apple_t2_chip - whether the machine has the Apple T2 chip
+ */
+extern bool has_apple_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..b4096d4c828d 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_apple_t2_chip) {
pr_err("Reading UEFI Secure Boot Certs is not supported on T2 Macs.\n");
return false;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] Add Apple T2 NHI device links
From: Atharva Tiwari @ 2026-07-21 5:45 UTC (permalink / raw)
Cc: Atharva Tiwari, Bjorn Helgaas, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Andreas Noever,
Mika Westerberg, Yehezkel Bernat, Hans de Goede,
Ilpo Järvinen, Jarkko Sakkinen, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Paul Moore, James Morris,
Serge E. Hallyn, linux-pci, linux-kernel, linux-usb,
platform-driver-x86, linux-integrity, keyrings,
linux-security-module
This series adds a cached flag to detect Apple T2 systems, then uses it
to create device links for the Thunderbolt NHI.
Changes in v2:
- Used a less generic name for has_t2_chip
- Used DMI instead of PCI for has_apple_t2_chip to avoid PCI problems
- Initialized ret in tb_apple_add_links
Link to v1:
https://lore.kernel.org/all/20260719180308.1398-1-atharvatiwarilinuxdev@gmail.com/
Atharva Tiwari (2):
treewide: Add a flag to detect the Apple T2 chip
thunderbolt: Add device links for Apple T2 NHI
arch/x86/kernel/quirks.c | 105 ++++++++++++++++++
drivers/thunderbolt/tb.c | 51 ++++++++-
include/linux/platform_data/x86/apple.h | 5 +
security/integrity/platform_certs/load_uefi.c | 38 ++-----
4 files changed, 168 insertions(+), 31 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH] apparmor: leverage audit_log_n_untrustedstring() when possible
From: Paul Moore @ 2026-07-21 1:53 UTC (permalink / raw)
To: John Johansen, linux-security-module
In-Reply-To: <326a6ffc-8cb1-4842-8bf0-74dd58bfdf08@canonical.com>
On July 20, 2026 9:41:05 PM John Johansen <john.johansen@canonical.com> wrote:
> On 7/17/26 14:52, Paul Moore wrote:
>> Make use of the audit_log_n_untrustedstring() function to simplify the
>> code in aa_label_xaudit().
>>
>> Signed-off-by: Paul Moore <paul@paul-moore.com>
>
> Acked-by: John Johansen <john.johansen@canonical.com>
>
> unless you object I will pull this into the apparmor tree
Please do, that code is up to you and Georgia, not me.
Thanks.
>
>>
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH] apparmor: leverage audit_log_n_untrustedstring() when possible
From: John Johansen @ 2026-07-21 1:41 UTC (permalink / raw)
To: Paul Moore, linux-security-module
In-Reply-To: <20260717215254.383183-2-paul@paul-moore.com>
On 7/17/26 14:52, Paul Moore wrote:
> Make use of the audit_log_n_untrustedstring() function to simplify the
> code in aa_label_xaudit().
>
> Signed-off-by: Paul Moore <paul@paul-moore.com>
Acked-by: John Johansen <john.johansen@canonical.com>
unless you object I will pull this into the apparmor tree
> ---
> security/apparmor/label.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/security/apparmor/label.c b/security/apparmor/label.c
> index 3fd384d8c41a..a165cadf8249 100644
> --- a/security/apparmor/label.c
> +++ b/security/apparmor/label.c
> @@ -1743,10 +1743,7 @@ void aa_label_xaudit(struct audit_buffer *ab, struct aa_ns *ns,
> str = (char *) label->hname;
> len = strlen(str);
> }
> - if (audit_string_contains_control(str, len))
> - audit_log_n_hex(ab, str, len);
> - else
> - audit_log_n_string(ab, str, len);
> + audit_log_n_untrustedstring(ab, str, len);
>
> kfree(name);
> }
^ permalink raw reply
* Re: [PATCH v5 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Paul Moore @ 2026-07-20 22:47 UTC (permalink / raw)
To: Kumar Kartikeya Dwivedi
Cc: David Windsor, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Jiri Olsa,
Emil Tsalapatis, Matt Bobrowski, James Morris, Serge E . Hallyn,
Casey Schaufler, Stephen Smalley, Ondrej Mosnacek, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Alexander Viro,
Christian Brauner, Jan Kara, Shuah Khan, bpf,
linux-security-module, linux-fsdevel, linux-integrity, selinux,
linux-kselftest, linux-kernel
In-Reply-To: <DK3PRLXZFGKN.GES64J05HY6B@gmail.com>
On Mon, Jul 20, 2026 at 5:24 PM Kumar Kartikeya Dwivedi
<memxor@gmail.com> wrote:
> On Mon Jul 20, 2026 at 10:15 PM CEST, Paul Moore wrote:
> > On Mon, Jul 20, 2026 at 2:27 PM Kumar Kartikeya Dwivedi
> > <memxor@gmail.com> wrote:
> >> On Mon Jul 20, 2026 at 8:12 PM CEST, David Windsor wrote:
> >> > On Thu, Jul 16, 2026 at 5:55 PM Paul Moore <paul@paul-moore.com> wrote:
> >> >>
> >> >>
> >> >> I'm sorry David, now that I'm seeing this function again, especially
> >> >> with the LSM specific bits extracted into a LSM function, this absolutely
> >> >> belongs somewhere under security/. It's only callable from within a
> >> >> BPF LSM callback and all it does outside of some BPF pointer boilerplate
> >> >> is call right back into a LSM helper function.
> >> >>
> >> >> If the BPF maintainers aren't willing to accept that, then we will all
> >> >> need to find another way.
> >> >
> >> > Where this code lands doesn't matter to me, so I'll stay out of the
> >> > decision of where it lives.
> >
> > Yes, you're caught up in some territorial wrangling that goes a fair
> > bit beyond what you're looking to accomplish. My apologies for my
> > half of that, it is an unfortunate part of upstream kernel
> > development.
> >
> >> > If this kfunc goes to security/, would we also want to move eg
> >> > bpf_set_dentry_xattr similarly?
> >> >
> >> > I'll roll v6 of this series meanwhile and we'll see what the BPF
> >> > maintainers say.
> >
> > Thanks. Fortunately, it should be easy enough to move the kfunc
> > around, that's likely one of the smaller changes needed in v6.
> >
> >> I don't think there was any preference expressed from the BPF side.
> >
> > Look at the second patch in the v4 patchset, you'll see a preference.
> >
> >> Logically,
> >> one cannot be faulted for adding a kfunc to set the xattr for inode in the same
> >> file where similar kfuncs to set xattr on other FS objects / entities exist.
> >
> > First off, I can't say that the existing BPF kfuncs intended for use
> > within a BPF LSM program are in a good location. Unlike every other
> > LSM which locates its code under security, the BPF LSM devs have
> > chosen to locate their associated code all over the place. Some of
> > that happened before I was responsible for the LSM framework, and some
> > of that which has happened afterwards has likely intentionally avoided
> > traditional LSM review. Unfortunately, this has muddied things with
> > respect to what is possible generally in BPF versus what is possible
> > only when the BPF LSM is enabled; we just recently saw where this was
> > arguably the root cause of an exploitable vulnerability.
> >
> >> The question about bpf_set_dentry_xattr is thus valid.
> >
> > It's a very valid question. It is my opinion that kfuncs which are
> > only intended to be called from within BPF LSMs should be located
> > under security/, just like every other LSM. If there is a kfunc that
> > is generally useful from other contexts, that is a different story,
> > but in the bpf_set_dentry_xattr() case, it is explicitly only useful
> > for setting 'security.bpf.*' xattrs.
>
> I don't think we should do that in v6 though.
Yes, that would be a separate effort and it's one of the reasons I
didn't bring it up in my review comments, I was simply responding to
those who raised it as a question.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v5 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Kumar Kartikeya Dwivedi @ 2026-07-20 21:24 UTC (permalink / raw)
To: Paul Moore, David Windsor, Kumar Kartikeya Dwivedi
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Jiri Olsa, Emil Tsalapatis,
Matt Bobrowski, James Morris, Serge E . Hallyn, Casey Schaufler,
Stephen Smalley, Ondrej Mosnacek, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Alexander Viro, Christian Brauner,
Jan Kara, Shuah Khan, bpf, linux-security-module, linux-fsdevel,
linux-integrity, selinux, linux-kselftest, linux-kernel
In-Reply-To: <CAHC9VhR8n_TBPGLGq-Pray+mHrUCdcmqGXi9wTXyeGa2Dc4m4g@mail.gmail.com>
On Mon Jul 20, 2026 at 10:15 PM CEST, Paul Moore wrote:
> On Mon, Jul 20, 2026 at 2:27 PM Kumar Kartikeya Dwivedi
> <memxor@gmail.com> wrote:
>> On Mon Jul 20, 2026 at 8:12 PM CEST, David Windsor wrote:
>> > On Thu, Jul 16, 2026 at 5:55 PM Paul Moore <paul@paul-moore.com> wrote:
>> >>
>> >>
>> >> I'm sorry David, now that I'm seeing this function again, especially
>> >> with the LSM specific bits extracted into a LSM function, this absolutely
>> >> belongs somewhere under security/. It's only callable from within a
>> >> BPF LSM callback and all it does outside of some BPF pointer boilerplate
>> >> is call right back into a LSM helper function.
>> >>
>> >> If the BPF maintainers aren't willing to accept that, then we will all
>> >> need to find another way.
>> >
>> > Where this code lands doesn't matter to me, so I'll stay out of the
>> > decision of where it lives.
>
> Yes, you're caught up in some territorial wrangling that goes a fair
> bit beyond what you're looking to accomplish. My apologies for my
> half of that, it is an unfortunate part of upstream kernel
> development.
>
>> > If this kfunc goes to security/, would we also want to move eg
>> > bpf_set_dentry_xattr similarly?
>> >
>> > I'll roll v6 of this series meanwhile and we'll see what the BPF
>> > maintainers say.
>
> Thanks. Fortunately, it should be easy enough to move the kfunc
> around, that's likely one of the smaller changes needed in v6.
>
>> I don't think there was any preference expressed from the BPF side.
>
> Look at the second patch in the v4 patchset, you'll see a preference.
>
>> Logically,
>> one cannot be faulted for adding a kfunc to set the xattr for inode in the same
>> file where similar kfuncs to set xattr on other FS objects / entities exist.
>
> First off, I can't say that the existing BPF kfuncs intended for use
> within a BPF LSM program are in a good location. Unlike every other
> LSM which locates its code under security, the BPF LSM devs have
> chosen to locate their associated code all over the place. Some of
> that happened before I was responsible for the LSM framework, and some
> of that which has happened afterwards has likely intentionally avoided
> traditional LSM review. Unfortunately, this has muddied things with
> respect to what is possible generally in BPF versus what is possible
> only when the BPF LSM is enabled; we just recently saw where this was
> arguably the root cause of an exploitable vulnerability.
>
>> The question about bpf_set_dentry_xattr is thus valid.
>
> It's a very valid question. It is my opinion that kfuncs which are
> only intended to be called from within BPF LSMs should be located
> under security/, just like every other LSM. If there is a kfunc that
> is generally useful from other contexts, that is a different story,
> but in the bpf_set_dentry_xattr() case, it is explicitly only useful
> for setting 'security.bpf.*' xattrs.
I don't think we should do that in v6 though. What you're describing affects all
other xattr kfuncs. That's a broader discussion we should have separately when
folks are back from vacation, and more importantly involve FS folks where the
code currently lives. As you say yourself, the lines are blurry, xattrs are as
much a filesystem concept.
So I wouldn't burden David with it right now. David, just respin addressing all
other comments and the CI issue.
^ permalink raw reply
* Re: [PATCH v5 1/3] security: rework inode_init_security xattr handling
From: Paul Moore @ 2026-07-20 20:41 UTC (permalink / raw)
To: David Windsor
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Jiri Olsa, Kumar Kartikeya Dwivedi,
Emil Tsalapatis, Matt Bobrowski, James Morris, Serge E . Hallyn,
Casey Schaufler, Stephen Smalley, Ondrej Mosnacek, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Alexander Viro,
Christian Brauner, Jan Kara, Shuah Khan, bpf,
linux-security-module, linux-fsdevel, linux-integrity, selinux,
linux-kselftest, linux-kernel
In-Reply-To: <CAEXv5_i_iHmF8n6Qf1NiVOhm2cCnVLgmwXK-b8M+hvmdO3aQdA@mail.gmail.com>
On Mon, Jul 20, 2026 at 2:06 PM David Windsor <dwindsor@gmail.com> wrote:
> On Thu, Jul 16, 2026 at 5:55 PM Paul Moore <paul@paul-moore.com> wrote:
> >
...
> > > +int security_lsmxattr_add(struct lsm_xattrs *xattrs, u64 lsm_id,
> > > + const char *name, const void *value,
> > > + size_t value_len)
> > > +{
> > > + struct xattr *xattr;
> > > + void *xattr_value;
> > > + size_t name_len;
> > > +
> > > + if (!xattrs || !xattrs->xattrs || !name || !value)
> > > + return -EINVAL;
> >
> > Sashiko raised a good point about xattrs->xattrs being NULL not
> > necessarily being a good reason for -EINVAL. If xattrs is NULL, yes,
> > something has gone wrong and -EINVAL seems reasonable, but the
> > xattr->xattrs NULL case does seem like it should simply return early
> > with a value of 0 (see SELinux's handling of this case as an example).
>
> The problem is, SELinux has already set the sid by before calling
> lsm_get_xattr_slot, so we do indeed get an in-core label for the inode
> before returning early here. Returning early here from BPF would not
> mean the same thing: there is no label anywhere, in memory or on disk.
It's important to remember that you are not always guaranteed to have
an lsm_xattrs buffer, for some filesystems that is going to be normal
and expected. In these instances the 'xattrs->xattrs' value is going
to be NULL and each LSM that provides a security_inode_init_security()
LSM callback needs to handle that condition gracefully.
As you already know, the SELinux approach to this is to set the
in-memory inode label, but refrain from setting a presistent label
(these filesystems are typically either transient or don't have a
mechanism to allow for persistent label storage). Each BPF program
will need to decide how they want to handle this in their
security_inode_init_security() callback, but in the
security_lsmxattr_add() code where the only purpose is to populate the
lsm_xattrs strcut with the persistent BPF label/xattr, there is
nothing that can be done, it should simply return early without error.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v5 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Paul Moore @ 2026-07-20 20:15 UTC (permalink / raw)
To: David Windsor, Kumar Kartikeya Dwivedi
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Jiri Olsa, Emil Tsalapatis,
Matt Bobrowski, James Morris, Serge E . Hallyn, Casey Schaufler,
Stephen Smalley, Ondrej Mosnacek, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Alexander Viro, Christian Brauner,
Jan Kara, Shuah Khan, bpf, linux-security-module, linux-fsdevel,
linux-integrity, selinux, linux-kselftest, linux-kernel
In-Reply-To: <DK3LZOFOVG5L.3F34IKOCO1I04@gmail.com>
On Mon, Jul 20, 2026 at 2:27 PM Kumar Kartikeya Dwivedi
<memxor@gmail.com> wrote:
> On Mon Jul 20, 2026 at 8:12 PM CEST, David Windsor wrote:
> > On Thu, Jul 16, 2026 at 5:55 PM Paul Moore <paul@paul-moore.com> wrote:
> >>
> >>
> >> I'm sorry David, now that I'm seeing this function again, especially
> >> with the LSM specific bits extracted into a LSM function, this absolutely
> >> belongs somewhere under security/. It's only callable from within a
> >> BPF LSM callback and all it does outside of some BPF pointer boilerplate
> >> is call right back into a LSM helper function.
> >>
> >> If the BPF maintainers aren't willing to accept that, then we will all
> >> need to find another way.
> >
> > Where this code lands doesn't matter to me, so I'll stay out of the
> > decision of where it lives.
Yes, you're caught up in some territorial wrangling that goes a fair
bit beyond what you're looking to accomplish. My apologies for my
half of that, it is an unfortunate part of upstream kernel
development.
> > If this kfunc goes to security/, would we also want to move eg
> > bpf_set_dentry_xattr similarly?
> >
> > I'll roll v6 of this series meanwhile and we'll see what the BPF
> > maintainers say.
Thanks. Fortunately, it should be easy enough to move the kfunc
around, that's likely one of the smaller changes needed in v6.
> I don't think there was any preference expressed from the BPF side.
Look at the second patch in the v4 patchset, you'll see a preference.
> Logically,
> one cannot be faulted for adding a kfunc to set the xattr for inode in the same
> file where similar kfuncs to set xattr on other FS objects / entities exist.
First off, I can't say that the existing BPF kfuncs intended for use
within a BPF LSM program are in a good location. Unlike every other
LSM which locates its code under security, the BPF LSM devs have
chosen to locate their associated code all over the place. Some of
that happened before I was responsible for the LSM framework, and some
of that which has happened afterwards has likely intentionally avoided
traditional LSM review. Unfortunately, this has muddied things with
respect to what is possible generally in BPF versus what is possible
only when the BPF LSM is enabled; we just recently saw where this was
arguably the root cause of an exploitable vulnerability.
> The question about bpf_set_dentry_xattr is thus valid.
It's a very valid question. It is my opinion that kfuncs which are
only intended to be called from within BPF LSMs should be located
under security/, just like every other LSM. If there is a kfunc that
is generally useful from other contexts, that is a different story,
but in the bpf_set_dentry_xattr() case, it is explicitly only useful
for setting 'security.bpf.*' xattrs.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v5 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: David Windsor @ 2026-07-20 18:31 UTC (permalink / raw)
To: Kumar Kartikeya Dwivedi
Cc: Paul Moore, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Jiri Olsa, Emil Tsalapatis,
Matt Bobrowski, James Morris, Serge E . Hallyn, Casey Schaufler,
Stephen Smalley, Ondrej Mosnacek, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Alexander Viro, Christian Brauner,
Jan Kara, Shuah Khan, bpf, linux-security-module, linux-fsdevel,
linux-integrity, selinux, linux-kselftest, linux-kernel
In-Reply-To: <DK3M1X95Q2FN.26PY131TLPS2O@gmail.com>
On Mon, Jul 20, 2026 at 2:30 PM Kumar Kartikeya Dwivedi
<memxor@gmail.com> wrote:
>
> On Mon Jul 20, 2026 at 8:27 PM CEST, Kumar Kartikeya Dwivedi wrote:
> > On Mon Jul 20, 2026 at 8:12 PM CEST, David Windsor wrote:
> >> On Thu, Jul 16, 2026 at 5:55 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>
> >>>
> >>> I'm sorry David, now that I'm seeing this function again, especially
> >>> with the LSM specific bits extracted into a LSM function, this absolutely
> >>> belongs somewhere under security/. It's only callable from within a
> >>> BPF LSM callback and all it does outside of some BPF pointer boilerplate
> >>> is call right back into a LSM helper function.
> >>>
> >>> If the BPF maintainers aren't willing to accept that, then we will all
> >>> need to find another way.
> >>>
> >>
> >> Where this code lands doesn't matter to me, so I'll stay out of the
> >> decision of where it lives.
> >>
> >> If this kfunc goes to security/, would we also want to move eg
> >> bpf_set_dentry_xattr similarly?
> >>
> >> I'll roll v6 of this series meanwhile and we'll see what the BPF
> >> maintainers say.
> >
> > I don't think there was any preference expressed from the BPF side. Logically,
> > one cannot be faulted for adding a kfunc to set the xattr for inode in the same
> > file where similar kfuncs to set xattr on other FS objects / entities exist.
> >
> > The question about bpf_set_dentry_xattr is thus valid.
> >
> > Anyway, I will leave it to Paul and Christian to decide between themselves where
> > it makes most sense for this one to live.
>
> Also, perhaps it makes sense to use set/get naming for this one too, to keep it
> consistent with other ones?
I considered that, but we're only allowing one to initialize the xattr
on the inode here. Once it's been initialized, one uses
bpf_dentry_set_xattr.
^ permalink raw reply
* Re: [PATCH v5 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Kumar Kartikeya Dwivedi @ 2026-07-20 18:30 UTC (permalink / raw)
To: Kumar Kartikeya Dwivedi, David Windsor, Paul Moore
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Jiri Olsa, Emil Tsalapatis,
Matt Bobrowski, James Morris, Serge E . Hallyn, Casey Schaufler,
Stephen Smalley, Ondrej Mosnacek, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Alexander Viro, Christian Brauner,
Jan Kara, Shuah Khan, bpf, linux-security-module, linux-fsdevel,
linux-integrity, selinux, linux-kselftest, linux-kernel
In-Reply-To: <DK3LZOFOVG5L.3F34IKOCO1I04@gmail.com>
On Mon Jul 20, 2026 at 8:27 PM CEST, Kumar Kartikeya Dwivedi wrote:
> On Mon Jul 20, 2026 at 8:12 PM CEST, David Windsor wrote:
>> On Thu, Jul 16, 2026 at 5:55 PM Paul Moore <paul@paul-moore.com> wrote:
>>>
>>>
>>> I'm sorry David, now that I'm seeing this function again, especially
>>> with the LSM specific bits extracted into a LSM function, this absolutely
>>> belongs somewhere under security/. It's only callable from within a
>>> BPF LSM callback and all it does outside of some BPF pointer boilerplate
>>> is call right back into a LSM helper function.
>>>
>>> If the BPF maintainers aren't willing to accept that, then we will all
>>> need to find another way.
>>>
>>
>> Where this code lands doesn't matter to me, so I'll stay out of the
>> decision of where it lives.
>>
>> If this kfunc goes to security/, would we also want to move eg
>> bpf_set_dentry_xattr similarly?
>>
>> I'll roll v6 of this series meanwhile and we'll see what the BPF
>> maintainers say.
>
> I don't think there was any preference expressed from the BPF side. Logically,
> one cannot be faulted for adding a kfunc to set the xattr for inode in the same
> file where similar kfuncs to set xattr on other FS objects / entities exist.
>
> The question about bpf_set_dentry_xattr is thus valid.
>
> Anyway, I will leave it to Paul and Christian to decide between themselves where
> it makes most sense for this one to live.
Also, perhaps it makes sense to use set/get naming for this one too, to keep it
consistent with other ones?
^ permalink raw reply
* Re: [PATCH v5 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Kumar Kartikeya Dwivedi @ 2026-07-20 18:27 UTC (permalink / raw)
To: David Windsor, Paul Moore
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Jiri Olsa, Kumar Kartikeya Dwivedi,
Emil Tsalapatis, Matt Bobrowski, James Morris, Serge E . Hallyn,
Casey Schaufler, Stephen Smalley, Ondrej Mosnacek, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Alexander Viro,
Christian Brauner, Jan Kara, Shuah Khan, bpf,
linux-security-module, linux-fsdevel, linux-integrity, selinux,
linux-kselftest, linux-kernel
In-Reply-To: <CAEXv5_gt7BPWvdR4D1_3XJ0_XpBXWN52jeAOf1K2QJ7LL6CtPQ@mail.gmail.com>
On Mon Jul 20, 2026 at 8:12 PM CEST, David Windsor wrote:
> On Thu, Jul 16, 2026 at 5:55 PM Paul Moore <paul@paul-moore.com> wrote:
>>
>>
>> I'm sorry David, now that I'm seeing this function again, especially
>> with the LSM specific bits extracted into a LSM function, this absolutely
>> belongs somewhere under security/. It's only callable from within a
>> BPF LSM callback and all it does outside of some BPF pointer boilerplate
>> is call right back into a LSM helper function.
>>
>> If the BPF maintainers aren't willing to accept that, then we will all
>> need to find another way.
>>
>
> Where this code lands doesn't matter to me, so I'll stay out of the
> decision of where it lives.
>
> If this kfunc goes to security/, would we also want to move eg
> bpf_set_dentry_xattr similarly?
>
> I'll roll v6 of this series meanwhile and we'll see what the BPF
> maintainers say.
I don't think there was any preference expressed from the BPF side. Logically,
one cannot be faulted for adding a kfunc to set the xattr for inode in the same
file where similar kfuncs to set xattr on other FS objects / entities exist.
The question about bpf_set_dentry_xattr is thus valid.
Anyway, I will leave it to Paul and Christian to decide between themselves where
it makes most sense for this one to live.
^ permalink raw reply
* Re: [PATCH v5 2/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: David Windsor @ 2026-07-20 18:12 UTC (permalink / raw)
To: Paul Moore
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Jiri Olsa, Kumar Kartikeya Dwivedi,
Emil Tsalapatis, Matt Bobrowski, James Morris, Serge E . Hallyn,
Casey Schaufler, Stephen Smalley, Ondrej Mosnacek, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Alexander Viro,
Christian Brauner, Jan Kara, Shuah Khan, bpf,
linux-security-module, linux-fsdevel, linux-integrity, selinux,
linux-kselftest, linux-kernel
In-Reply-To: <a3a376bce713ac38ce6746508239c1af@paul-moore.com>
On Thu, Jul 16, 2026 at 5:55 PM Paul Moore <paul@paul-moore.com> wrote:
>
>
> I'm sorry David, now that I'm seeing this function again, especially
> with the LSM specific bits extracted into a LSM function, this absolutely
> belongs somewhere under security/. It's only callable from within a
> BPF LSM callback and all it does outside of some BPF pointer boilerplate
> is call right back into a LSM helper function.
>
> If the BPF maintainers aren't willing to accept that, then we will all
> need to find another way.
>
Where this code lands doesn't matter to me, so I'll stay out of the
decision of where it lives.
If this kfunc goes to security/, would we also want to move eg
bpf_set_dentry_xattr similarly?
I'll roll v6 of this series meanwhile and we'll see what the BPF
maintainers say.
^ permalink raw reply
* Re: [PATCH v5 1/3] security: rework inode_init_security xattr handling
From: David Windsor @ 2026-07-20 18:06 UTC (permalink / raw)
To: Paul Moore
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Jiri Olsa, Kumar Kartikeya Dwivedi,
Emil Tsalapatis, Matt Bobrowski, James Morris, Serge E . Hallyn,
Casey Schaufler, Stephen Smalley, Ondrej Mosnacek, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Alexander Viro,
Christian Brauner, Jan Kara, Shuah Khan, bpf,
linux-security-module, linux-fsdevel, linux-integrity, selinux,
linux-kselftest, linux-kernel
In-Reply-To: <cb9f84292a7f1d41ff8388d8c0c8c3d0@paul-moore.com>
On Thu, Jul 16, 2026 at 5:55 PM Paul Moore <paul@paul-moore.com> wrote:
>
> > +struct lsm_xattrs {
> > + struct xattr *xattrs;
> > + unsigned int xattr_count;
> > +};
>
> Please separate out the 'struct lsm_xattrs' related changes into a
> separate patch from the security_lsmxattr_add() changes. I know they
> are related, but they are different things.
>
Will do.
> > +#ifdef CONFIG_BPF_LSM
> > +static unsigned int lsm_xattrs_used(const struct lsm_xattrs *xattrs,
> > + const char *prefix)
> > +{
> > + size_t prefix_len = strlen(prefix);
> > + unsigned int i, n = 0;
> > +
> > + for (i = 0; i < xattrs->xattr_count; i++) {
> > + const char *name = xattrs->xattrs[i].name;
> > +
> > + if (name && !strncmp(name, prefix, prefix_len))
> > + n++;
> > + }
> > + return n;
> > +}
> > +#endif /* CONFIG_BPF_LSM */
>
> More on this below, but this function isn't strictly BPF LSM related so
> let's drop the CONFIG_BPF_LSM macro bracketing.
>
Ack
> > +int security_lsmxattr_add(struct lsm_xattrs *xattrs, u64 lsm_id,
> > + const char *name, const void *value,
> > + size_t value_len)
> > +{
> > + struct xattr *xattr;
> > + void *xattr_value;
> > + size_t name_len;
> > +
> > + if (!xattrs || !xattrs->xattrs || !name || !value)
> > + return -EINVAL;
>
> Sashiko raised a good point about xattrs->xattrs being NULL not
> necessarily being a good reason for -EINVAL. If xattrs is NULL, yes,
> something has gone wrong and -EINVAL seems reasonable, but the
> xattr->xattrs NULL case does seem like it should simply return early
> with a value of 0 (see SELinux's handling of this case as an example).
>
The problem is, SELinux has already set the sid by before calling
lsm_get_xattr_slot, so we do indeed get an in-core label for the inode
before returning early here. Returning early here from BPF would not
mean the same thing: there is no label anywhere, in memory or on disk.
> > + name_len = strlen(name);
> > + if (name_len == 0 || name_len > XATTR_NAME_MAX)
> > + return -EINVAL;
> > + if (value_len == 0 || value_len > XATTR_SIZE_MAX)
> > + return -EINVAL;
> > +
> > + switch (lsm_id) {
> > +#ifdef CONFIG_BPF_LSM
> > + case LSM_ID_BPF:
> > + if (lsm_xattrs_used(xattrs, XATTR_BPF_LSM_SUFFIX) >=
> > + BPF_LSM_INODE_INIT_XATTRS)
> > + return -ENOSPC;
> > + break;
> > +#endif /* CONFIG_BPF_LSM */
>
> I like to avoid macro conditional code inside functions whenever
> possible, and I think this is a case where we could avoid the conditional
> block with a little work.
>
> The LSM_ID_BPF macro is already defined as part of the UAPI so that will
> always be available. While BPF_LSM_INODE_INIT_XATTRS is dependent on
> CONFIG_BPF_LSM in this revision, that should be easy enough to move
> outside the CONFIG_BPF_LSM conditional in bpf_lsm.h. Eventually we
> should probably expand the lsm_id struct to carry this info, likely just
> a permanent/local copy of the LSM's lsm_blob_sizes passed during
> registration, but I can take care of that later; just make the
> BPF_LSM_INODE_INIT_XATTRS macro always accessible now.
>
> We should also probably record the xattr suffix/length when the LSM is
> registered, but that can also be done later with the other lsm_id
> additions.
>
Sounds good, will refactor to remove the conditional.
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + /* Combine xattr value + name into one allocation. */
> > + xattr_value = kmalloc(value_len + name_len + 1, GFP_NOWAIT);
> > + if (!xattr_value)
> > + return -ENOMEM;
> > +
> > + memcpy(xattr_value, value, value_len);
> > + memcpy(xattr_value + value_len, name, name_len);
> > + ((char *)xattr_value)[value_len + name_len] = '\0';
>
> You'll need to add an additional memcpy() here, likely in a switch
> statement to handle the different LSMs, to copy over the LSM specific
> prefix. It's a little ugly, but when we have things captured in the
> lsm_id struct it will get a lot cleaner.
>
Yup
>
> --
> paul-moore.com
Thanks,
David
^ permalink raw reply
* Re: [PATCH v1] landlock: Document the threat model
From: Mickaël Salaün @ 2026-07-20 12:59 UTC (permalink / raw)
To: Jann Horn
Cc: Günther Noack, Bryam Vargas, Greg Kroah-Hartman, Jens Axboe,
Jonathan Corbet, Justin Suess, Konstantin Meskhidze,
Leon Romanovsky, Matthieu Buffet, Mikhail Ivanov,
Nicolas Bouchinet, Paul Moore, Shuah Khan, Tingmao Wang,
Ubisectech Sirius, Willy Tarreau, Yuxian Mao, kernel-team,
landlock, linux-doc, linux-kernel, linux-security-module,
Kees Cook
In-Reply-To: <CAG48ez3ywK8FZ-TZFzp1GwiW6Wb+DeO3OFt3Ys4QAeGTS0jv6g@mail.gmail.com>
On Wed, Jul 08, 2026 at 11:48:09PM +0200, Jann Horn wrote:
> On Tue, Jul 7, 2026 at 11:03 PM Mickaël Salaün <mic@digikod.net> wrote:
> > +Sandboxing is layered
> > +---------------------
> > +
> > +Landlock is the access-control layer of a sandbox, not the whole sandbox. A
> > +robust sandbox also needs steps that are the program's responsibility: switching
> > +to an unprivileged user, dropping capabilities, setting ``PR_SET_NO_NEW_PRIVS``,
> > +and confining all threads of the process with the same domain. A
> > +single-threaded process gets the latter for free; a multithreaded one can
> > +enforce a ruleset atomically on all its threads, or must otherwise synchronize
> > +them before any untrusted work. Landlock is typically applied last, to tighten
> > +access and make the domain identifiable and auditable.
> > +
> > +Stronger isolation can come from combining Landlock with other mechanisms in a
> > +defense-in-depth approach, notably seccomp-bpf (see
> > +Documentation/userspace-api/seccomp_filter.rst) for what Landlock does not yet
> > +cover. A long-term goal of Landlock is to control access to any kind of kernel
> > +resource in a way suited to sandboxing.
>
> I think this part is something that should go near the top of the
> document, and should have a title like "How to securely use landlock"
> - most of the document is focused on telling kernel developers or
> security researchers what the boundaries of the threat model are, but
This patch is really about the threat model, to make it clear to
kernel developers, security researchers, and especially to AI agents
(not sure it will work but at least we can point to a specific doc),
what is not a Landlock security bug and why.
> I think it is also important (and maybe even more important) to
> present this from the perspective of "if I want to design a sandbox
> using landlock, what do I need to pay attention to".
I agree that it's more important, but the correct doc for that would be
the userspace API doc, which already describes how to use Landlock.
That would be an independent patch though.
>
> I think it would also make sense to give more specific guidance on
> which sets of syscalls, with what argument restrictions, can be
> permitted in a seccomp policy because landlock covers any accesses
> that these syscalls can perform to objects to which the process
> doesn't already hold file descriptors or such.
> I think it would be helpful to have instructions like "you can safely
> allow socket operations if you ensure that socket creation (socket())
> only works for AF_UNIX, and that the process has no existing socket
> file descriptors for non-covered socket types, and you have fs_access
> rules, and the kernel is sufficiently recent".
I'm wondering how we could have such a doc without gaps, make it simple
to read, and keep it up-to-date for all kernel versions and
architectures. Another challenge would also be to map these syscalls
and arguments to the evolving set of Landlock access rights. I think
the most pragmatic approach would be to rely on a dedicated library, but
maintaining it with a complete test coverage looks like a nightmare.
^ permalink raw reply
* Re: [PATCH v3 1/3] landlock: Require LANDLOCK_ACCESS_FS_MAKE_WHITEOUT for RENAME_WHITEOUT
From: Mickaël Salaün @ 2026-07-20 10:58 UTC (permalink / raw)
To: Günther Noack
Cc: Christian Brauner, linux-security-module, Paul Moore,
Amir Goldstein, Miklos Szeredi, Serge Hallyn, Stephen Smalley
In-Reply-To: <aivEo6bV_phFFJg5@google.com>
On Fri, Jun 12, 2026 at 10:34:43AM +0200, Günther Noack wrote:
> Thanks for the review!
>
> On Wed, Jun 10, 2026 at 03:38:56PM +0200, Mickaël Salaün wrote:
> > Making MAKE_CHAR not covering MAKE_WHITEOUT is not addressed (see
> > previous discussion). MAKE_CHAR should not restrict whiteout creation
> > *if* MAKE_WHITEOUT is handled.
>
> (This is option (3) from your reply to V1 [1].)
>
> I am skeptical of this approach, because it complicates how userspace
> needs to deal with this access right. Consider the following
> scenario: A program wants to install the policy:
>
> * DENY MAKE_WHITEOUT, MAKE_CHAR
> * ALLOW MAKE_WHITEOUT in /foo (path_beneath rule)
>
> Then, if the kernel ABI predates make-whiteout, with the usual
> best-effort fallback (clearing out the unsupported bits), this ruleset
> becomes:
>
> * DENY MAKE_CHAR
> * (no ALLOW rule)
>
> But this ruleset is incorrect, because it denies mknod("/foo/x",
> S_IFCHR | mode, makedev(0, 0)) in /foo, which was explicitly allowed
> in the earlier ruleset.
>
> So in order to implement the best-effort fallback, I guess userspace
> libraries would now have to take into account whether there are any
> rules where MAKE_WHITEOUT is specifically allowed, and if so, they
> can't restrict MAKE_CHAR either? I find this a bit complicated and I
> think it's foreseeable that library implementers will predominantly
> get this wrong.
I use this example below. In this case the library should *replace*
rules' MAKE_WHITEOUT with MAKE_CHAR.
>
>
> Let me circle back to the other options you mentioned in [1], quoting
> them here for reference:
> > I see four options:
> >
> > 1. Consider whiteouts as regular files and make them handled by
> > LANDLOCK_ACCESS_FS_MAKE_REG. This would require an erratum and would
> > make sense for direct mknod calls, but it would be weird for
> > renameat2 calls than move a file and should only require
> > LANDLOCK_ACCESS_FS_REMOVE_FILE from the user point of view.
>
> It would be weird for renameat2 calls to require MAKE_REG in the
> source directory, but the weirdness would only affect
> fuse-overlayfs-style programs and could be documented explicitly for
> them for the case that they start using Landlock.
>
> Normal programs that just call rename() on an existing FUSE-Overlayfs
> filesystem would *not* require the MAKE_REG right, because the FUSE
> process would do that on their behalf with the FUSE processes'
> credentials.
This is definitely the simplest approach, and the compatibility impact
should be really minimal, especially because fuse-overlayfs would
probably already need to be allowed to create regular files there.
I'm now leaning toward this option, but because I though about another
one, I'll describe it anyway.
>
> >
> > 2. Add a new LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right to handle whitout
> > creation (direct and indirect?) and keep LANDLOCK_ACCESS_FS_MAKE_CHAR
> > handle direct whiteout creation (and don't backport anything). It
> > looks inconsistent from an access control point of view.
>
> MAKE_WHITEOUT to handle rename(RENAME_WHITEOUT) and MAKE_CHAR to
> handle mknod(chardev (0, 0)) -- This is a bit inconsistent, but it
> does not make a difference for any programs other than the ones
> calling rename(RENAME_WHITEOUT) (i.e., overlayfs-fuse), and it could
> be documented for that one use case.
>
> I find this a pragmatic balance, and it does not require special logic
> for the best-effort fallback either. Could you be persuaded to go
> this route instead?
>
> > 3. Add a new LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right and, when handled,
> > make LANDLOCK_ACCESS_FS_MAKE_CHAR not handle whiteout. This would be
> > a bit weird from a kernel point of view but it should work well for
> > users while still forbidding direct whiteout creation.
>
> Except for the best-effort fallback, which is IMHO prone to
> implementation bugs. (see above)
>
> On the side, the implementation of this is also non-trivial: In order
> to check for mknod(..., makedev(0, 0)), we need to check
> layer-by-layer whether the layer handles MAKE_WHITEOUT and then either
> check for MAKE_CHAR or MAKE_WHITEOUT.
Canonicalizing MAKE_WHITEOUT at domain creation time (similarly to how
unhandled access rights are actually handled) should make this much
easier, and the following proposal would enable that:
First, a backportable patch would make MAKE_CHAR also control/deny
RENAME_WHITEOUT to be consistent with direct whiteout creation (i.e.
MAKE_CHAR control any S_IFCHR file, including whiteout ones). This
would be a real "Fixes" patch (without erratum). We should keep in mind
that whiteout creation doesn't require CAP_MKNOD, so in most cases,
sandboxed processes shouldn't be allowed to create real character
devices in the first place. Also, current fuse-overlayfs processes need
both ways to create whiteouts, so the current state is inconsistent to
them too.
Then, to be able to differentiate real character devices from whiteouts,
a new patch would add a LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right,
controlling only whiteouts. As with this third option, when this right
is handled by a ruleset/layer, MAKE_CHAR doesn't control whiteout
creation.
The best-effort compatibility is handled by userspace libraries. The
tricky part is when a policy handles MAKE_CHAR | MAKE_WHITEOUT, and has
a rule with MAKE_WHITEOUT but not MAKE_CHAR: when running such policy in
an old kernel (not supporting MAKE_WHITEOUT), the library should replace
the MAKE_WHITEOUT in the rules with a MAKE_CHAR. For the other cases,
simple masking should work as expected. This pattern could apply to
potentially future splits of existing access right.
I find this approach good to add a new dedicated access right, but I now
think it's overkill for this whiteout case. Anyway, this pattern could
be used if we want, one day, to split an access right.
>
>
> > 4. Add a new LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right and make
> > LANDLOCK_ACCESS_FS_MAKE_CHAR never handle whiteout (and backport
> > MAKE_CHAR fix with an errata). This would be consistent but backport
> > a way to directly create whiteouts (e.g. with mknod).
>
> It's mostly theoretical, but lifting the mknod(chardev (0,0))
> restriction for normal mknod() calls and calling it an erratum seems
> surprising as well, because it would relax security guarantees for
> existing programs.
Agreed
>
> I also pondered the alternative of creating an erratum but
> intentionally *not* backporting it, but even in that case, that
> surprising erratum still affects older programs which are deployed on
> newer kernels.
Yeah, that would not be useful and that's not the role of an erratum.
>
>
> Revisiting this discussion, I'd lean towards option 1 or 2 -- could
> you be persuaded towards one of these?
>
> I have a slight preference for option 1 (using MAKE_REG) because it
> would be a narrow fix that could be backported to older kernels as
> well and would not require a new access right. Given that the use
> case for RENAME_WHITEOUT is really only for FUSE-OverlayFS and given
> that FUSE-OverlayFS anyway needs MAKE_REG permissions there, I have
> trouble imagining a scenario where a separate access right for
> MAKE_WHITEOUT is needed in a policy. It seems like a pragmatic
> choice.
I was reluctant at first but I now think it's the best approach.
whiteouts are technically S_IFCHR but they are handled by the kernel/VFS
as regular files wrt access checks (unprivileged: don't need CAP_MKNOD),
so it would be inconsistent for Landlock to diverge from that.
Whiteouts are safe (no device can bind to them), and the goal of
LANDLOCK_ACCESS_FS_MAKE_CHAR is really to restrict the creation of new
interfaces to the kernel (through an arbitrary device driver). This
case and rationale should be explained in the doc (also see other VFS
replies wrt what are whiteouts).
So, LANDLOCK_ACCESS_FS_MAKE_REG should be the *only* access right to
restrict whiteout creation, either directly with mknod or indirectly
with RENAME_WHITEOUT. fuse-overlayfs already needs MAKE_REG, so this
should not change much its current status, but fuse-overlayfs could now
drop MAKE_CHAR.
Let's go with option 1!
>
>
> > Specific tests should check that all
> > these cases are proprely handled.
> >
> > There is no documentation update related to the new feature. A note
> > should also explain what exactly is a whiteout and why it is not
> > considered a character device (see previous discussions).
> >
> > The sandboxer is not updated.
> >
> > There is no audit tests.
>
> Acknowledged, these were missing.
>
> (I was initially hoping that this bug report wouldn't expand into a
> full-fledged feature with its own access right constant, but it is
> correct that this is all required in that case... :-/)
>
> Will add this for the next patch set revision if it is still needed.
>
> —Günther
>
> [1] https://lore.kernel.org/all/20260414.Lae5ida1eeGh@digikod.net/
>
^ permalink raw reply
* [PATCH v4] security: Expand task_setscheduler LSM hook
From: Aaron Tomlin @ 2026-07-20 1:41 UTC (permalink / raw)
To: tsbogend, paul, jmorris, serge, mingo, peterz, juri.lelli,
vincent.guittot, stephen.smalley.work, casey, longman, tj, hannes,
mkoutny
Cc: chenridong, dietmar.eggemann, rostedt, bsegall, mgorman, vschneid,
kprateek.nayak, omosnace, kees, atomlin, neelx, sean, chjohnst,
steve, mproche, nick.lange, cgroups, linux-mips, linux-fsdevel,
linux-security-module, selinux, linux-kernel
At present, the task_setscheduler LSM hook provides security modules
with the opportunity to mediate changes to a task's scheduling policy by
inspecting the requested sched_attr. However, when invoked via
sched_setaffinity(), the hook lacks visibility into the actual CPU
affinity mask being requested. Consequently, security modules are
entirely blind to the target CPUs and cannot make granular access
control decisions based on spatial isolation.
In modern multi-tenant and real-time environments, CPU isolation is a
critical boundary. The inability to audit or restrict specific CPU
pinning requests limits the effectiveness of security policies,
particularly when attempting to shield isolated or cryptographic cores
from unprivileged or compromised tasks.
This patch expands the security_task_setscheduler() hook signature to
include a pointer to the requested cpumask alongside the existing
sched_attr. Because this is a shared hook used for multiple scheduling
attribute changes, call sites that do not modify CPU affinity are
updated to safely pass NULL for the mask. To protect against unverified
dereferences, the parameter is annotated with __nullable in the LSM hook
definition, ensuring the BPF verifier mandates explicit NULL checks for
attached eBPF programs.
Historically, SELinux has governed all scheduling alterations under a
single, monolithic PROCESS__SETSCHED access vector. However, by
inspecting fields such as attr->sched_policy or attr->sched_priority, a
security module can introduce granular access controls. For instance,
differentiating between standard time-sharing policies and
latency-sensitive real-time policies.
This change updates all in-tree security modules (SELinux and Smack) to
accommodate the new parameter mechanically, while providing LSMs with
the necessary context to enforce strict affinity policies.
Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
---
Changes since v3:
- Expanded the task_setscheduler LSM hook to accept the 'sched_attr'
payload, enabling BPF and other LSMs to inspect scheduling attributes
(Peter Zijlstra)
- Updated all call sites for security_task_setscheduler() to correctly
pass the attr structure when available, or NULL otherwise
(Peter Zijlstra)
- Added the necessary forward declaration for struct sched_attr to
include/linux/security.h
- Linked to v3: https://lore.kernel.org/lkml/20260526142838.774711-1-atomlin@atomlin.com/
Changes since v2:
- Dropped patch 1. This is to be addressed by the cgroup cpuset
maintainer (Waiman Long)
- Dropped patch 3. Will be submitted as a separate patch (Paul Moore)
- Linked to v2: https://lore.kernel.org/lkml/20260509213803.968464-1-atomlin@atomlin.com/
Changes since v1:
- Reordered the allocation and user-copy of new_mask in the MIPS
architecture's mipsmt_sys_sched_setaffinity() to occur before the
LSM hook is invoked. This ensures the security modules evaluate a fully
populated mask rather than uninitialised memory, while cleanly handling
error unwinding
- Updated cpuset_can_fork() to pass the destination cpuset's effective CPU
mask instead of NULL
- Linked to v1: https://lore.kernel.org/lkml/20260509164847.939294-1-atomlin@atomlin.com/
Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
---
arch/mips/kernel/mips-mt-fpaff.c | 2 +-
fs/proc/base.c | 2 +-
include/linux/lsm_hook_defs.h | 4 +++-
include/linux/security.h | 15 +++++++++++----
kernel/cgroup/cpuset.c | 4 ++--
kernel/sched/syscalls.c | 4 ++--
security/commoncap.c | 9 +++++++--
security/security.c | 14 +++++++++-----
security/selinux/hooks.c | 4 +++-
security/smack/smack_lsm.c | 13 +++++++++++--
10 files changed, 50 insertions(+), 21 deletions(-)
diff --git a/arch/mips/kernel/mips-mt-fpaff.c b/arch/mips/kernel/mips-mt-fpaff.c
index 4fead87d2f43..c7a5d55cf7ca 100644
--- a/arch/mips/kernel/mips-mt-fpaff.c
+++ b/arch/mips/kernel/mips-mt-fpaff.c
@@ -110,7 +110,7 @@ asmlinkage long mipsmt_sys_sched_setaffinity(pid_t pid, unsigned int len,
goto out_unlock;
}
- retval = security_task_setscheduler(p);
+ retval = security_task_setscheduler(p, NULL, new_mask);
if (retval)
goto out_unlock;
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 780f81259052..b14401030e5c 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2589,7 +2589,7 @@ static ssize_t timerslack_ns_write(struct file *file, const char __user *buf,
}
rcu_read_unlock();
- err = security_task_setscheduler(p);
+ err = security_task_setscheduler(p, NULL, NULL);
if (err) {
count = err;
goto out;
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 65c9609ec207..80ca02879620 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -255,7 +255,9 @@ LSM_HOOK(int, 0, task_prlimit, const struct cred *cred,
const struct cred *tcred, unsigned int flags)
LSM_HOOK(int, 0, task_setrlimit, struct task_struct *p, unsigned int resource,
struct rlimit *new_rlim)
-LSM_HOOK(int, 0, task_setscheduler, struct task_struct *p)
+LSM_HOOK(int, 0, task_setscheduler, struct task_struct *p,
+ const struct sched_attr *attr__nullable,
+ const struct cpumask *in_mask__nullable)
LSM_HOOK(int, 0, task_getscheduler, struct task_struct *p)
LSM_HOOK(int, 0, task_movememory, struct task_struct *p)
LSM_HOOK(int, 0, task_kill, struct task_struct *p, struct kernel_siginfo *info,
diff --git a/include/linux/security.h b/include/linux/security.h
index 153e9043058f..82dfe4e3f8d1 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -82,6 +82,7 @@ struct ctl_table;
struct audit_krule;
struct user_namespace;
struct timezone;
+struct sched_attr;
enum lsm_event {
LSM_POLICY_CHANGE,
@@ -196,7 +197,9 @@ extern int cap_mmap_addr(unsigned long addr);
extern int cap_task_fix_setuid(struct cred *new, const struct cred *old, int flags);
extern int cap_task_prctl(int option, unsigned long arg2, unsigned long arg3,
unsigned long arg4, unsigned long arg5);
-extern int cap_task_setscheduler(struct task_struct *p);
+extern int cap_task_setscheduler(struct task_struct *p,
+ const struct sched_attr *attr,
+ const struct cpumask *in_mask);
extern int cap_task_setioprio(struct task_struct *p, int ioprio);
extern int cap_task_setnice(struct task_struct *p, int nice);
extern int cap_vm_enough_memory(struct mm_struct *mm, long pages);
@@ -531,7 +534,9 @@ int security_task_prlimit(const struct cred *cred, const struct cred *tcred,
unsigned int flags);
int security_task_setrlimit(struct task_struct *p, unsigned int resource,
struct rlimit *new_rlim);
-int security_task_setscheduler(struct task_struct *p);
+int security_task_setscheduler(struct task_struct *p,
+ const struct sched_attr *attr,
+ const struct cpumask *in_mask);
int security_task_getscheduler(struct task_struct *p);
int security_task_movememory(struct task_struct *p);
int security_task_kill(struct task_struct *p, struct kernel_siginfo *info,
@@ -1393,9 +1398,11 @@ static inline int security_task_setrlimit(struct task_struct *p,
return 0;
}
-static inline int security_task_setscheduler(struct task_struct *p)
+static inline int security_task_setscheduler(struct task_struct *p,
+ const struct sched_attr *attr,
+ const struct cpumask *in_mask)
{
- return cap_task_setscheduler(p);
+ return cap_task_setscheduler(p, attr, in_mask);
}
static inline int security_task_getscheduler(struct task_struct *p)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 45944b3e31ca..6ab47cf5582b 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -3042,7 +3042,7 @@ static int cpuset_can_attach(struct cgroup_taskset *tset)
goto out_unlock;
if (setsched_check) {
- ret = security_task_setscheduler(task);
+ ret = security_task_setscheduler(task, NULL, cs->effective_cpus);
if (ret)
goto out_unlock;
}
@@ -3600,7 +3600,7 @@ static int cpuset_can_fork(struct task_struct *task, struct css_set *cset)
if (ret)
goto out_unlock;
- ret = security_task_setscheduler(task);
+ ret = security_task_setscheduler(task, NULL, cs->effective_cpus);
if (ret)
goto out_unlock;
diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c
index b215b0ead9a6..86490035e815 100644
--- a/kernel/sched/syscalls.c
+++ b/kernel/sched/syscalls.c
@@ -540,7 +540,7 @@ int __sched_setscheduler(struct task_struct *p,
if (attr->sched_flags & SCHED_FLAG_SUGOV)
return -EINVAL;
- retval = security_task_setscheduler(p);
+ retval = security_task_setscheduler(p, attr, NULL);
if (retval)
return retval;
}
@@ -1213,7 +1213,7 @@ long sched_setaffinity(pid_t pid, const struct cpumask *in_mask)
return -EPERM;
}
- retval = security_task_setscheduler(p);
+ retval = security_task_setscheduler(p, NULL, in_mask);
if (retval)
return retval;
diff --git a/security/commoncap.c b/security/commoncap.c
index 3399535808fe..d83eee0459fe 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -1222,13 +1222,18 @@ static int cap_safe_nice(struct task_struct *p)
/**
* cap_task_setscheduler - Determine if scheduler policy change is permitted
* @p: The task to affect
+ * @attr: Requested scheduling attributes (ignored)
+ * @in_mask: Requested CPU affinity mask (ignored)
*
* Determine if the requested scheduler policy change is permitted for the
- * specified task.
+ * specified task. The capabilities security module does not evaluate the
+ * @attr or @in_mask parameters, relying solely on cap_safe_nice().
*
* Return: 0 if permission is granted, -ve if denied.
*/
-int cap_task_setscheduler(struct task_struct *p)
+int cap_task_setscheduler(struct task_struct *p,
+ const struct sched_attr *attr __always_unused,
+ const struct cpumask *in_mask __always_unused)
{
return cap_safe_nice(p);
}
diff --git a/security/security.c b/security/security.c
index 71aea8fdf014..a6725dddc34f 100644
--- a/security/security.c
+++ b/security/security.c
@@ -3240,17 +3240,21 @@ int security_task_setrlimit(struct task_struct *p, unsigned int resource,
}
/**
- * security_task_setscheduler() - Check if setting sched policy/param is allowed
+ * security_task_setscheduler() - Check if setting sched policy/param/affinity is allowed
* @p: target task
+ * @attr: requested scheduling attributes, or NULL if not changing parameters
+ * @in_mask: requested CPU affinity mask, or NULL if not changing affinity
*
- * Check permission before setting scheduling policy and/or parameters of
- * process @p.
+ * Check permission before setting the scheduling policy, parameters, and/or
+ * CPU affinity of process @p.
*
* Return: Returns 0 if permission is granted.
*/
-int security_task_setscheduler(struct task_struct *p)
+int security_task_setscheduler(struct task_struct *p,
+ const struct sched_attr *attr,
+ const struct cpumask *in_mask)
{
- return call_int_hook(task_setscheduler, p);
+ return call_int_hook(task_setscheduler, p, attr, in_mask);
}
/**
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 8d6945edae7a..d77a8d5c364c 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -4559,7 +4559,9 @@ static int selinux_task_setrlimit(struct task_struct *p, unsigned int resource,
return 0;
}
-static int selinux_task_setscheduler(struct task_struct *p)
+static int selinux_task_setscheduler(struct task_struct *p,
+ const struct sched_attr *attr __always_unused,
+ const struct cpumask *in_mask __always_unused)
{
return avc_has_perm(current_sid(), task_sid_obj(p), SECCLASS_PROCESS,
PROCESS__SETSCHED, NULL);
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index ff115068c5c0..cf28ccc28b80 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -2338,10 +2338,19 @@ static int smack_task_getioprio(struct task_struct *p)
/**
* smack_task_setscheduler - Smack check on setting scheduler
* @p: the task object
+ * @attr: Requested scheduling attributes (ignored)
+ * @in_mask: Requested CPU affinity mask (ignored)
*
- * Return 0 if read access is permitted
+ * Evaluate whether the current task has write access to the target task @p
+ * to change its scheduling policy. The Smack security module relies
+ * strictly on label-based access control and does not evaluate CPU
+ * affinity masks or scheduling attributes.
+ *
+ * Return: 0 if write access is permitted
*/
-static int smack_task_setscheduler(struct task_struct *p)
+static int smack_task_setscheduler(struct task_struct *p,
+ const struct sched_attr *attr __always_unused,
+ const struct cpumask *in_mask __always_unused)
{
return smk_curacc_on_task(p, MAY_WRITE, __func__);
}
--
2.54.0
^ permalink raw reply related
* [PATCH 2/2] thunderbolt: Add device links for Apple T2 NHI
From: Atharva Tiwari @ 2026-07-19 18:03 UTC (permalink / raw)
Cc: Atharva Tiwari, Andre Eikmeyer, Bjorn Helgaas, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Andreas Noever, Mika Westerberg, Yehezkel Bernat, Hans de Goede,
Ilpo Järvinen, Jarkko Sakkinen, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Paul Moore, James Morris,
Serge E. Hallyn, linux-pci, linux-kernel, linux-usb,
platform-driver-x86, linux-integrity, keyrings,
linux-security-module
In-Reply-To: <20260719180308.1398-1-atharvatiwarilinuxdev@gmail.com>
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
^ permalink raw reply related
* [PATCH 1/2] treewide: Add a flag to detect the Apple T2 chip
From: Atharva Tiwari @ 2026-07-19 18:03 UTC (permalink / raw)
Cc: Atharva Tiwari, Bjorn Helgaas, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Andreas Noever,
Mika Westerberg, Yehezkel Bernat, Hans de Goede,
Ilpo Järvinen, Jarkko Sakkinen, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Paul Moore, James Morris,
Serge E. Hallyn, linux-pci, linux-kernel, linux-usb,
platform-driver-x86, linux-integrity, keyrings,
linux-security-module
In-Reply-To: <20260719180308.1398-1-atharvatiwarilinuxdev@gmail.com>
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
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox