Skip to content

Enable kernel lockdown only under EFI Secure Boot #218

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jun 11, 2025

Conversation

ixhamza
Copy link
Contributor

@ixhamza ixhamza commented Jun 10, 2025

Cherry-pick two patches from Debian Backports to enable conditional kernel lockdown only when booted under EFI Secure Boot. This ensures backward compatibility, i.e. systems without Secure Boot support or with Secure Boot disabled remain unaffected (e.g. lockdown=[none]).

  1. efi-add-an-efi_secure_boot-flag-to-indicate-secure-boot.patch
  2. efi-lock-down-the-kernel-if-booted-in-secure-boot-mode.patch

Note: This is one of the requirements of the shim-review process:
“How does your signed kernel enforce lockdown when your system runs with Secure Boot enabled?
Hint: If it does not, we are not likely to sign your shim.”

Testing

  • With Secure Boot Enabled
root@truenas[~]# cat /boot/config-6.12.25-production+truenas | grep SECURE_BOOT
CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT=y
root@truenas[~]# mokutil --sb-state
SecureBoot enabled
root@truenas[~]# cat /sys/kernel/security/lockdown 
none [integrity] confidentiality
  • With Secure Boot Disabled
root@truenas[~]# cat /boot/config-6.12.25-production+truenas | grep SECURE_BOOT
CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT=y
root@truenas[~]# mokutil --sb-state
SecureBoot disabled
root@truenas[~]# cat /sys/kernel/security/lockdown 
[none] integrity confidentiality

dhowells and others added 3 commits June 10, 2025 17:33
UEFI machines can be booted in Secure Boot mode.  Add an EFI_SECURE_BOOT
flag that can be passed to efi_enabled() to find out whether secure boot is
enabled.

Move the switch-statement in x86's setup_arch() that inteprets the
secure_boot boot parameter to generic code and set the bit there.

Suggested-by: Ard Biesheuvel <[email protected]>
Signed-off-by: David Howells <[email protected]>
Reviewed-by: Ard Biesheuvel <[email protected]>
cc: [email protected]
[rperier: Forward-ported to 5.5:
 - Use pr_warn()
 - Adjust context]
[bwh: Forward-ported to 5.6: adjust context]
[bwh: Forward-ported to 5.7:
 - Use the next available bit in efi.flags
 - Adjust context]
Based on an earlier patch by David Howells, who wrote the following
description:

> UEFI Secure Boot provides a mechanism for ensuring that the firmware will
> only load signed bootloaders and kernels.  Certain use cases may also
> require that all kernel modules also be signed.  Add a configuration option
> that to lock down the kernel - which includes requiring validly signed
> modules - if the kernel is secure-booted.

Signed-off-by: Ben Hutchings <[email protected]>
[Salvatore Bonaccorso: After fixing https://bugs.debian.org/956197 the
help text for LOCK_DOWN_IN_EFI_SECURE_BOOT was adjusted to mention that
lockdown is triggered in integrity mode (https://bugs.debian.org/1025417)]
Signed-off-by: Salvatore Bonaccorso <[email protected]>
@ixhamza ixhamza requested review from amotin and yocalebo June 10, 2025 16:26
@yocalebo yocalebo requested a review from billohanlon June 10, 2025 16:39
Copy link
Collaborator

@amotin amotin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No objections, seems we have to. Just wonder what we may lose with it, like PLX configuration on M-series, etc. Also makes me think about possibility of some injection to make kernel think it is not SecureBoot-enabled and so not lock up. ;)

@ixhamza ixhamza merged commit 16c9da6 into truenas/linux-6.12 Jun 11, 2025
6 checks passed
@ixhamza ixhamza deleted the NAS-135054-lockdown branch June 11, 2025 15:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants