[BUG] SHA-3 causes kmod 28 to segfault

[BUG] SHA-3 causes kmod 28 to segfault

[Russell King (Oracle)]

Hi,

When building 6.7 under Debian Oldstable with kmod 28, the installation
of modules fails during depmod with a SEGV.

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.)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [BUG] SHA-3 causes kmod 28 to segfault

[Dimitri John Ledkov]

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.

> 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

Or ensure that you use a compatible kernel configuration by for
example using SHA256 for kernel module signing.

SHA3 is added as a future alternative to the currently recommended
SHA2 based hashes, as it seems not great to only have a single family
of hashes supported out of the box that are still deemed to be secure.

-- 
Dimitri

Sent from Ubuntu Pro
https://ubuntu.com/pro

Re: [BUG] SHA-3 causes kmod 28 to segfault

[Russell King (Oracle)]

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" ?

> > 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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [BUG] SHA-3 causes kmod 28 to segfault

[Dimitri John Ledkov]

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.
using bleeding edge kernel features, with an obsolete userspace often
can have compatibility issues.

>
> > > 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.

Can you please provide your config?
Can you please explain how you chose it?
As both oldconfig, and menuconfig should have offered you
MODULE_SIG_SHA256 as the default choice, if you chose to enable
automatic module signing with an ephemeral key.
Please note that SHA256 is recommended and sufficient through 2030 and
beyond, as of now.

If you want to use SHA3, SM3, or GOST you need to have appropriate
builds of openssl and kmod to support those.

-- 
Dimitri

Sent from Ubuntu Pro
https://ubuntu.com/pro

Re: [BUG] SHA-3 causes kmod 28 to segfault

[Russell King (Oracle)]

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_.

So please, I'm not stupid - but right now I think you are, because
you clearly don't understand the difference between TARGET and HOST.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [BUG] SHA-3 causes kmod 28 to segfault

[Russell King (Oracle)]

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!

Re: [BUG] SHA-3 causes kmod 28 to segfault

[Dimitri John Ledkov]

On Tue, 9 Jan 2024 at 11:15, Russell King (Oracle)
<linux@armlinux.org.uk> 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@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
>

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