July 2023 - openSUSE Kernel - openSUSE Mailing Lists

Kmod's new usr-lib-modules.patch breaks Vanilla kernel RPM building
by Bjoern Voigt 21 Jul '23

21 Jul '23

I found, that the latest Tumbleweek Kmod patch usr-lib-modules.patch breaks Vanilla kernel RPM building. I use "make binrpm-pkg". This breaks the "depmod_hack_needed" hack in scripts/depmod.sh. See this example build of Linux-6.1.36: myuser@mybox:/usr/src/linux-6.1-lts/linux-6.1.36> make binrpm-pkg [...] INSTALL /home/myuser/rpmbuild/BUILDROOT/kernel-6.1.36_myuser1-1.x86_64/lib/modules/6.1.36-myuser1/kernel/sound/x86/snd-hdmi-lpe-audio.ko INSTALL /home/myuser/rpmbuild/BUILDROOT/kernel-6.1.36_myuser1-1.x86_64/lib/modules/6.1.36-myuser1/kernel/sound/xen/snd_xen_front.ko INSTALL /home/myuser/rpmbuild/BUILDROOT/kernel-6.1.36_myuser1-1.x86_64/lib/modules/6.1.36-myuser1/kernel/virt/lib/irqbypass.ko DEPMOD /home/myuser/rpmbuild/BUILDROOT/kernel-6.1.36_myuser1-1.x86_64/lib/modules/6.1.36-myuser1 depmod: ERROR: could not open directory /home/myuser/rpmbuild/BUILDROOT/kernel-6.1.36_myuser1-1.x86_64/usr/lib/modules/99.98.6.1.36-myuser1: No such file or directory depmod: FATAL: could not search modules: No such file or directory make[2]: *** [Makefile:1942: modules_install] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.PiILLZ (%install) RPM build warnings: line 22: It's not recommended to have unversioned Obsoletes: Obsoletes: kernel-headers RPM build errors: Bad exit status from /var/tmp/rpm-tmp.PiILLZ (%install) There are probably multiple possible solutions or hacks. The new "depmod" uses "/usr" as a static prefix for kernel modules. This can't be disabled via command line options. I compiled kmod with usr-lib-modules.patch disabled and use "depmod" from the modified package temporary for "make binrpm-pkg". This works. Are there better solutions available? Björn

3 3

Kernel 6.4.3 comes with lockdown enabled
by Frank Krüger 13 Jul '23

13 Jul '23

JFYI: Kernel 6.4.3-3.g5ab030f-default from Kernel:stable has lockdown enabled (i.e. "cat /sys/kernel/security/lockdown -> integrity"), which was announced some time ago. Since hibernation is not working in this case with secure boot enabled, is there any solution in sight? Thx. Regards, Frank

4 8

The lockdown function be enabled in master branch of openSUSE kernel
by joeyli 12 Jul '23

12 Jul '23

Hi folks, After testing NVIDIA kmp with lockdown kernel, the lockdown function be enabled in master branch of openSUSE Tumbleweed kernel again. (SLE and Leap kernels are already enabled) The following patches are unmartked: patches.suse/0001-security-lockdown-expose-a-hook-to-lock-the-kernel-down.patch patches.suse/0002-efi-Add-an-EFI_SECURE_BOOT-flag-to-indicate-secure-boot-mode.patch patches.suse/0003-efi-Lock-down-the-kernel-if-booted-in-secure-boot-mode.patch patches.suse/0004-efi-Lock-down-the-kernel-at-the-integrity-level-if-b.patch patches.suse/arm64-lock-down-kernel-in-secure-boot-mode.patch The following config be enabled. It will load MOK (machine owner key) to kernel keyring: CONFIG_IMA_ARCH_POLICY=y CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y The following downstream config be enabled on x86_64 and aarch64. It will connect lockdown function with secure boot option in EFI firmware: CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT=y Kernel will set to integrity lockdown mode when secure boot be enabled: linux/security.h enum lockdown_reason { LOCKDOWN_NONE, LOCKDOWN_MODULE_SIGNATURE, // kernel module verification LOCKDOWN_DEV_MEM, LOCKDOWN_EFI_TEST, LOCKDOWN_KEXEC, LOCKDOWN_HIBERNATION, LOCKDOWN_PCI_ACCESS, LOCKDOWN_IOPORT, LOCKDOWN_MSR, LOCKDOWN_ACPI_TABLES, LOCKDOWN_DEVICE_TREE, LOCKDOWN_PCMCIA_CIS, LOCKDOWN_TIOCSSERIAL, LOCKDOWN_MODULE_PARAMETERS, LOCKDOWN_MMIOTRACE, LOCKDOWN_DEBUGFS, // restricted debugfs LOCKDOWN_XMON_WR, LOCKDOWN_BPF_WRITE_USER, // BPF write LOCKDOWN_DBG_WRITE_KERNEL, LOCKDOWN_RTAS_ERROR_INJECTION, LOCKDOWN_INTEGRITY_MAX, // integrity mode LOCKDOWN_KCORE, LOCKDOWN_KPROBES, LOCKDOWN_BPF_READ_KERNEL, // BPF read LOCKDOWN_DBG_READ_KERNEL, LOCKDOWN_PERF, LOCKDOWN_TRACEFS, LOCKDOWN_XMON_RW, LOCKDOWN_XFRM_SECRET, LOCKDOWN_CONFIDENTIALITY_MAX, // confidentiality mode }; As you see, the kernel module verification will be enabled. So please sign your self-built kernel module. You can reference this section in openSUSE UEFI wiki page: https://en.opensuse.org/openSUSE:UEFI#Signing_kernel_module_for_verification Please enroll your key to MOK by mokutil. If you didn't use shim, e.g. systemd-boot/dracut solution. I have created a bug bsc#1211224. Currently we do not support it with secure boot. Let's discuss it in bsc#1211224. Regards Joey Lee

9 37