Problem: Currently with the new USE=generic-uki on gentoo-kernel-bin, it is not possible to enable both the firmware's secure boot and the kernel's lockdown=integrity mode. The problem arises because gentoo-kernel-bin by default does not force lockdown mode, among other things it enforces that modules are signed. Enabling it by default would complicate things for users who don't care about signed modules. However, when using a unified kernel image with secureboot enabled, it is not possible to override the kernel cmdline and enable lockdown=integrity mode. This is something you probably do want, since it does not make sense to first enforce that all (unified) kernel images are signed, but then allow arbitrary unsigned modules to be loaded. Fedora and Ubuntu (and presumably derivatives), have a solution for this in the form of a kernel patch[1] that enables lockdown=integrity mode by default when secureboot is enabled. This ensures that users who wish to enforce signed kernels at boot by enabling secure boot, also have similar protection at kernel runtime via lockdown=integrity. Without complicating things for users who don't care about signed kernels or modules. This patch was rejected upstream [2]. Possible solutions for our problem in the generic-uki are: 1) add lockdown=integirty to the default kernel cmdline of the generic-uki (enable lockdown by default in the UKI, but not in the plain kernel image, regardless of secure boot status. It is still possible to override the lockdown mode to none, but only when secure boot is disabled). 2) drop the kernel config override used when building gentoo-kernel-bin[3] (enable lockdown mode by default for all users of gentoo-kernel-bin, they must now sign external modules always or explicitly disable lockdown mode, regardless of secure boot status. It is still possible to override the lockdown mode to none, but in the generic-uki only when secure boot is disabled). 3) adopt Fedora's patches, and specify LOCK_DOWN_IN_EFI_SECURE_BOOT=y for gentoo-kernel (lockdown=integrity is the default for both gentoo-kernel and gentoo-kernel-bin when secure boot is enabled) Lets discuss here what is the best solution. I'm currently leaning towards either 1 or 3. 2 has the disadvantage of changing the default for everyone, requiring manual user action to ensure third party modules still work. 1 fixes the problem with the smallest impact on other things, but does introduce a discrepancy in the default behaviour of the generic unified kernel image and the plain kernel image. Of course 3 is only an option if the kernel project is willing to maintain this extra patch, knowing that there is probably no chance that it will ever be upstreamed, though maintenance should be low on our side since we can copy what Fedora does. [1] https://gitlab.com/cki-project/kernel-ark/-/commit/5850c93175b9d2e1081873f4bbe08dead202cb08 [2] https://lore.kernel.org/lkml/CA+55aFwVUmjZ+Swe9xUdDOEE+EOoaU3dh7BcrH74BOLCi8y_Kw@mail.gmail.com/ [3] https://github.com/projg2/binpkg-docker/blob/master/kernel-configd
The linked PR [1] implements solution 1. Please let me know if solution 3 is also acceptable, I personally don't have a strong preference for either solution. [1] https://github.com/gentoo/gentoo/pull/34616
Created attachment 881556 [details] patchset I've determined which patches exactly we need for solution 3, rebased and tested these locally. Patchset attached. The required patches are: - security: lockdown: expose a hook to lock the kernel down https://gitlab.com/cki-project/kernel-ark/-/commit/72223fd1241cc5c70b96a491db14d54c83beadd8 - efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode https://gitlab.com/cki-project/kernel-ark/-/commit/53250b991f841be025fa4d264850dadc0fae2861 - efi: Lock down the kernel if booted in secure boot mode https://gitlab.com/cki-project/kernel-ark/-/commit/5850c93175b9d2e1081873f4bbe08dead202cb08 The fourth patch is a bonus that makes similar changes for the IPL secure flag on s390. We don't currently support s390 in sys-kernel/gentoo-kernel, and I don't have the hardware so its untested, this patch we can skip. Included it in the tarball for completeness. - s390: Lock down the kernel when the IPL secure flag is set https://gitlab.com/cki-project/kernel-ark/-/commit/2384646bf71d8c282cf49bb20321fdf802c61cce Tested on 6.6.10, it works as it should: SecureBoot off: andrew@andrew-gentoo-pc ~ % cat /sys/kernel/security/lockdown [none] integrity confidentiality SecureBoot on: andrew@andrew-gentoo-pc ~ % cat /sys/kernel/security/lockdown none [integrity] confidentiality dmesg: [ 0.000000] efi: EFI v2.7 by American Megatrends [ 0.000000] efi: TPMFinalLog=0x79afd000 ACPI 2.0=0x79a77000 ACPI=0x79a77000 SMBIOS=0x7ad29000 MEMATTR=0x743 1b018 ESRT=0x7440fe98 MOKvar=0x7ad3e000 RNG=0x796c8f18 INITRD=0x6f845a98 TPMEventLog=0x6d0e8018 [ 0.000000] random: crng init done [ 0.000000] efi: Remove mem60: MMIO range=[0xe0000000-0xefffffff] (256MB) from e820 map [ 0.000000] e820: remove [mem 0xe0000000-0xefffffff] reserved [ 0.000000] efi: Not removing mem61: MMIO range=[0xfe000000-0xfe010fff] (68KB) from e820 map [ 0.000000] efi: Not removing mem62: MMIO range=[0xfec00000-0xfec00fff] (4KB) from e820 map [ 0.000000] efi: Not removing mem63: MMIO range=[0xfed00000-0xfed00fff] (4KB) from e820 map [ 0.000000] efi: Not removing mem64: MMIO range=[0xfee00000-0xfee00fff] (4KB) from e820 map [ 0.000000] efi: Remove mem65: MMIO range=[0xff000000-0xffffffff] (16MB) from e820 map [ 0.000000] e820: remove [mem 0xff000000-0xffffffff] reserved [ 0.000000] secureboot: Secure boot enabled [ 0.000000] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7 [ 0.000000] SMBIOS 2.8 present. [ 0.000000] DMI: Micro-Star International Co., Ltd. MS-7B48/Z370-A PRO (MS-7B48), BIOS 2.D3 11/18/2021
Gentle ping. I feel it is important to resolve this somehow. We have gone through the trouble of signing the modules and (unified) kernel images. But currently users can choose to verify the unified kernel image (by enabling secure boot via UEFI firmware), or choose to verify the kernel modules (by enabling lockdown mode via kernel command line), but it is impossible to force verification of both. This kind of defeats the purpose of the generic-uki (or at least part of the purpose). Note that the patches for solution 3 only cause runtime changes if CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT=y which is disabled by default. So we could add these patches without causing any changes for gentoo-sources users (unless they opt-into this by enabling the config option). I also still feel solution 1 is acceptable since it only effects the (still experimental and stable masked) generic-uki. But I know Michal disagrees with me.
