[PATCH 0/2] Secure Boot lock down

[PATCH 0/2] Secure Boot lock down

[Hamza Mahfooz]

All major distros have had carried a version of this patch-set
out of tree for sometime now, but with a bunch of magic (typically
sprinkled in setup_arch()). Though we can avoid those architecture
specific quirks if we call efi_get_secureboot_mode() from
efisubsys_init() and that allows us to have a generic solution.

Hamza Mahfooz (2):
  security: introduce security_lock_kernel_down()
  efi: introduce EFI_KERNEL_LOCK_DOWN_IN_SECURE_BOOT

 drivers/firmware/efi/Kconfig  | 10 ++++++++++
 drivers/firmware/efi/efi.c    |  9 +++++++++
 include/linux/lsm_hook_defs.h |  1 +
 include/linux/security.h      |  8 ++++++++
 security/lockdown/lockdown.c  |  1 +
 security/security.c           | 15 +++++++++++++++
 6 files changed, 44 insertions(+)

-- 
2.49.0

[PATCH 1/2] security: introduce security_lock_kernel_down()

[Hamza Mahfooz]

Define and export security_lock_kernel_down(), so that we can lock down
the kernel from other parts of the kernel.

Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
---
 include/linux/lsm_hook_defs.h |  1 +
 include/linux/security.h      |  8 ++++++++
 security/lockdown/lockdown.c  |  1 +
 security/security.c           | 15 +++++++++++++++
 4 files changed, 25 insertions(+)

diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index bf3bbac4e02a..08ffd103c863 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -442,6 +442,7 @@ LSM_HOOK(int, 0, bpf_token_cmd, const struct bpf_token *token, enum bpf_cmd cmd)
 LSM_HOOK(int, 0, bpf_token_capable, const struct bpf_token *token, int cap)
 #endif /* CONFIG_BPF_SYSCALL */
 
+LSM_HOOK(int, 0, lock_down, const char *where, enum lockdown_reason level)
 LSM_HOOK(int, 0, locked_down, enum lockdown_reason what)
 
 #ifdef CONFIG_PERF_EVENTS
diff --git a/include/linux/security.h b/include/linux/security.h
index cc9b54d95d22..373f8dd2a265 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -573,6 +573,7 @@ void security_inode_invalidate_secctx(struct inode *inode);
 int security_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen);
 int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen);
 int security_inode_getsecctx(struct inode *inode, struct lsm_context *cp);
+int security_lock_kernel_down(const char *where, enum lockdown_reason level);
 int security_locked_down(enum lockdown_reason what);
 int lsm_fill_user_ctx(struct lsm_ctx __user *uctx, u32 *uctx_len,
 		      void *val, size_t val_len, u64 id, u64 flags);
@@ -1576,6 +1577,13 @@ static inline int security_inode_getsecctx(struct inode *inode,
 {
 	return -EOPNOTSUPP;
 }
+
+static inline int security_lock_kernel_down(const char *where,
+					    enum lockdown_reason level)
+{
+    return -EOPNOTSUPP;
+}
+
 static inline int security_locked_down(enum lockdown_reason what)
 {
 	return 0;
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index cf83afa1d879..3839a62c2c17 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -73,6 +73,7 @@ static int lockdown_is_locked_down(enum lockdown_reason what)
 }
 
 static struct security_hook_list lockdown_hooks[] __ro_after_init = {
+	LSM_HOOK_INIT(lock_down, lock_kernel_down),
 	LSM_HOOK_INIT(locked_down, lockdown_is_locked_down),
 };
 
diff --git a/security/security.c b/security/security.c
index fb57e8fddd91..51fbe8124388 100644
--- a/security/security.c
+++ b/security/security.c
@@ -5789,6 +5789,21 @@ void security_bpf_token_free(struct bpf_token *token)
 }
 #endif /* CONFIG_BPF_SYSCALL */
 
+/**
+ * security_lock_kernel_down() - Lock down the kernel
+ * @where: the location from where the lock down is being initiated
+ * @level: requested lock down level
+ *
+ * Attempt to lock down the kernel at the requested level.
+ *
+ * Return: Returns 0 on success, error on failure.
+ */
+int security_lock_kernel_down(const char *where, enum lockdown_reason level)
+{
+	return call_int_hook(lock_down, where, level);
+}
+EXPORT_SYMBOL(security_lock_kernel_down);
+
 /**
  * security_locked_down() - Check if a kernel feature is allowed
  * @what: requested kernel feature
-- 
2.49.0

[PATCH 2/2] efi: introduce EFI_KERNEL_LOCK_DOWN_IN_SECURE_BOOT

[Hamza Mahfooz]

Add a kernel configuration option to lock down the kernel, to restrict
userspace's ability to modify the running kernel when Secure Boot is
enabled.

Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
---
 drivers/firmware/efi/Kconfig | 10 ++++++++++
 drivers/firmware/efi/efi.c   |  9 +++++++++
 2 files changed, 19 insertions(+)

diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 5fe61b9ab5f9..4e827354e919 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -248,6 +248,16 @@ config EFI_DISABLE_RUNTIME
 
 	  This default can be overridden by using the efi=runtime option.
 
+config EFI_KERNEL_LOCK_DOWN_IN_SECURE_BOOT
+	bool "Lock down the kernel in EFI Secure Boot mode"
+	default n
+	depends on EFI
+	depends on SECURITY_LOCKDOWN_LSM
+	select SECURITY_LOCKDOWN_LSM_EARLY
+	help
+	  Enabling this option results in kernel lockdown being
+	  set in integrity mode if EFI Secure Boot is enabled.
+
 config EFI_COCO_SECRET
 	bool "EFI Confidential Computing Secret Area Support"
 	help
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 7309394b8fc9..b7a5fc79b065 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -427,6 +427,15 @@ static int __init efisubsys_init(void)
 		}
 	}
 
+#ifdef CONFIG_EFI_KERNEL_LOCK_DOWN_IN_SECURE_BOOT
+	if (efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE)) {
+		if (efi_get_secureboot_mode(efi.get_variable) ==
+		    efi_secureboot_mode_enabled)
+			security_lock_kernel_down("EFI Secure Boot",
+						  LOCKDOWN_INTEGRITY_MAX);
+	}
+#endif
+
 	if (efi_rt_services_supported(EFI_RT_SUPPORTED_TIME_SERVICES))
 		platform_device_register_simple("rtc-efi", 0, NULL, 0);
 
-- 
2.49.0

Re: [PATCH 0/2] Secure Boot lock down

[Hamza Mahfooz]

Ping?

On Thu, Jun 26, 2025 at 03:10:37PM -0700, Hamza Mahfooz wrote:
> All major distros have had carried a version of this patch-set
> out of tree for sometime now, but with a bunch of magic (typically
> sprinkled in setup_arch()). Though we can avoid those architecture
> specific quirks if we call efi_get_secureboot_mode() from
> efisubsys_init() and that allows us to have a generic solution.
> 
> Hamza Mahfooz (2):
>   security: introduce security_lock_kernel_down()
>   efi: introduce EFI_KERNEL_LOCK_DOWN_IN_SECURE_BOOT
> 
>  drivers/firmware/efi/Kconfig  | 10 ++++++++++
>  drivers/firmware/efi/efi.c    |  9 +++++++++
>  include/linux/lsm_hook_defs.h |  1 +
>  include/linux/security.h      |  8 ++++++++
>  security/lockdown/lockdown.c  |  1 +
>  security/security.c           | 15 +++++++++++++++
>  6 files changed, 44 insertions(+)
> 
> -- 
> 2.49.0

Re: [PATCH 0/2] Secure Boot lock down

[Paul Moore]

On Wed, Jul 16, 2025 at 5:29 PM Hamza Mahfooz
<hamzamahfooz@linux.microsoft.com> wrote:
>
> Ping?

Adding the new Lockdown maintainers to the To/CC line for review in
case they missed it earlier.  For reference, the patchset can be found
at the lore link below:

https://lore.kernel.org/linux-security-module/1750975839-32463-1-git-send-email-hamzamahfooz@linux.microsoft.com/

> On Thu, Jun 26, 2025 at 03:10:37PM -0700, Hamza Mahfooz wrote:
> > All major distros have had carried a version of this patch-set
> > out of tree for sometime now, but with a bunch of magic (typically
> > sprinkled in setup_arch()). Though we can avoid those architecture
> > specific quirks if we call efi_get_secureboot_mode() from
> > efisubsys_init() and that allows us to have a generic solution.
> >
> > Hamza Mahfooz (2):
> >   security: introduce security_lock_kernel_down()
> >   efi: introduce EFI_KERNEL_LOCK_DOWN_IN_SECURE_BOOT
> >
> >  drivers/firmware/efi/Kconfig  | 10 ++++++++++
> >  drivers/firmware/efi/efi.c    |  9 +++++++++
> >  include/linux/lsm_hook_defs.h |  1 +
> >  include/linux/security.h      |  8 ++++++++
> >  security/lockdown/lockdown.c  |  1 +
> >  security/security.c           | 15 +++++++++++++++
> >  6 files changed, 44 insertions(+)

-- 
paul-moore.com

Re: [PATCH 0/2] Secure Boot lock down

[Nicolas Bouchinet]

Hi Hamza, thanks for your patch.

Thanks, Paul, for the forward. 

Sorry for the delay, we took a bit of time to do some lore archaeology
and discuss it with Xiu. 

As you might know, this has already been through debates in 2017 [1]. At
that time, the decision was not to merge this behavior. 

Distros have indeed carried downstream patches reflecting this behavior
for a long time and have been affected by vulnerabilities like
CVE-2025-1272 [2], which is caused by the magic sprinkled in
setup_arch(). 

While your implementation looks cleaner to me. One of the points in
previous debates was to have a Lockdown side Kconfig knob to enable or
not this behavior. It would gate the registration of the Lockdown LSM to
the security_lock_kernel_down() hook. 

However, what bothers me is that with this patch, if UEFI Secure Boot is
activated and a user wants to disable Lockdown, they need to go through
disabling Secure Boot. I'm really not fond of that. A user shouldn't
have to be forced to disable security firmware settings because of a
kernel feature. 

We thus might want to add a way to disable Lockdown through kernel
cmdline. However, letting a user disable Lockdown through kernel cmdline
would allow easy Lockdown bypasses, especially since the kernel cmdline
as well as the initramfs are not integrity protected on most distros. A
root user would be able to tamper with kernel cmdline and change its
behavior across reboot. 

IMHO, if someone wants to enable Lockdown, the easy and correct way is
to set the kernel cmdline and integrity protect it using an UKI for
example. If the chain of trust is respected, no Lockdown bypasses should
be possible. 

I'm still open to hearing new arguments about this patch. 

[1]: https://lore.kernel.org/all/29447.1509035858@warthog.procyon.org.uk/
[2]: https://access.redhat.com/security/cve/cve-2025-1272

Best regards,

Nicolas

---

On Thu, Jul 17, 2025 at 02:22:04PM -0400, Paul Moore wrote:
> On Wed, Jul 16, 2025 at 5:29 PM Hamza Mahfooz
> <hamzamahfooz@linux.microsoft.com> wrote:
> >
> > Ping?
> 
> Adding the new Lockdown maintainers to the To/CC line for review in
> case they missed it earlier.  For reference, the patchset can be found
> at the lore link below:
> 
> https://lore.kernel.org/linux-security-module/1750975839-32463-1-git-send-email-hamzamahfooz@linux.microsoft.com/
> 
> > On Thu, Jun 26, 2025 at 03:10:37PM -0700, Hamza Mahfooz wrote:
> > > All major distros have had carried a version of this patch-set
> > > out of tree for sometime now, but with a bunch of magic (typically
> > > sprinkled in setup_arch()). Though we can avoid those architecture
> > > specific quirks if we call efi_get_secureboot_mode() from
> > > efisubsys_init() and that allows us to have a generic solution.
> > >
> > > Hamza Mahfooz (2):
> > >   security: introduce security_lock_kernel_down()
> > >   efi: introduce EFI_KERNEL_LOCK_DOWN_IN_SECURE_BOOT
> > >
> > >  drivers/firmware/efi/Kconfig  | 10 ++++++++++
> > >  drivers/firmware/efi/efi.c    |  9 +++++++++
> > >  include/linux/lsm_hook_defs.h |  1 +
> > >  include/linux/security.h      |  8 ++++++++
> > >  security/lockdown/lockdown.c  |  1 +
> > >  security/security.c           | 15 +++++++++++++++
> > >  6 files changed, 44 insertions(+)
> 
> -- 
> paul-moore.com

Re: [PATCH 0/2] Secure Boot lock down

[sergeh]

On Thu, Jul 24, 2025 at 02:59:39PM +0200, Nicolas Bouchinet wrote:
> Hi Hamza, thanks for your patch.
> 
> Thanks, Paul, for the forward. 
> 
> Sorry for the delay, we took a bit of time to do some lore archaeology
> and discuss it with Xiu. 
> 
> As you might know, this has already been through debates in 2017 [1]. At
> that time, the decision was not to merge this behavior. 
> 
> Distros have indeed carried downstream patches reflecting this behavior
> for a long time and have been affected by vulnerabilities like
> CVE-2025-1272 [2], which is caused by the magic sprinkled in
> setup_arch(). 
> 
> While your implementation looks cleaner to me. One of the points in
> previous debates was to have a Lockdown side Kconfig knob to enable or
> not this behavior. It would gate the registration of the Lockdown LSM to
> the security_lock_kernel_down() hook. 

Well, but there is a default-n kconfig.  What do you mean by "Lockdown
side Kconfig knob"?  I'm sure I'm missing something, but not sure
what...

thanks,
-serge

Re: [PATCH 0/2] Secure Boot lock down

[Nicolas Bouchinet]

On Thu, Jul 24, 2025 at 02:13:41PM +0000, sergeh@kernel.org wrote:
> On Thu, Jul 24, 2025 at 02:59:39PM +0200, Nicolas Bouchinet wrote:
> > Hi Hamza, thanks for your patch.
> > 
> > Thanks, Paul, for the forward. 
> > 
> > Sorry for the delay, we took a bit of time to do some lore archaeology
> > and discuss it with Xiu. 
> > 
> > As you might know, this has already been through debates in 2017 [1]. At
> > that time, the decision was not to merge this behavior. 
> > 
> > Distros have indeed carried downstream patches reflecting this behavior
> > for a long time and have been affected by vulnerabilities like
> > CVE-2025-1272 [2], which is caused by the magic sprinkled in
> > setup_arch(). 
> > 
> > While your implementation looks cleaner to me. One of the points in
> > previous debates was to have a Lockdown side Kconfig knob to enable or
> > not this behavior. It would gate the registration of the Lockdown LSM to
> > the security_lock_kernel_down() hook. 
> 
> Well, but there is a default-n kconfig.  What do you mean by "Lockdown
> side Kconfig knob"?  I'm sure I'm missing something, but not sure
> what...
> 
Sorry, if I have been unclear, I talk about something like a 
"LOCK_DOWN_IF_SECURE_BOOT" config in `security/lockdown/Kconfig`.
In addition to the "EFI_KERNEL_LOCK_DOWN_IN_SECURE_BOOT" in
`drivers/firmware/efi/Kconfig`.

- "EFI_KERNEL_LOCK_DOWN_IN_SECURE_BOOT" would gate the call to the
  `security_lock_kernel_down` hook and thus to any LSM registered to it.

- "LOCK_DOWN_IF_SECURE_BOOT" would gate the Lockdown LSM registration to
  the `security_lock_kernel_down` hook.

Thanks,

Nicolas

Re: [PATCH 0/2] Secure Boot lock down

[Paul Moore]

On Thu, Jul 24, 2025 at 8:59 AM Nicolas Bouchinet
<nicolas.bouchinet@oss.cyber.gouv.fr> wrote:
>
> Hi Hamza, thanks for your patch.
>
> Thanks, Paul, for the forward.
>
> Sorry for the delay, we took a bit of time to do some lore archaeology
> and discuss it with Xiu.
>
> As you might know, this has already been through debates in 2017 [1]. At
> that time, the decision was not to merge this behavior.
>
> Distros have indeed carried downstream patches reflecting this behavior
> for a long time and have been affected by vulnerabilities like
> CVE-2025-1272 [2], which is caused by the magic sprinkled in
> setup_arch().
>
> While your implementation looks cleaner to me. One of the points in
> previous debates was to have a Lockdown side Kconfig knob to enable or
> not this behavior. It would gate the registration of the Lockdown LSM to
> the security_lock_kernel_down() hook.
>
> However, what bothers me is that with this patch, if UEFI Secure Boot is
> activated and a user wants to disable Lockdown, they need to go through
> disabling Secure Boot. I'm really not fond of that. A user shouldn't
> have to be forced to disable security firmware settings because of a
> kernel feature.
>
> We thus might want to add a way to disable Lockdown through kernel
> cmdline.

One can enable/disable "normal" LSMs via the "lsm=" kernel command
line option, however, as Lockdown is an "early" LSM, it is enabled
prior to the command line option parsing in the kernel so that isn't
really an option unless we add some mechanism to later disable
Lockdown during the "normal" LSM initialization phase when the command
line options are available.  This would result in a window of time
during very early boot where Lockdown would be enabled, before being
disabled, but I have no idea how problematic that might be for users.

-- 
paul-moore.com