Message-ID: <ZZ0qvM9uVOh5wQ59@shell.armlinux.org.uk>
Date: Tue, 9 Jan 2024 11:15:08 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Dimitri John Ledkov <dimitri.ledkov@...onical.com>,
	Masahiro Yamada <masahiroy@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org
Subject: Re: [BUG] SHA-3 causes kmod 28 to segfault

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@...linux.org.uk> 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@...linux.org.uk> 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!

Powered by blists - more mailing lists