On Tue, 9 Jan 2024 at 11:15, Russell King (Oracle) <linux@xxxxxxxxxxxxxxx> wrote: > > 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 > Did you test that things are successful wtih kmod 29, 30, 31? The code to correctly support sha3 in kmod was committed after 31 was tagged, and there is no newer tag yet hence the revision that has the correct code is v31-6-g510c8b7f74. If such check is desired, kmod 32 should be tagged and check should check for 32. > 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' > If possible please use min-tool-version.sh to set the lower bound of kmod that is supported by the build. Assuming module signing is generally desired to be supported, the minimum required kmod should be set to 26. Otherwise at least modinfo doesn't work. -- Dimitri Sent from Ubuntu Pro https://ubuntu.com/pro
