- openSUSE Kernel

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

Re: Build 20230505 Kernel LockDown
by Andrei Borzenkov 08 May '23

08 May '23

On 08.05.2023 17:29, Joe Salmeri wrote: > HI Andrei > > On 5/8/23 00:50, Andrei Borzenkov wrote: >> On 07.05.2023 21:25, Joe Salmeri wrote: >>> >>> I just updated from 20230413 to 20230505 and after rebooting vmware >>> kernel modules ( after recompiling for kernel 6.3.1-1 ) would not load. >>> >>> modprobe: ERROR: could not insert 'vmmon': Key was rejected by >>> service >>> modprobe: ERROR: could not insert 'vmnet': Key was rejected by >>> service >>> >> >> Post kernel messages (dmesg output) at the time when you see this >> error. Even better in such cases is to provide full dmesg output. >> > I interpreted the 2 modprobe messages to indicate that since the 2 > vmware modules were not signed they were rejected. > > The same errors were thrown in my test environment and in my main desktop. > > > As a test for you, I recompiled both modules again in my test > environment, but this time I did NOT sign them. > > > I ran 'journalctl -k -xef' in one konsole session and in another konsole > session I ran 'systemctl start vmware' > > The only 2 messages that were displayed were > > May 08 10:17:56 Test-VM: Loading of unsigned module is rejected > May 08 10:17:56 Test-VM: Loading of unsigned module is rejected > > So that seems to indicate that the kernel was changed back to requiring > signed modules. > Yes, although it probably is not exactly lockdown. It is due to CONFIG_IMA_ARCH_POLICY=y which was set by this commit: commit 90a46594a115a4abf9381bd4c327fd875ac0da0b Author: Lee, Chun-Yi <jlee(a)suse.com> Date: Thu Mar 9 13:25:10 2023 +0800 Update config files. Add the following config to x86_64, arm64 and i386. CONFIG_IMA_ARCH_POLICY=y CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y This config be used to detect secure boot. (bsc#1209006) There is no way to override it at run time (except disabling secure boot). Cc kernel. > If I boot back to the previous kernel which was 6.2.10-1, then the > unsigned vmware modules load fine. > > If I follow the steps in my original message and sign the vmware > modules, then kernel 6.3.1.1 loads the modules, the service starts and > vmware works. > > >>> I have not see an announcement regarding kernel lockdown being enabled >> >> Where do you see any indication of kernel lockdown? >> > Everything I had noted from the last time that kernel lockdown was > enabled, indicates that it is NOT locked down with 6.3.1-1. > > I don't understand why everything indicates that lockdown is NOT > enabled, however, the actual messages from the journal/dmesg indicate > that unsigned modules can no longer be loaded with the 6.3.1-1 kernel > and signing them allows them to load so clearly something changed. > > Maybe they found a way to deal with the previous issues that occurred > back with the 6.2 kernel where lockdown would not allow signing with > secondary keys and loading the modules? > > Hopefully Jira,will see these messages and chime in.... > >

1 0

Error building TW kernel locally
by DB 01 May '23

01 May '23

Hey, I'm trying to build the Tumbleweed kernel 6.2.12 on my machine running the same version to test some patches. I had built kernels like this in the past on TW but now I'm not having much luck. I've installed kernel-source-6.2.12-1.1 package from the repo, copied over /usr/src/linux-6.2.12-1 to my home dir, ran `make oldconfig` there, changed CONFIG_LOCALVERSION to "-1-test" in .config and then `make -j 12 binrpm-pkg`. I didn't apply any patches yet, just want to get the base kernel working. The build ends with errors: make[2]: *** [Makefile:2036: .] Error 2 make[1]: *** [scripts/Makefile.package:79: binrpm-pkg] Error 2 make: *** [Makefile:1680: binrpm-pkg] Error 2 There's also some errors about certs in the middle: make[4]: *** No rule to make target '.kernel_signing_key.pem', needed by 'certs/signing_key.x509'. Stop. make[4]: *** Waiting for unfinished jobs.... HOSTCC certs/extract-cert make[3]: *** [scripts/Makefile.build:505: certs] Error 2 make[3]: *** Waiting for unfinished jobs.... The whole output is here https://pastebin.com/vhxM5swj I'm not really sure is it because of the certs or something else. Anybody has any ideas? David

7 11

Kernel:HEAD with lockdown enabled
by Frank Krüger 03 Apr '23

03 Apr '23

Hi there, kernel-default-6.3~rc4-2.1.g3ee059d.x86_64 from Kernel:HEAD has 'cat /sys/kernel/security/lockdown = integrity'? Is this on purpose? Regards, Frank

3 2

Anybody booted the latest Leap update kernel successfully on an intel graphics machine?
by Stefan Seyfried 19 Mar '23

19 Mar '23

Hi, see $SUBJECT: has anyone succeeded with booting 5.14.21-150400.24.49-default on an i915 graphics machine without "nomodeset"? nomodeset works for me, but the 80x25 console is really annoying. Any secret i915 module parameters that are nowadays mandatory and which I did forget to add? best regards, -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

5 5

What about enabling CONFIG_IKHEADERS in master?
by Petr Tesařík 16 Mar '23

16 Mar '23

Hi, I have recently built a few custom kernels (locally, not packaged), and I quickly ran into an issue with eBPF not able to find kernel headers (or finding the wrong ones). The kernel headers can be packed into a kernel module (kheaders.ko) if CONFIG_IKHEADERS=m. Would anyone object to enabling this option on master branch? Cheers Petr T

3 4

6.2.2 will NOT have lockdown patches
by Jiri Slaby 10 Mar '23

10 Mar '23

Hi all, due to regressions we saw with lockdown patches in Tumbleweed (esp. bsc#1209006), I decided to disable the lockdown patches for now. This will be merged with 6.2.2 (SR#1070329). You can use (the currently building) Kernel:stable too. Lockdown will be retried once in better shape. Or maybe secureboot will be buried in history at that time and we won't care ;). (I have blacklotus on my mind.) The current (might be extended later or at your request) conditions are: * external modules would work out of the box * the bug asking to enable lockdown would be visible to all sorry for all the trouble, -- js suse labs

3 3

6.2.1 will have lockdown patches
by Jiri Slaby 02 Mar '23

02 Mar '23

Hi all, just so you know, as per bug 1198101, the kernel for Tumbleweed received patchset for locked down kernel (see the bug). This will be a part of the 6.2.1 submission (SR#1068171). Few notes: * Hibernation does not work when secure boot is enabled (bug 1208766) * Leap inherited/contains this patchset long from SLE time ago. regards, -- js suse labs

1 0

15.4 kernel 5.14.21-150400.24.38-default not respecting vers=1.0 for OS/2 LAN connectivity
by Felix Miata 06 Jan '23

06 Jan '23

5.14.21-150400.24.38-default boots, but I can't use it, because OS/2 connectivity is a must. 5.14.21-150400.24.33-default solves the problem, keeps OS/2 connected. What changed this time? I looked in the 24.38 changlog since 24.33 release and didn't spot anything. The vers=1.0 hit in the error message doesn't seem could apply, since it's already being used: /etc/fstab includes: //os2/G /smbmnt/os2/G cifs ro,credentials=/etc/samba/os2.cred,noserverino,sec=lanman,vers=1.0,servern=OS2,domain=PEERS,port=139,dir_mode=0555,file_mode=0664,noauto 0 0 # alias | grep mountos2 alias mountos2='mount //os2/G' # mountos2 mount error: Server abruptly closed the connection. This can happen if the server does not support the SMB version you are trying to use. The default SMB version recently changed from SMB1 to SMB2.1 and above. Try mounting with vers=1.0. mount error(112): Host is down Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) With the older kernel and working as expected, the journal contained the following: ## kernel 24.33 - OK # journalctl -b | grep -i -C3 cifs > Jan 01 03:47:59 at-spi-bus-launcher[1378]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry Jan 01 03:48:06 kernel: FS-Cache: Loaded Jan 01 03:48:06 kernel: Key type dns_resolver registered Jan 01 03:48:06 kernel: FS-Cache: Netfs 'cifs' registered for caching Jan 01 03:48:06 kernel: Key type cifs.spnego registered Jan 01 03:48:06 kernel: Key type cifs.idmap registered Jan 01 03:48:06 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: Attempting to mount \\mazda\E Jan 01 03:48:06 kernel: CIFS: VFS: Send error in QFSAttributeInfo = -95 Jan 01 03:48:06 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: Attempting to mount \\mazda\G Jan 01 03:48:06 kernel: CIFS: VFS: Send error in QFSAttributeInfo = -95 Jan 01 03:48:06 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: Attempting to mount \\mazda\I Jan 01 03:48:06 kernel: CIFS: VFS: Send error in QFSAttributeInfo = -95 Jan 01 03:48:06 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: Attempting to mount \\mazda\J Jan 01 03:48:06 kernel: CIFS: VFS: Send error in QFSAttributeInfo = -95 ... Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:58:04 kernel: CIFS: VFS: bogus file nlink value 0 Jan 01 03:58:04 kernel: CIFS: VFS: bogus file nlink value 0 ... Jan 01 04:18:25 kernel: CIFS: VFS: bogus file nlink value 0 Jan 01 04:18:25 kernel: CIFS: VFS: bogus file nlink value 0 With the 5.14.21-150400.24.38 kernel, I get the following excerpts instead from a full journal at https://susepaste.org/29524759 : Jan 01 03:23:52 kernel: CIFS: Attempting to mount \\os2\E Jan 01 03:23:52 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:23:52 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:52 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:52 kernel: CIFS: Attempting to mount \\os2\G Jan 01 03:23:52 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:23:52 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:52 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:52 kernel: CIFS: Attempting to mount \\os2\I Jan 01 03:23:53 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:23:53 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:53 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:53 kernel: CIFS: Attempting to mount \\os2\J Jan 01 03:23:53 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:36:00 systemd[1]: Starting Cleanup of Temporary Directories... Jan 01 03:36:00 systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully. Jan 01 03:36:00 systemd[1]: Finished Cleanup of Temporary Directories. Jan 01 03:37:57 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:57 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:57 kernel: CIFS: Attempting to mount \\os2\E Jan 01 03:37:58 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:37:58 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:58 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:58 kernel: CIFS: Attempting to mount \\os2\G Jan 01 03:37:58 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:37:58 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:58 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:58 kernel: CIFS: Attempting to mount \\os2\I Jan 01 03:37:59 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:38:13 systemd-logind[843]: New session 3 of user root. Jan 01 03:38:13 systemd[1]: Started Session 3 of User root. Jan 01 03:38:13 kdm[1021]: :0[1021]: pam_unix(xdm:session): session opened for user root by (uid=0) -- Jan 01 03:38:16 at-spi-bus-launcher[1499]: dbus-daemon[1499]: Successfully activated service 'org.a11y.atspi.Registry' Jan 01 03:38:16 at-spi-bus-launcher[1516]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry Jan 01 03:38:37 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:37 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:37 kernel: CIFS: Attempting to mount \\os2\E Jan 01 03:38:38 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:38:38 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:38 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:38 kernel: CIFS: Attempting to mount \\os2\G Jan 01 03:38:38 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:38:38 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:38 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:38 kernel: CIFS: Attempting to mount \\os2\I Jan 01 03:38:39 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:38:39 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:39 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:39 kernel: CIFS: Attempting to mount \\os2\J Jan 01 03:38:39 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:46:41 kdm[1021]: :0[1021]: pam_unix(xdm:session): session closed for user root Jan 01 03:46:41 at-spi-bus-launcher[1516]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" Jan 01 03:46:41 at-spi-bus-launcher[1516]: after 157 requests (157 known processed) with 0 events remaining. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

2 1

new Kernel:stable/kernel-source tarball signature
by Hans-Peter Jansen 06 Oct '22

06 Oct '22

Hi, my local kernel-source builds fails, due to: [ 148s] error: Bad file: /home/abuild/rpmbuild/SOURCES/linux.keyring: No such file or directory [ 148s] error: Bad file: /home/abuild/rpmbuild/SOURCES/linux-5.19.tar.sign: No such file or directory Kernel:stable/kernel-source does have these files, and commit e76c4ca of https://github.com/openSUSE/kernel-source implies, that those comes straight from the public archives now, therefore the ability to create the kernel tarball from a local git tree via export LINUX_GIT=... seems to be lost. Am I missing something here? Best, Pete -- Life without chameleons is possible, but pointless.

2 2