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/ (local)
[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
[off-list ref] wrote:

quoted

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/ (local)

quoted

On Thu, Jun 26, 2025 at 03:10:37PM -0700, Hamza Mahfooz wrote:

quoted

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