All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Dimitri John Ledkov <dimitri.ledkov@canonical.com>,
	Masahiro Yamada <masahiroy@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org
Subject: Re: [BUG] SHA-3 causes kmod 28 to segfault
Date: Tue, 9 Jan 2024 11:15:08 +0000	[thread overview]
Message-ID: <ZZ0qvM9uVOh5wQ59@shell.armlinux.org.uk> (raw)
In-Reply-To: <ZZxyrFkTmrGneP0H@shell.armlinux.org.uk>

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@armlinux.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@armlinux.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!

  reply	other threads:[~2024-01-09 11:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-08 16:38 [BUG] SHA-3 causes kmod 28 to segfault Russell King (Oracle)
2024-01-08 18:14 ` Dimitri John Ledkov
2024-01-08 18:30   ` Russell King (Oracle)
2024-01-08 18:46     ` Dimitri John Ledkov
2024-01-08 22:09       ` Russell King (Oracle)
2024-01-09 11:15         ` Russell King (Oracle) [this message]
2024-01-09 11:56           ` Dimitri John Ledkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZZ0qvM9uVOh5wQ59@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=dimitri.ledkov@canonical.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.