Skip to content

[CIQ 6.12.y] additional SecureBoot Lockdown patches #185

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 6 commits into from
Apr 2, 2025

Conversation

PlaidCat
Copy link
Collaborator

@PlaidCat PlaidCat commented Mar 28, 2025

Per the request here: rhboot/shim-review#455 (comment)
For the kernel.org Mainline / LongTerm kernels you need either CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=y OR these patches currently carried by Debian: https://salsa.debian.org/kernel-team/linux/-/tree/debian/latest/debian/patches/features/all/lockdown?ref_type=heads

Since CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=y Impacts non-secureboot users we opted for the patches from Debian and not carried in the usptream kernel.

This built and ran but I don't think I can test it fully until we have stuff setup for secureboot so these may not be the final forms of these patches and may require others (that we're currently unaware of)

Note the current SHA's are a little different from logs shown due to adding in a CIQ header to make sure we trace back to the original patch locations that we're aware of.

Patch application

The Debian patches come from here: https://salsa.debian.org/kernel-team/linux/-/tree/78c8af872660c31779951583b6f1ebf283d95985/debian/patches/features/all/lockdown
Since this is for the 6.12.y kernel the HEAD at time of writing needed debian/patches/features/all/lockdown/efi-add-an-efi_secure_boot-flag-to-indicate-secure-b.patch updated to 6.13-rc1 to get the next oldest version I looked at the history of the path and saw that the last modified content for the directory was for 6.12-rc2 so I used 78c8af872660c31779951583b6f1ebf283d95985 as the commit sha in the CIQ header for the kernel entry. Everywhere else this corresponds to a git commit but this commit is a normal drop/refresh commit if you manage patches outside of the tree.

So to apply these I just checked out the sha listed above and in the commits of the patches in this PR and did a normal git am --signoff for all the patches in that directory. They applied cleanly and did not require fixing.

$ git am --signoff ../debian-kernel/debian/patches/features/all/lockdown/*

$ pushd ../debian-kernel/debian/patches/features/all/lockdown/
~/workspace/ciq_kernel/debian-kernel/debian/patches/features/all/lockdown ~/workspace/ciq_kernel/kernel-src-tree
$ git branch
* (HEAD detached at 78c8af8726)
  debian/latest

Future 6.12.y updates

CIQ plans on rebasing our kernel on top of the latest stable v6.12.y kernel on regular intervals thus we will encounter merge issues when a problem arises and will require that to be fixed in place so these commits for the Debain patches will only ever be once but they may diverge from upstream (the Debian SHA). When this occurs we'll include a method of documenting the merge conflicts and resolutions.

Update

We investigated the fedora kernel-ark lockdown changes and found that some of them are very similar to Debian specifically these efi,lockdown: fix kernel lockdown on Secure Boot && security: lockdown: expose a hook to lock the kernel down
However since these were not pointed out NOR as easily referenced as Debians Changes we're going to stick with the Debain patches here. Fedora is not carrying the ARM patches either so that leads us to want to use Debians.

However the EFI error changes looked helpful so we're pulling those in from fedora as well.

Update 2

Added config changes for aarch64 based on Debians settings after their LockDown Patches
https://salsa.debian.org/kernel-team/linux/-/blob/debian/latest/debian/config/config?ref_type=heads#L7762
Validated by extracting their configs here:
https://packages.debian.org/sid/amd64/linux-config-6.12/download

[jmaple@devbox linux-config-6.12]$ find . | xargs grep LOCK_DOWN 2>/dev/null
./config.amd64_none_amd64:CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y
./config.amd64_none_amd64:# CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set
./config.amd64_none_amd64:# CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set
./config.amd64_none_amd64:CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT=y
./config.amd64_none_cloud-amd64:CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y
./config.amd64_none_cloud-amd64:# CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set
./config.amd64_none_cloud-amd64:# CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set
./config.amd64_none_cloud-amd64:CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT=y
./config.amd64_rt_amd64:CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y
./config.amd64_rt_amd64:# CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set
./config.amd64_rt_amd64:# CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set
./config.amd64_rt_amd64:CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT=y

Build

/mnt/code/kernel-src-tree
  CLEAN   scripts/basic
  CLEAN   scripts/kconfig
  CLEAN   include/config include/generated .config .config.old
[TIMER]{MRPROPER}: 5s
x86_64 architecture detected, copying config
'ciq/configs/kernel-x86_64.config' -> '.config'
Setting Local Version for build
CONFIG_LOCALVERSION="-_jmaple__sb_ciq-6.12.y-27daed599f82"
Making olddefconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  LEX     scripts/kconfig/lexer.lex.c
  YACC    scripts/kconfig/parser.tab.[ch]
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/menu.o
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTCC  scripts/kconfig/util.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
Starting Build
  GEN     arch/x86/include/generated/asm/orc_hash.h
  WRAP    arch/x86/include/generated/uapi/asm/errno.h
  
[SNIP]

  BTF [M] net/hsr/hsr.ko
  BTF [M] net/qrtr/qrtr-mhi.ko
[TIMER]{BUILD}: 1921s
Making Modules
  SYMLINK /lib/modules/6.12.15-_jmaple__sb_ciq-6.12.y-27daed599f82+/build
  INSTALL /lib/modules/6.12.15-_jmaple__sb_ciq-6.12.y-27daed599f82+/modules.order

[SNIP]

  INSTALL /lib/modules/6.12.15-_jmaple__sb_ciq-6.12.y-27daed599f82+/kernel/net/qrtr/qrtr-mhi.ko
  STRIP   /lib/modules/6.12.15-_jmaple__sb_ciq-6.12.y-27daed599f82+/kernel/net/qrtr/qrtr-mhi.ko
  SIGN    /lib/modules/6.12.15-_jmaple__sb_ciq-6.12.y-27daed599f82+/kernel/net/qrtr/qrtr-mhi.ko
  DEPMOD  /lib/modules/6.12.15-_jmaple__sb_ciq-6.12.y-27daed599f82+
[TIMER]{MODULES}: 36s
Making Install
  INSTALL /boot
[TIMER]{INSTALL}: 23s
Setting Default Kernel to /boot/vmlinuz-6.12.15-_jmaple__sb_ciq-6.12.y-4e5411d06b62+ and Index to 3
Hopefully Grub2.0 took everything ... rebooting after time metrices
[TIMER]{MRPROPER}: 5s
[TIMER]{BUILD}: 1921s
[TIMER]{MODULES}: 36s
[TIMER]{INSTALL}: 23s
[TIMER]{TOTAL} 1992s
Rebooting in 10 seconds

Kselftest

Previous
$ grep '^ok ' 6.12.15-_jmaple__ciq-6.12.y-b3fa7c3036f6+.kselftest.log | wc -l
522

Current
$ grep '^ok ' 6.12.15-_jmaple__sb_ciq-6.12.y-4e5411d06b62+.kselftest.log | wc -l
522

6.12.15-_jmaple__ciq-6.12.y-b3fa7c3036f6+.kselftest.log

6.12.15-_jmaple__sb_ciq-6.12.y-4e5411d06b62+.kselftest.log

bmastbergen
bmastbergen previously approved these changes Mar 31, 2025
Copy link
Collaborator

@bmastbergen bmastbergen left a comment

Choose a reason for hiding this comment

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

🥌

Linn Crosetto and others added 5 commits April 1, 2025 18:13
jira LE-2629
feature Additional SecureBoot patches for dynamic lockdown
commit 78c8af872660c31779951583b6f1ebf283d95985
commit-source https://salsa.debian.org/kernel-team/linux.git
commit-patch-path debian/patches/features/all/lockdown
commit-info Checkout the commit sha above and move to the directory
            listed above to find Debian patches matching this commits
	    summary line.

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 <[email protected]>
[bwh: Forward-ported to 4.10: adjust context]
[Lukas Wunner: Forward-ported to 4.11: drop parts applied upstream]
[bwh: Forward-ported to 4.15 and lockdown patch set:
 - Pass result of efi_get_secureboot() in stub through to
   efi_set_secure_boot() in main kernel
 - Use lockdown API and naming]
[bwh: Forward-ported to 4.19.3: adjust context in update_fdt()]
[dannf: Moved init_lockdown() call after uefi_init(), fixing SB detection]
[bwh: Drop call to init_lockdown(), as efi_set_secure_boot() now calls this]
[bwh: Forward-ported to 5.6: efi_get_secureboot() no longer takes a
 sys_table parameter]
[bwh: Forward-ported to 5.7: EFI initialisation from FDT was rewritten, so:
 - Add Secure Boot mode to the parameter enumeration in fdtparams.c
 - Add a parameter to efi_get_fdt_params() to return the Secure Boot mode
 - Since Xen does not have a property name defined for Secure Boot mode,
   change efi_get_fdt_prop() to handle a missing property name by clearing
   the output variable]
[Salvatore Bonaccorso: Forward-ported to 5.10: f30f242 ("efi: Rename
arm-init to efi-init common for all arch") renamed arm-init.c to efi-init.c]

Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2629
feature Additional SecureBoot patches for dynamic lockdown
commit 78c8af872660c31779951583b6f1ebf283d95985
commit-source https://salsa.debian.org/kernel-team/linux.git
commit-patch-path debian/patches/features/all/lockdown
commit-info Checkout the commit sha above and move to the directory
            listed above to find Debian patches matching this commits
            summary line.
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]
Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2629
feature Additional SecureBoot patches for dynamic lockdown
commit 78c8af872660c31779951583b6f1ebf283d95985
commit-source https://salsa.debian.org/kernel-team/linux.git
commit-patch-path debian/patches/features/all/lockdown
commit-info Checkout the commit sha above and move to the directory
            listed above to find Debian patches matching this commits
            summary line.

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]>
Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2629
feature Additional SecureBoot patches for dynamic lockdown
commit 78c8af872660c31779951583b6f1ebf283d95985
commit-source https://salsa.debian.org/kernel-team/linux.git
commit-patch-path debian/patches/features/all/lockdown
commit-info Checkout the commit sha above and move to the directory
            listed above to find Debian patches matching this commits
            summary line.

These drivers allow mapping arbitrary memory ranges as MTD devices.
This should be disabled to preserve the kernel's integrity when it is
locked down.

* Add the HWPARAM flag to the module parameters
* When slram is built-in, it uses __setup() to read kernel parameters,
  so add an explicit check security_locked_down() check

Signed-off-by: Ben Hutchings <[email protected]>
Cc: Matthew Garrett <[email protected]>
Cc: David Howells <[email protected]>
Cc: Joern Engel <[email protected]>
Cc: [email protected]
Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2629
feature Fedora EFI status status
ommit 7a60169d168d6aae70aca10b7b71070666068529
commit-source https://gitlab.com/cki-project/kernel-ark/

This adds efi_status_to_str() for use when printing efi_status_t
messages, and reworks efi_status_to_err() so that the two use a common
list of errors.

Upstream Status: RHEL only
Signed-off-by: Peter Jones <[email protected]>
Signed-off-by: Jonathan Maple <[email protected]>
@PlaidCat PlaidCat force-pushed the {jmaple}_sb_ciq-6.12.y branch from 67a558f to b1cf04f Compare April 1, 2025 22:25
jira LE-2629

The config option CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT is enabled for
x86_64 from our base kernel-ark fork process however since we
prioritized the additional lockdown patches from Debian as they also
support ARM they've also set the config CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT
to for their arm configs as well so we must do the same.

For technical reasons its defined here:
https://salsa.debian.org/kernel-team/linux/-/blob/debian/latest/debian/config/config?ref_type=heads#L7762

It was validated that this is the generic setting by downloading their
arm64 configs from here:
https://packages.debian.org/sid/amd64/linux-config-6.12/download
Copy link

@elguero elguero left a comment

Choose a reason for hiding this comment

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

Changes LGTM and look sane. A second approval from @jason-rodri would be good before merging.

@PlaidCat PlaidCat merged commit 007f9ec into ciq-6.12.y Apr 2, 2025
6 checks passed
@PlaidCat PlaidCat deleted the {jmaple}_sb_ciq-6.12.y branch April 2, 2025 17:48
PlaidCat pushed a commit that referenced this pull request Apr 2, 2025
…tion

commit 3d4114a upstream.

Address a lockdep warning triggered by the use of the clk_gating.lock before
it is properly initialized. The warning is as follows:

[    4.388838] INFO: trying to register non-static key.
[    4.395673] The code is fine but needs lockdep annotation, or maybe
[    4.402118] you didn't initialize this object before use?
[    4.407673] turning off the locking correctness validator.
[    4.413334] CPU: 5 UID: 0 PID: 58 Comm: kworker/u32:1 Not tainted 6.12-rc1 #185
[    4.413343] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
[    4.413362] Call trace:
[    4.413364]  show_stack+0x18/0x24 (C)
[    4.413374]  dump_stack_lvl+0x90/0xd0
[    4.413384]  dump_stack+0x18/0x24
[    4.413392]  register_lock_class+0x498/0x4a8
[    4.413400]  __lock_acquire+0xb4/0x1b90
[    4.413406]  lock_acquire+0x114/0x310
[    4.413413]  _raw_spin_lock_irqsave+0x60/0x88
[    4.413423]  ufshcd_setup_clocks+0x2c0/0x490
[    4.413433]  ufshcd_init+0x198/0x10ec
[    4.413437]  ufshcd_pltfrm_init+0x600/0x7c0
[    4.413444]  ufs_qcom_probe+0x20/0x58
[    4.413449]  platform_probe+0x68/0xd8
[    4.413459]  really_probe+0xbc/0x268
[    4.413466]  __driver_probe_device+0x78/0x12c
[    4.413473]  driver_probe_device+0x40/0x11c
[    4.413481]  __device_attach_driver+0xb8/0xf8
[    4.413489]  bus_for_each_drv+0x84/0xe4
[    4.413495]  __device_attach+0xfc/0x18c
[    4.413502]  device_initial_probe+0x14/0x20
[    4.413510]  bus_probe_device+0xb0/0xb4
[    4.413517]  deferred_probe_work_func+0x8c/0xc8
[    4.413524]  process_scheduled_works+0x250/0x658
[    4.413534]  worker_thread+0x15c/0x2c8
[    4.413542]  kthread+0x134/0x200
[    4.413550]  ret_from_fork+0x10/0x20

To fix this issue, ensure that the spinlock is only used after it has been
properly initialized before using it in ufshcd_setup_clocks().  Do that
unconditionally as initializing a spinlock is a fast operation.

Fixes: 209f4e4 ("scsi: ufs: core: Introduce a new clock_gating lock")
Reported-by: Dmitry Baryshkov <[email protected]>
Tested-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Avri Altman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Bean Huo <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

7 participants