ALT Linux kernel packages development
 help / color / mirror / Atom feed
From: Vitaly Chikunov <vt@altlinux.org>
To: ALT Linux kernel packages development <devel-kernel@lists.altlinux.org>
Subject: Re: [d-kernel] [PATCH 5/6] efi: determine and pass Secure Boot state via FDT
Date: Sat, 9 May 2026 03:28:57 +0300
Message-ID: <af5-8_fy3de_8XPR@altlinux.org> (raw)
In-Reply-To: <20260506173722.1012394-6-egori@altlinux.org>

On Wed, May 06, 2026 at 08:37:21PM +0300, Egor Ignatov wrote:
> From: Linn Crosetto <linn@hpe.com>
> 
> Determine the state of UEFI Secure Boot in the EFI stub on platforms
> that use FDT-based EFI parameter passing (ARM, arm64, RISC-V), and

Вроде бы у нас нет pesign для arm - так зачем нам патч для arm?

> forward it to the kernel through a new "linux,uefi-secure-boot" FDT
> property. The early init path then calls efi_set_secure_boot(), which
> on kernels with CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT triggers kernel
> lockdown — analogous to how x86 already does it via boot_params.
> 
> Based on the Debian patch
> "arm64-add-kernel-config-option-to-lock-down-when-in-Secure-Boot-mode.patch"
> by Linn Crosetto. The original subject incorrectly implied an arm64-only
> change; the patch in fact only touches generic drivers/firmware/efi/ code
> that is shared by all FDT-based EFI architectures (ARM, arm64, RISC-V).
> Re-titled and re-described accordingly; the code is unchanged.
> 
> Original commit message:
> 
>   arm64: add kernel config option to lock down when in Secure Boot mode
>   Add a kernel configuration option to lock down the kernel, to restrict
>   userspace's ability to modify the running kernel when UEFI Secure Boot
>   is enabled. Based on the x86 patch by Matthew Garrett.
>   Determine the state of Secure Boot in the EFI stub and pass this to the
>   kernel using the FDT.
> 
>   Signed-off-by: Linn Crosetto <linn@hpe.com>
> 
> Signed-off-by: Linn Crosetto <linn@hpe.com>
> [egori: re-titled and rewrote commit message; no code changes]
> Signed-off-by: Egor Ignatov <egori@altlinux.org>

В SUSE и Fedora этого патча нет - зачем он нам нужен? Обязателен ли он для
shim?

> ---
>  drivers/firmware/efi/efi-init.c    |  5 ++++-
>  drivers/firmware/efi/fdtparams.c   | 12 +++++++++++-
>  drivers/firmware/efi/libstub/fdt.c |  6 ++++++
>  include/linux/efi.h                |  3 ++-
>  4 files changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/firmware/efi/efi-init.c b/drivers/firmware/efi/efi-init.c
> index 6103b1a082..dea8d67c71 100644
> --- a/drivers/firmware/efi/efi-init.c
> +++ b/drivers/firmware/efi/efi-init.c
> @@ -234,9 +234,10 @@ void __init efi_init(void)
>  {
>  	struct efi_memory_map_data data;
>  	u64 efi_system_table;
> +	u32 secure_boot;
>  
>  	/* Grab UEFI information placed in FDT by stub */
> -	efi_system_table = efi_get_fdt_params(&data);
> +	efi_system_table = efi_get_fdt_params(&data, &secure_boot);
>  	if (!efi_system_table)
>  		return;
>  
> @@ -258,6 +259,8 @@ void __init efi_init(void)
>  		return;
>  	}
>  
> +	efi_set_secure_boot(secure_boot);
> +
>  	reserve_regions();
>  	/*
>  	 * For memblock manipulation, the cap should come after the memblock_add().
> diff --git a/drivers/firmware/efi/fdtparams.c b/drivers/firmware/efi/fdtparams.c
> index b815d2a754..6f05b73c14 100644
> --- a/drivers/firmware/efi/fdtparams.c
> +++ b/drivers/firmware/efi/fdtparams.c
> @@ -16,6 +16,7 @@ enum {
>  	MMSIZE,
>  	DCSIZE,
>  	DCVERS,
> +	SBMODE,
>  
>  	PARAMCOUNT
>  };
> @@ -26,6 +27,7 @@ static __initconst const char name[][22] = {
>  	[MMSIZE] = "MemMap Size          ",
>  	[DCSIZE] = "MemMap Desc. Size    ",
>  	[DCVERS] = "MemMap Desc. Version ",
> +	[SBMODE] = "Secure Boot Enabled  ",
>  };
>  
>  static __initconst const struct {
> @@ -43,6 +45,7 @@ static __initconst const struct {
>  			[MMSIZE] = "xen,uefi-mmap-size",
>  			[DCSIZE] = "xen,uefi-mmap-desc-size",
>  			[DCVERS] = "xen,uefi-mmap-desc-ver",
> +			[SBMODE] = "",
>  		}
>  	}, {
>  #endif
> @@ -53,6 +56,7 @@ static __initconst const struct {
>  			[MMSIZE] = "linux,uefi-mmap-size",
>  			[DCSIZE] = "linux,uefi-mmap-desc-size",
>  			[DCVERS] = "linux,uefi-mmap-desc-ver",
> +			[SBMODE] = "linux,uefi-secure-boot",
>  		}
>  	}
>  };
> @@ -64,6 +68,11 @@ static int __init efi_get_fdt_prop(const void *fdt, int node, const char *pname,
>  	int len;
>  	u64 val;
>  
> +	if (!pname[0]) {
> +		memset(var, 0, size);
> +		return 0;
> +	}
> +
>  	prop = fdt_getprop(fdt, node, pname, &len);
>  	if (!prop)
>  		return 1;
> @@ -81,7 +90,7 @@ static int __init efi_get_fdt_prop(const void *fdt, int node, const char *pname,
>  	return 0;
>  }
>  
> -u64 __init efi_get_fdt_params(struct efi_memory_map_data *mm)
> +u64 __init efi_get_fdt_params(struct efi_memory_map_data *mm, u32 *secure_boot)
>  {
>  	const void *fdt = initial_boot_params;
>  	unsigned long systab;
> @@ -95,6 +104,7 @@ u64 __init efi_get_fdt_params(struct efi_memory_map_data *mm)
>  		[MMSIZE] = { &mm->size,		sizeof(mm->size) },
>  		[DCSIZE] = { &mm->desc_size,	sizeof(mm->desc_size) },
>  		[DCVERS] = { &mm->desc_version,	sizeof(mm->desc_version) },
> +		[SBMODE] = { secure_boot,		sizeof(*secure_boot) },
>  	};
>  
>  	BUILD_BUG_ON(ARRAY_SIZE(target) != ARRAY_SIZE(name));
> diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
> index 6a337f1f87..6c679da644 100644
> --- a/drivers/firmware/efi/libstub/fdt.c
> +++ b/drivers/firmware/efi/libstub/fdt.c
> @@ -132,6 +132,12 @@ static efi_status_t update_fdt(void *orig_fdt, unsigned long orig_fdt_size,
>  		}
>  	}
>  
> +	fdt_val32 = cpu_to_fdt32(efi_get_secureboot());
> +	status = fdt_setprop(fdt, node, "linux,uefi-secure-boot",
> +			     &fdt_val32, sizeof(fdt_val32));
> +	if (status)
> +		goto fdt_set_fail;
> +
>  	/* Shrink the FDT back to its minimum size: */
>  	fdt_pack(fdt);
>  
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 4419ae4eae..d3d4533468 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -758,7 +758,8 @@ extern int efi_mem_desc_lookup(u64 phys_addr, efi_memory_desc_t *out_md);
>  extern int __efi_mem_desc_lookup(u64 phys_addr, efi_memory_desc_t *out_md);
>  extern void efi_mem_reserve(phys_addr_t addr, u64 size);
>  extern int efi_mem_reserve_persistent(phys_addr_t addr, u64 size);
> -extern u64 efi_get_fdt_params(struct efi_memory_map_data *data);
> +extern u64 efi_get_fdt_params(struct efi_memory_map_data *data,
> +			      u32 *secure_boot);
>  extern struct kobject *efi_kobj;
>  
>  extern int efi_reboot_quirk_mode;
> -- 
> 2.50.1
> 
> _______________________________________________
> devel-kernel mailing list
> devel-kernel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-kernel


  reply	other threads:[~2026-05-09  0:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-06 17:37 [d-kernel] [PATCH 0/6] [7.0, 7.1] Lock down the kernel if booted in Secure Boot mode Egor Ignatov
2026-05-06 17:37 ` [d-kernel] [PATCH 1/6] mtd: phram, slram: Disable when the kernel is locked down Egor Ignatov
2026-05-08 23:43   ` Vitaly Chikunov
2026-05-06 17:37 ` [d-kernel] [PATCH 2/6] security: lockdown: expose security_lock_kernel_down function Egor Ignatov
2026-05-09  0:20   ` Vitaly Chikunov
2026-05-06 17:37 ` [d-kernel] [PATCH 3/6] efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode Egor Ignatov
2026-05-06 17:37 ` [d-kernel] [PATCH 4/6] efi: Lock down the kernel if booted in " Egor Ignatov
2026-05-09  0:24   ` Vitaly Chikunov
2026-05-06 17:37 ` [d-kernel] [PATCH 5/6] efi: determine and pass Secure Boot state via FDT Egor Ignatov
2026-05-09  0:28   ` Vitaly Chikunov [this message]
2026-05-06 17:37 ` [d-kernel] [PATCH 6/6] config: Enable LOCK_DOWN_IN_EFI_SECURE_BOOT Egor Ignatov
2026-05-09  0:34   ` Vitaly Chikunov
2026-05-08 23:01 ` [d-kernel] [PATCH 0/6] [7.0, 7.1] Lock down the kernel if booted in Secure Boot mode Vitaly Chikunov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=af5-8_fy3de_8XPR@altlinux.org \
    --to=vt@altlinux.org \
    --cc=devel-kernel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux kernel packages development

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel-kernel/0 devel-kernel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel-kernel devel-kernel/ http://lore.altlinux.org/devel-kernel \
		devel-kernel@altlinux.org devel-kernel@altlinux.ru devel-kernel@altlinux.com
	public-inbox-index devel-kernel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git