The openSUSE Tumbleweed kernel is lockded-down since v6.4.3 when secure boot is enabled. It means that the behavior of Tumbleweed kernel will align with SLE and openSUSE Leap when secure boot is enabled.

1. Locked down openSUSE
Tumbleweed kernel
openSUSE.Asia Summit 2023, Chongqing
SUSE Labs Taipei
Joey Lee
jlee@suse.com

2. Agenda
●
What is kernel lockdown mode
●
Why lock down Tumbleweed kernel?
●
Which functions are locked-down?

3. Kernel lockdown mode
●
Kernel lockdown mode be merged in kernel
mainline since v5.4 kernel.
– Commit id: aefcf2f4b5 [September, 2019]
●
Be introduced in SLE/openSUSE:
– SLE11-SP3 v3.0 kernel July, 2013
– openSUSE Leap 42.2 v4.4 kernel November, 2016
– Fedora core 20 (maybe earlier) v3.11 kernel December, 2013
– openSUSE Tumbleweed kernel v6.4.3 kernel July, 2023

4. Kernel lockdown mode (cont.)
●
This patchset introduces an optional kernel
lockdown feature, intended to strengthen the
boundary between UID 0 and the kernel. When
enabled, various pieces of kernel functionality are
restricted. [1]
●
In dmesg:
[ 0.000000] Kernel is locked down from EFI Secure Boot mode; see
man kernel_lockdown.7
[ 25.299313] Lockdown: numlockbios: /dev/mem,kmem,port is
restricted; see man kernel_lockdown.7

5. Why Lockdown Tumbleweed
kernel?
●
Improve kernel security.
●
Sync with big distros. Especially sync with SLE
and openSUSE Leap.
– Applications developed on Tumbleweed (non-
lockdown) may not work on SLE/openSUSE Leap
(lockdown).
●
The opensuse-cert-prompt patch does not pass
shim-review. (bsc#1198101)[4]

6. States of lockdown
●
None
●
Integrity
– kernel features that allow userland to modify
the running kernel are disabled.
●
Confidentiality
– kernel features that allow userland to extract
confidential information from the kernel are
also disabled.

7. States of lockdown (cont.)
●
The state of lockdown can only be
upgraded, not downgraded:
– None → Integrity → Confidentiality
The inverse is not
# cat /sys/kernel/security/lockdown
none [integrity] confidentiality
# echo none > /sys/kernel/security/lockdown
-bash: echo: write error: Operation not permitted

8. SUSE setting of lockdown state
●
CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y
CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set
CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set
●
CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT=y
(x86_64, arm64)
– Link lockdown mode (integrity state) with UEFI
secure boot.

9. SUSE setting of lockdown state
(cont.)
●
CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT=y
(x86_64, arm64)
– Link lockdown mode (integrity state) with UEFI
secure boot.
– Applied downstream patches:
0003-efi-Lock-down-the-kernel-if-booted-in-secure-boot-mode.patch
0004-efi-Lock-down-the-kernel-at-the-integrity-level-if-b.patch
– Some kernel upstream experts think that lockdown
should not relates to a firmware option. [2]

10. Which functions are locked-down
(Integrity state)
●
LOCKDOWN_MODULE_SIGNATURE: unsigned module loading
●
LOCKDOWN_DEV_MEM: /dev/mem,kmem,port
●
LOCKDOWN_EFI_TEST: /dev/efi_test access
●
LOCKDOWN_KEXEC: kexec of unsigned images
●
LOCKDOWN_HIBERNATION: hibernation
●
LOCKDOWN_PCI_ACCESS: direct PCI access
●
LOCKDOWN_IOPORT: raw io port access
●
LOCKDOWN_MSR: raw MSR access
●
LOCKDOWN_ACPI_TABLES: modifying ACPI tables Kernel v6.6-rc3

11. Which functions are locked-down
(integrity state)(cont.)
●
LOCKDOWN_DEVICE_TREE: modifying device tree contents
●
LOCKDOWN_PCMCIA_CIS: direct PCMCIA CIS storage
●
LOCKDOWN_TIOCSSERIAL: reconfiguration of serial port IO
●
LOCKDOWN_MODULE_PARAMETERS: unsafe module parameters
●
LOCKDOWN_MMIOTRACE: unsafe mmio
●
LOCKDOWN_DEBUGFS: debugfs access
●
LOCKDOWN_XMON_WR: xmon write access
●
LOCKDOWN_BPF_WRITE_USER: use of bpf to write user RAM Kernel v6.6-rc3

12. Which functions are locked-down
(integrity state)(cont.)
●
LOCKDOWN_DBG_WRITE_KERNEL: use of kgdb/kdb to write kernel RAM
●
LOCKDOWN_RTAS_ERROR_INJECTION: RTAS error injection
Kernel v6.6-rc3

13. Which functions are locked-down
(confidentiality state)
●
LOCKDOWN_KCORE: /proc/kcore access
●
LOCKDOWN_KPROBES: use of kprobes
●
LOCKDOWN_BPF_READ_KERNEL: use of bpf to read kernel RAM
●
LOCKDOWN_DBG_READ_KERNEL: use of kgdb/kdb to read kernel RAM
●
LOCKDOWN_PERF: unsafe use of perf
●
LOCKDOWN_TRACEFS: use of tracefs
●
LOCKDOWN_XMON_RW: xmon read and write access
●
LOCKDOWN_XFRM_SECRET: xfrm SA secret Kernel v6.6-rc3

14. LOCKDOWN_MODULE_SIGNATURE
●
Commit id: 49fcf732bd
lockdown: Enforce module signatures if the kernel is
locked down
●
It equals CONFIG_MODULE_SIG_FORCE
●
Reject unsigned modules or signed modules for
which we don't have a key. Without this, such
modules will simply taint the kernel.

15. LOCKDOWN_DEV_MEM
●
Commit id: 9b9d8dda1e
lockdown: Restrict /dev/{mem,kmem,port} when the
kernel is locked down
●
Allowing users to read and write to core kernel memory
makes it possible for the kernel to be subverted,
avoiding module loading restrictions, and also to steal
cryptographic information.

16. LOCKDOWN_DEV_MEM (cont.)
●
Disallow /dev/mem and /dev/kmem from being opened
this when the kernel has been locked down to prevent
this.
●
Disallow /dev/port from being opened to prevent raw
ioport access and thus DMA from being used to
accomplish the same thing.

17. LOCKDOWN_DEV_MEM(cont.)
●
CONFIG_STRICT_DEVMEM=y
CONFIG_IO_STRICT_DEVMEM=y
– mmap

18. LOCKDOWN_KEXEC
●
Commit id: 7d31f4602f
kexec_load: Disable at runtime if the kernel is locked
down
●
The kexec_load() syscall permits the loading and
execution of arbitrary code in ring 0, which is something
that lock-down is meant to prevent. It makes sense to
disable kexec_load() in this situation.
●
This does not affect kexec_file_load() syscall which can
check for a signature on the image to be booted.

19. LOCKDOWN_HIBERNATION
●
Commit id: 38bd94b8a1
hibernate: Disable when the kernel is locked down
●
There is currently no way to verify the resume image
when returning from hibernate. This might compromise
the signed modules trust model, so until we can work
with signed hibernate images we disable it when the
kernel is locked down.
# cat /sys/power/state
freeze mem

20. LOCKDOWN_HIBERNATION (cont.)
●
Evan Green: [PATCH v5 00/11] Encrypted Hibernation
https://lkml.org/lkml/2022/11/11/1229
●
Bug 1208766 - Kernel 6.2.1 does not suspend/hibernate
anymore for AMD Ryzen 7 Pro

21. LOCKDOWN_PCI_ACCESS
●
Commit id: eb627e1772
PCI: Lock down BAR access when the kernel is locked
down
●
Any hardware that can potentially generate DMA has to
be locked down in order to avoid it being possible for an
attacker to modify kernel code, allowing them to
circumvent disabled module loading or module signing.
Default to paranoid - in future we can potentially relax
this for sufficiently IOMMU-isolated devices.

22. LOCKDOWN_PCI_ACCESS (cont.)
●
/sys/devices/pci0000:00/0000:00:01.3/config
●
/sys/devices/pci0000:00/0000:00:01.3/0000:04:00.0/resource4
/sys/devices/pci0000:00/0000:00:01.3/0000:04:00.0/resource4_wc
– mmap
●
/proc/bus/pci/00/01.3
●
/sbin/setpci -s 00:00.0 0x50.B=0x40

23. LOCKDOWN_IOPORT
●
Commit id: 96c4f67293
x86: Lock down IO port access when the kernel is locked
down
●
IO port access would permit users to gain access to PCI
configuration registers, which in turn (on a lot of
hardware) give access to MMIO register space. This
would potentially permit root to trigger arbitrary DMA,
so lock it down by default.
●
Ioperm() - set port input/output permissions

24. LOCKDOWN_MSR
●
Commit id: 95f5e95f41
x86/msr: Restrict MSR access when the kernel is locked
down
●
Writing to MSRs should not be allowed if the kernel is
locked down, since it could lead to execution of arbitrary
code in kernel mode.
●
/dev/cpu/0/msr
– rdmsr, wrmsr

25. LOCKDOWN_MSR (cont.)
●
Re: [PATCH] x86: Lock down MSR writing in secure boot
– Kees Cook: Yes, change the SYSENTER entry point to
where-ever you like.
http://grsecurity.net/~spender/msr32.c
SYSENTER_EIP_MSR
– _writing_ an MSR from userspace should be
considered a bug. If writing is needed, a kernel driver
should be mediating the change. [3]

26. LOCKDOWN_ACPI_TABLES
●
Commit id: f474e1486b
ACPI: Limit access to custom_method when the kernel is
locked down
●
custom_method effectively allows arbitrary access to
system memory, making it possible for an attacker to
circumvent restrictions on module loading. Disable it if
the kernel is locked down.
cat test.aml > /sys/kernel/debug/acpi/custom_method

27. LOCKDOWN_ACPI_TABLES (cont.)
●
Commit id: 75b0cea7bf
ACPI: configfs: Disallow loading ACPI tables when locked
down
●
this one here allows the root user to load ACPI tables,
which enables arbitrary physical address writes, which
in turn makes it possible to disable lockdown.
https://git.zx2c4.com/american-unsigned-language/tre
e/american-unsigned-language-2.sh
overwrite kernel_locked_down symbol

28. LOCKDOWN_ACPI_TABLES (cont.)
●
Commit id: 41fa1ee9c6
acpi: Ignore acpi_rsdp kernel param when the kernel has
been locked down
●
This option allows userspace to pass the RSDP address
to the kernel, which makes it possible for a user to
modify the workings of hardware. Reject the option
when the kernel is locked down.
– Root System Description Pointer (RSDP)

29. LOCKDOWN_ACPI_TABLES (cont.)
●
Commit id: 6ea0e815fc
acpi: Disable ACPI table override if the kernel is locked
down
– CONFIG_ACPI_TABLE_UPGRADE
– initrd_table_override.rst
●
ACPI tables contain code invoked by the kernel, so do
not allow ACPI tables to be overridden if the kernel is
locked down.

30. LOCKDOWN_ACPI_TABLES (cont.)
●
Commit id: 1957a85b00
efi: Restrict efivar_ssdt_load when the kernel is locked
down
– CONFIG_EFI_CUSTOM_SSDT_OVERLAYS
– efivar_ssdt=<EFI_VARIABLE_NAME>
●
efivar_ssdt_load allows the kernel to import arbitrary
ACPI code from an EFI variable, which gives arbitrary
code execution in ring 0. Prevent that when the kernel is
locked down. (ssdt-overlays.rst)

31. LOCKDOWN_MODULE_PARAMETERS
●
Commit id: 20657f66ef
lockdown: Lock down module params that specify
hardware parameters (eg. ioport)
●
Provided an annotation for module parameters that
specify hardware parameters (such as io ports, iomem
addresses, irqs, dma channels, fixed dma buffers and
other types).
●
arch/x86/mm/testmmiotrace.c
module_param_hw(mmio_address, ulong, iomem, 0);

32. LOCKDOWN_DEBUGFS
●
Commit id: 5496197f9b
debugfs: Restrict debugfs when the kernel is locked
down
●
Disallow opening of debugfs files that might be used to
muck around when the kernel is locked down as various
drivers give raw access to hardware through debugfs.

33. LOCKDOWN_DEBUGFS (cont.)
●
When the kernel is locked down, only files with the
following criteria are permitted to be opened:
– The file must have mode 00444
– The file must not have ioctl methods
– The file must not have mmap
●
When the kernel is locked down, files may only be
opened for reading.
●
Normal device interaction should be done through
configfs, sysfs or a miscdev, not debugfs.

34. LOCKDOWN_BPF_WRITE_USER
●
Commit id: 51e1bb9eea
bpf: Add lockdown check for probe_write_user helper
●
commit 96ae52279594 ("bpf: Add bpf_probe_write_user
BPF helper to be called in tracers") added the
bpf_probe_write_user() helper in order to allow to
override user space memory.
Its original goal was to have a facility to "debug, divert,
and manipulate execution of semi-cooperative
processes" under CAP_SYS_ADMIN.

35. LOCKDOWN_BPF_WRITE_USER
(cont.)
●
Write to kernel was explicitly disallowed since it would
otherwise tamper with its integrity.
●
cf9b1199de27 ("samples/bpf: Add test/example of using
bpf_probe_write_user bpf helper"

36. LOCKDOWN_EFI_TEST
●
Commit id: 359efcc2c9
efi/efi_test: Lock down /dev/efi_test and require
CAP_SYS_ADMIN
●
The driver exposes EFI runtime services to user-space
through an IOCTL interface, calling the EFI services
function pointers directly without using the efivar API.
●
Disallow access to the /dev/efi_test character device
when the kernel is locked down to prevent arbitrary
user-space to call EFI runtime services.

37. LOCKDOWN_DBG_WRITE_KERNEL
●
Commit id: eadb2f47a3
lockdown: also lock down previous kgdb use
●
KGDB and KDB allow read and write access to
kernel memory, and thus should be restricted
during lockdown.

38. LOCKDOWN_PCMCIA_CIS
●
Commit id: 3f19cad3fa
lockdown: Prohibit PCMCIA CIS storage when the kernel
is locked down
●
Prohibit replacement of the PCMCIA Card Information
Structure when the kernel is locked down.
●
The Card Information Structure (CIS) is a data structure
accessed through Card Services that contains
identification and configuration information about PC
Cards. [5]

39. LOCKDOWN_TIOCSSERIAL
●
Commit id: 794edf30ee
lockdown: Lock down TIOCSSERIAL
●
Lock down TIOCSSERIAL as that can be used to change
the ioport and irq settings on a serial port. This only
appears to be an issue for the serial drivers that use the
core serial code. All other drivers seem to either ignore
attempts to change port/irq or give an error.

40. LOCKDOWN_MMIOTRACE
●
Commit id: 906357f77a
x86/mmiotrace: Lock down the testmmiotrace module
●
The testmmiotrace module shouldn't be permitted when
the kernel is locked down as it can be used to arbitrarily
read and write MMIO space.

41. LOCKDOWN_DEVICE_TREE
●
Commit id: 99df7a2810
powerpc/pseries: block untrusted device tree changes
when locked down
●
The /proc/powerpc/ofdt interface allows the root user to
freely alter the in-kernel device tree, enabling arbitrary
physical address writes via drivers that could bind to
malicious device nodes, thus making it possible to
disable lockdown.
●
SUSE does NOT lock down kernel on powerpc.

42. LOCKDOWN_XMON_WR
●
Commit id: 69393cb03c
powerpc/xmon: Restrict when kernel is locked down
●
Xmon should be either fully or partially disabled
depending on the kernel lockdown state.
●
SUSE does NOT lock down kernel on powerpc.

43. LOCKDOWN_RTAS_ERROR_INJECTION
●
Commit id: b8f3e48834
powerpc/rtas: block error injection when locked down
●
The error injection facility on pseries VMs allows
corruption of arbitrary guest memory, potentially
enabling a sufficiently privileged user to disable
lockdown or perform other modifications of the running
kernel via the rtas syscall.
●
SUSE does NOT lock down kernel on powerpc.

44. Summary
●
Tumbleweed locked down kernel on x86_64 and arm64
to aline with SLE/Leap.
●
Tumbleweed kernel be locked down on integity state
when EFI secure boot is enabled.
●
General interfaces be restricted. Application should
accesses safe interface from specific driver.
●
Module parameters that specify hardware parameters
are also be restricted. (io ports, iomem addresses, irqs,
dma channels, fixed dma buffers and other types).

45. Reference
●
[1] Kernel lockdown patches for v5.4
https://lore.kernel.org/lkml/alpine.LRH.2.21.1909101402230.20291@namei.org/
●
[2] Kernel lockdown locked out — for now
https://lwn.net/Articles/751061/
●
[3] Re: [PATCH] x86: Lock down MSR writing in secure boot
https://lore.kernel.org/lkml/20130208191213.GA25081@www.outflux.net/T/
●
[4][Bug 1198101] VUL-0: shim: openSUSE tumbleweed not fully locked down?
Add opensuse-cert-prompt back to openSUSE shim
●
[5] Card Information Structure (CIS)
http://blog.chinaunix.net/uid-20235103-id-1970862.html

46. Thank you!