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(+)
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
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
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
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
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
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
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
© 2016 - 2025 Red Hat, Inc.