| Message ID | E1rNVlL-000qDm-Pg@rmk-PC.armlinux.org.uk (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | kbuild: detect depmod version to exclude new SHA3 module signing options | expand |
Ping? On Wed, Jan 10, 2024 at 10:24:43AM +0000, Russell King (Oracle) wrote: > When using the SHA3 module signing options, kmod 28 segfaults during > "make modules_install" on the build host. > > When running depmod under gdb, it reports: > > Program received signal SIGSEGV, Segmentation fault. > __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-vec.S:133 > > Therefore, SHA3 can't be used on a build system with an old kmod. Add > a script to retrieve the version of depmod, and use that in the Kconfig > to determine whether the SHA3 options should be made available. > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > --- > I don't know what the minimum requirement is for SHA3 to work, so I have > chosen a minimum of version 29 for the purposes of this patch. > --- > kernel/module/Kconfig | 8 ++++++++ > scripts/Kconfig.include | 3 +++ > scripts/depmod-version.sh | 11 +++++++++++ > 3 files changed, 22 insertions(+) > create mode 100755 scripts/depmod-version.sh > > 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' > -- > 2.30.2 > >
On Mon, 15 Jan 2024 at 12:45, Russell King (Oracle) <linux@armlinux.org.uk> wrote: > > Ping? > The intent is good. The implementation is incomplete. Please respond or address review feedback emailed previously. See https://lore.kernel.org/all/CADWks+Z5iZ=P_OAanA-PiePFbMpwtRe3_dF8wRTak8YAi87zvQ@mail.gmail.com/#t > On Wed, Jan 10, 2024 at 10:24:43AM +0000, Russell King (Oracle) wrote: > > When using the SHA3 module signing options, kmod 28 segfaults during > > "make modules_install" on the build host. > > > > When running depmod under gdb, it reports: > > > > Program received signal SIGSEGV, Segmentation fault. > > __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-vec.S:133 > > > > Therefore, SHA3 can't be used on a build system with an old kmod. Add > > a script to retrieve the version of depmod, and use that in the Kconfig > > to determine whether the SHA3 options should be made available. > > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > --- > > I don't know what the minimum requirement is for SHA3 to work, so I have > > chosen a minimum of version 29 for the purposes of this patch. > > --- > > kernel/module/Kconfig | 8 ++++++++ > > scripts/Kconfig.include | 3 +++ > > scripts/depmod-version.sh | 11 +++++++++++ > > 3 files changed, 22 insertions(+) > > create mode 100755 scripts/depmod-version.sh > > > > 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' > > -- > > 2.30.2 > > > > > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On Mon, Jan 15, 2024 at 01:09:25PM +0000, Dimitri John Ledkov wrote: > On Mon, 15 Jan 2024 at 12:45, Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > > > Ping? > > > > The intent is good. > The implementation is incomplete. > > Please respond or address review feedback emailed previously. See > https://lore.kernel.org/all/CADWks+Z5iZ=P_OAanA-PiePFbMpwtRe3_dF8wRTak8YAi87zvQ@mail.gmail.com/#t There was feedback to it? News to me... I'll take a look.
On Mon, Jan 15, 2024 at 01:09:25PM +0000, Dimitri John Ledkov wrote: > On Mon, 15 Jan 2024 at 12:45, Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > > > Ping? > > > > The intent is good. > The implementation is incomplete. > > Please respond or address review feedback emailed previously. See > https://lore.kernel.org/all/CADWks+Z5iZ=P_OAanA-PiePFbMpwtRe3_dF8wRTak8YAi87zvQ@mail.gmail.com/#t > Did you test that things are successful wtih kmod 29, 30, 31? No I didn't. See my comment below the "---" line: "I don't know what the minimum requirement is for SHA3 to work, so I have chosen a minimum of version 29 for the purposes of this patch." > 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. Thanks for the information. > If such check is desired, kmod 32 should be tagged and check should > check for 32. "If such a check is desired" ? You mean you prefer systems to segfault during the installation step when the build system doesn't have a new enough kmod? > 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. That's a separate issue though, and has build-breaking ramifications. Enforcing a minimum kmod 26 will mean that the kernel will fail if kmod isn't new enough, whereas someone may be building with module signing disabled and thus be fine with older kmod. These are two separate issues, and I think _this_ _fix_ needs to be first because the issue is already there and affecting people (me), and then maybe add the minimum version thing _afterwards_ in case it needs to be reverted. Doing it the other way around would make reverting the min-version thing much harder.
On Mon, 15 Jan 2024 at 14:25, Russell King (Oracle) <linux@armlinux.org.uk> wrote: > > On Mon, Jan 15, 2024 at 01:09:25PM +0000, Dimitri John Ledkov wrote: > > On Mon, 15 Jan 2024 at 12:45, Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > > > > Ping? > > > > > > > The intent is good. > > The implementation is incomplete. > > > > Please respond or address review feedback emailed previously. See > > https://lore.kernel.org/all/CADWks+Z5iZ=P_OAanA-PiePFbMpwtRe3_dF8wRTak8YAi87zvQ@mail.gmail.com/#t > > > Did you test that things are successful wtih kmod 29, 30, 31? > > No I didn't. See my comment below the "---" line: > > "I don't know what the minimum requirement is for SHA3 to work, so I > have chosen a minimum of version 29 for the purposes of this patch." > > > 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. > > Thanks for the information. > > > If such check is desired, kmod 32 should be tagged and check should > > check for 32. > > "If such a check is desired" ? You mean you prefer systems to segfault > during the installation step when the build system doesn't have a new > enough kmod? > > > 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. > > That's a separate issue though, and has build-breaking ramifications. > Enforcing a minimum kmod 26 will mean that the kernel will fail if > kmod isn't new enough, whereas someone may be building with module > signing disabled and thus be fine with older kmod. > > These are two separate issues, and I think _this_ _fix_ needs to be > first because the issue is already there and affecting people (me), I don't believe the fix you desire is as critical as you think it is. Majority of people do not compile and install bleeding edge kernels, on an EOL release with a 5 year old kmod, when both are released by the same upstream project (more or less). Also your fix will prevent people to use EOL release for kernel compilation (or introduce requirement to have kmod installed on the build host), when they do not execute install on the same system (but transfer the files into a packaging format / execute depmod using up to date kmod not in path). Thus you may actually break even more people with this change, as kmod versions have never been enforced before. I am still waiting for a response from you: 1) why you attempted this given non-default configuration build - given your obsolete kmod in the installation target system (intentionally attempting to choose config options to suitable for your target) 2) why you want people to prevent compiling such a build, which they can install later on with a compatible kmod (when their build-time and install-time systems are different) Which you have ignored responding to, in the previous emails. I am trying to politely help you, and yet the tone of your emails are very aggressive and very dismissive to me. So far, this patch is a NACK from me. > and then maybe add the minimum version thing _afterwards_ in case it > needs to be reverted. > > Doing it the other way around would make reverting the min-version > thing much harder. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! -- Dimitri Sent from Ubuntu Pro https://ubuntu.com/pro
On Mon, Jan 15, 2024 at 02:39:05PM +0000, Dimitri John Ledkov wrote: > On Mon, 15 Jan 2024 at 14:25, Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > > > On Mon, Jan 15, 2024 at 01:09:25PM +0000, Dimitri John Ledkov wrote: > > > On Mon, 15 Jan 2024 at 12:45, Russell King (Oracle) > > > <linux@armlinux.org.uk> wrote: > > > > > > > > Ping? > > > > > > > > > > The intent is good. > > > The implementation is incomplete. > > > > > > Please respond or address review feedback emailed previously. See > > > https://lore.kernel.org/all/CADWks+Z5iZ=P_OAanA-PiePFbMpwtRe3_dF8wRTak8YAi87zvQ@mail.gmail.com/#t > > > > > Did you test that things are successful wtih kmod 29, 30, 31? > > > > No I didn't. See my comment below the "---" line: > > > > "I don't know what the minimum requirement is for SHA3 to work, so I > > have chosen a minimum of version 29 for the purposes of this patch." > > > > > 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. > > > > Thanks for the information. > > > > > If such check is desired, kmod 32 should be tagged and check should > > > check for 32. > > > > "If such a check is desired" ? You mean you prefer systems to segfault > > during the installation step when the build system doesn't have a new > > enough kmod? > > > > > 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. > > > > That's a separate issue though, and has build-breaking ramifications. > > Enforcing a minimum kmod 26 will mean that the kernel will fail if > > kmod isn't new enough, whereas someone may be building with module > > signing disabled and thus be fine with older kmod. > > > > These are two separate issues, and I think _this_ _fix_ needs to be > > first because the issue is already there and affecting people (me), > > I don't believe the fix you desire is as critical as you think it is. > > Majority of people do not compile and install bleeding edge kernels, > on an EOL release with a 5 year old kmod, when both are released by > the same upstream project (more or less). > Also your fix will prevent people to use EOL release for kernel > compilation (or introduce requirement to have kmod installed on the > build host), when they do not execute install on the same system (but > transfer the files into a packaging format / execute depmod using up > to date kmod not in path). Thus you may actually break even more > people with this change, as kmod versions have never been enforced > before. > > I am still waiting for a response from you: > 1) why you attempted this given non-default configuration build - > given your obsolete kmod in the installation target system > (intentionally attempting to choose config options to suitable for > your target) > 2) why you want people to prevent compiling such a build, which they > can install later on with a compatible kmod (when their build-time and > install-time systems are different) > > Which you have ignored responding to, in the previous emails. > > I am trying to politely help you, and yet the tone of your emails are > very aggressive and very dismissive to me. Your responses have been confusing, and suggest that you don't know what you're talking about. For example: 1) your initial response started talking about the target host OS when I clearly stated that the problem was while _building_ which means the (build) host. I interpret "target host" to be confusing, since "target" is the platform that will _run_ the kernel and "host" is the build host. 2) your second response contained: "the kernel configuration you use, should target the operating system you are planning to use the given kernel on." factually and demonstrably incorrect (if it were true, I wouldn't be seeing the segfault.) This statement is also demeaning, since you are implying that I have no idea how to configure the kernel - given that I've been a kernel contributer and maintainer since the early days I have much more experience than you do. So your responses make no sense to me, sorry. This is the first feature where some other kernel developer seems to be saying "yes, it's fine if we get a segfault while doing normal operations with the kernel build system." To me, that is totally not acceptable.
On Mon, Jan 15, 2024 at 02:25:45PM +0000, Russell King (Oracle) wrote: >On Mon, Jan 15, 2024 at 01:09:25PM +0000, Dimitri John Ledkov wrote: >> On Mon, 15 Jan 2024 at 12:45, Russell King (Oracle) >> <linux@armlinux.org.uk> wrote: >> > >> > Ping? >> > >> >> The intent is good. >> The implementation is incomplete. >> >> Please respond or address review feedback emailed previously. See >> https://lore.kernel.org/all/CADWks+Z5iZ=P_OAanA-PiePFbMpwtRe3_dF8wRTak8YAi87zvQ@mail.gmail.com/#t > >> Did you test that things are successful wtih kmod 29, 30, 31? > >No I didn't. See my comment below the "---" line: > >"I don't know what the minimum requirement is for SHA3 to work, so I >have chosen a minimum of version 29 for the purposes of this patch." > >> 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. > >Thanks for the information. > >> If such check is desired, kmod 32 should be tagged and check should >> check for 32. > >"If such a check is desired" ? You mean you prefer systems to segfault >during the installation step when the build system doesn't have a new >enough kmod? I don't think we should check the version number at all to workaround bugs like that. It'd better we let distros to port the fix. If we need a 29.1, 30.1, 31.1 kmod releases to make this common for distros, I can help make that happen. Lucas De Marchi
On Wed, Jan 17, 2024 at 7:36 AM Lucas De Marchi <lucas.demarchi@intel.com> wrote: > > On Mon, Jan 15, 2024 at 02:25:45PM +0000, Russell King (Oracle) wrote: > >On Mon, Jan 15, 2024 at 01:09:25PM +0000, Dimitri John Ledkov wrote: > >> On Mon, 15 Jan 2024 at 12:45, Russell King (Oracle) > >> <linux@armlinux.org.uk> wrote: > >> > > >> > Ping? > >> > > >> > >> The intent is good. > >> The implementation is incomplete. > >> > >> Please respond or address review feedback emailed previously. See > >> https://lore.kernel.org/all/CADWks+Z5iZ=P_OAanA-PiePFbMpwtRe3_dF8wRTak8YAi87zvQ@mail.gmail.com/#t > > > >> Did you test that things are successful wtih kmod 29, 30, 31? > > > >No I didn't. See my comment below the "---" line: > > > >"I don't know what the minimum requirement is for SHA3 to work, so I > >have chosen a minimum of version 29 for the purposes of this patch." > > > >> 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. > > > >Thanks for the information. > > > >> If such check is desired, kmod 32 should be tagged and check should > >> check for 32. > > > >"If such a check is desired" ? You mean you prefer systems to segfault > >during the installation step when the build system doesn't have a new > >enough kmod? > > I don't think we should check the version number at all to workaround > bugs like that. It'd better we let distros to port the fix. If we need > a 29.1, 30.1, 31.1 kmod releases to make this common for distros, > I can help make that happen. > > Lucas De Marchi I think Russell's comments are sensible. But, if Lucas back-ports a fix-up to older kmod versions, that sounds great too, as I do not need to pick up this patch.
[ Going through my "this is still pending" list ] On Wed, 10 Jan 2024 at 02:24, Russell King (Oracle) <rmk+kernel@armlinux.org.uk> wrote: > > I don't know what the minimum requirement is for SHA3 to work, so I have > chosen a minimum of version 29 for the purposes of this patch. I see that there is some noise about hopefully just getting depmod fixed. But if we take this approach and just say "don't allow SHA3 signing with a broken depmod", I'd personally be happier with something that isn't version-dependent, but is bug-dependent. IOW, instead of doing "depmod --version" and parsing that, particularly since apparently the exact version isn't clear, would it be possible to just actually test for the bug itself? Or, honestly, maybe just extend the depmod wrapper script to write our a more descriptive error report. We already have that whole echo "Warning: 'make modules_install' requires $DEPMOD. Please install it." >&2 thing, so we already have run-time error handling (although I note that it does "exit 0" instead of something saner) rather than some Kconfig-time case. Linus
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'
When using the SHA3 module signing options, kmod 28 segfaults during "make modules_install" on the build host. When running depmod under gdb, it reports: Program received signal SIGSEGV, Segmentation fault. __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-vec.S:133 Therefore, SHA3 can't be used on a build system with an old kmod. Add a script to retrieve the version of depmod, and use that in the Kconfig to determine whether the SHA3 options should be made available. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> --- I don't know what the minimum requirement is for SHA3 to work, so I have chosen a minimum of version 29 for the purposes of this patch. --- kernel/module/Kconfig | 8 ++++++++ scripts/Kconfig.include | 3 +++ scripts/depmod-version.sh | 11 +++++++++++ 3 files changed, 22 insertions(+) create mode 100755 scripts/depmod-version.sh