On Mon, Jan 08, 2024 at 10:09:49PM +0000, Russell King (Oracle) wrote: > On Mon, Jan 08, 2024 at 06:46:10PM +0000, Dimitri John Ledkov wrote: > > On Mon, 8 Jan 2024 at 18:30, Russell King (Oracle) > > <linux@xxxxxxxxxxxxxxx> wrote: > > > > > > On Mon, Jan 08, 2024 at 06:14:17PM +0000, Dimitri John Ledkov wrote: > > > > Hi, > > > > > > > > On Mon, 8 Jan 2024 at 16:38, Russell King (Oracle) > > > > <linux@xxxxxxxxxxxxxxx> wrote: > > > > > > > > > > Hi, > > > > > > > > > > When building 6.7 under Debian Oldstable with kmod 28, the installation > > > > > of modules fails during depmod with a SEGV. > > > > > > > > > > > > > What is your kernel configuration, and I hope you make config choices > > > > compatible with your target host OS. > > > > > > "target host OS" - that's a total misnomer. "host" is generally what > > > you're building under. "target" is generally what you're building _for_. > > > So I don't fully understand your comment. Maybe you meant "target _and_ > > > host" ? > > > > the kernel configuration you use, should target the operating system > > you are planning to use the given kernel on. > > Thank you for stating the damn obvious. I've been developing Linux > kernels for 30 years, I think I know this. > > > using bleeding edge kernel features, with an obsolete userspace often > > can have compatibility issues. > > You're still not being clear. I wonder whether you understand the > terms "target" and "host". > > > > > > Running under gdb: > > > > > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > > __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-vec.S:133 > > > > > > > > > > I have no further information as I can't remember how to get the debug > > > > > info for packages under Debian - and even if I could, it's probably a > > > > > bug in the kmod package that Debian will have absolutely no interest in > > > > > fixing (based on previous experience reporting bugs to Debian.) > > > > > > > > For latest kernel and latest kernel features support in kmod, latest > > > > kmod is required. I.e. patched with > > > > https://github.com/kmod-project/kmod/commit/510c8b7f7455c6613dd1706e5e41ec7b09cf6703 > > > > > > Would be nice if there was some documentation. Also, as kconfig provides > > > a mechanism to detect e.g. the version of tooling used to build the > > > kernel, it would've been nice to detect whether depmod was sufficiently > > > recent to support SHA3 and make the module signing SHA3 options depend > > > on that. > > > > > > Leaving this to a SEGV to indicate that something is wrong isn't user > > > friendly. > > > > > > > There is no ability to detect runtime kmod at build time, given the > > two are usually often not the same. > > Again, you CLEARLY don't understand the problem. I am *NOT* reporting > a problem on the target. I am reporting a problem on the *build* > *host*. > > > Can you please provide your config? > > Can you please explain how you chose it? > > No, because it's totally irrelevant to the problem I'm reporting. > > What I'm reporting to you is that _IF_ you build a kernel with the > SHA3 modsigning options on a HOST that has kmod 28, then depmod > SEGVs when _INSTALLING_ the modules to a directory on the _HOST_. > > This has *nothing* to do with the capabilities of the _TARGET_. > Whether the configuration matches the capabilities of the _TARGET_ > is *totally* irrelevant at _this_ stage. In fact, with the _HOST_ > depmod segfaulting, one can't complete the installation process > to even _think_ about transferring it to the _TARGET_. Here's a patch that checks the version of depmod on the _build_ _host_, preventing the use of the SHA3 module signing if it isn't recent enough, which causes make modules_install INSTALL_MOD_PATH=/foo/bar/bzz run on the _build_ _host_ to fail with a segfault. diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig index 0ea1b2970a23..d2ba454026a9 100644 --- a/kernel/module/Kconfig +++ b/kernel/module/Kconfig @@ -223,6 +223,11 @@ config MODULE_SIG_ALL Sign all modules during make modules_install. Without this option, modules must be signed manually, using the scripts/sign-file tool. +config DEPMOD_VERSION + int + default $(depmod-version) + default 0 + comment "Do not forget to sign required modules with scripts/sign-file" depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL @@ -250,14 +255,17 @@ config MODULE_SIG_SHA512 config MODULE_SIG_SHA3_256 bool "Sign modules with SHA3-256" + depends on DEPMOD_VERSION > 28 select CRYPTO_SHA3 config MODULE_SIG_SHA3_384 bool "Sign modules with SHA3-384" + depends on DEPMOD_VERSION > 28 select CRYPTO_SHA3 config MODULE_SIG_SHA3_512 bool "Sign modules with SHA3-512" + depends on DEPMOD_VERSION > 28 select CRYPTO_SHA3 endchoice diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include index 5a84b6443875..052f581c86da 100644 --- a/scripts/Kconfig.include +++ b/scripts/Kconfig.include @@ -63,3 +63,6 @@ ld-version := $(shell,set -- $(ld-info) && echo $2) cc-option-bit = $(if-success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null,$(1)) m32-flag := $(cc-option-bit,-m32) m64-flag := $(cc-option-bit,-m64) + +# depmod version +depmod-version := $(shell,$(srctree)/scripts/depmod-version.sh) diff --git a/scripts/depmod-version.sh b/scripts/depmod-version.sh new file mode 100755 index 000000000000..32a8a6f6b737 --- /dev/null +++ b/scripts/depmod-version.sh @@ -0,0 +1,11 @@ +#!/bin/sh +# SPDX-License-Identifier: GPL-2.0 + +set -e + +: ${DEPMOD:=depmod} + +# legacy behavior: "depmod" in /sbin, no /sbin in PATH +PATH="$PATH:/sbin" + +LC_ALL=C "$DEPMOD" --version | sed -n '1s/kmod version //p' -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
