linux-kernel - [PATCH] modules: CONFIG_MODULE_COMPRESS: add hint that userspace support may easily be missing.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150531152932.GA16337@rhlx01.hs-esslingen.de>
Date:	Sun, 31 May 2015 17:29:32 +0200
From:	Andreas Mohr <andi@...as.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Rusty Russell <rusty@...tcorp.com.au>,
	Bertrand Jacquin <beber@...eeweb.net>,
	Marco d'Itri <md@...ux.it>, linux-modules@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH] modules: CONFIG_MODULE_COMPRESS: add hint that userspace
 support may easily be missing.

Hi,

I just had a not so nice experience
when finally upgrading to a new 4.1-rc5
with CONFIG_MODULE_COMPRESS newly enabled -
userspace binary parts (kmod 18 or 20 in my case)
did not have compression enabled
(at least on Debian 8pre, vs. encountering it enabled on FC21)
since it does not seem to be
the default build configuration of kmod (yet?).

Doing a manual
    for gz in $(find . -name "*.gz"); do echo gunzip $gz; done
    depmod -a (somewhere temporarily in bootup scripts)
manages to fix the grave problem
introduced by erroneously having enabled CONFIG_MODULE_COMPRESS.

Thus it seems that the Kconfig text was much more optimistic
than a hapless user would want to encounter,
thus I decided to have it updated.


BTW: kmod and/or module-init-tools packages
might want to provide a generic way to openly advertise
certain build-configured "capabilities" in the binary -
neither
    kmod --help
nor
    kmod -V
indicated whether or not they provided capabilities
such as e.g. providing or not providing support of compression types
and which ones.
That would have been a very helpful way
to reliably determine
that support in fact is missing in the binary,
rather than having to resort to clumsy hacks
such as ldd or even strings.


While this is a minor but useful addition
rather than a severe fix,
having a CC to stable@ added subsequently might be useful.

Thanks!

Signed-off-by: Andreas Mohr <andim2@...rs.sf.net>

---
 init/Kconfig | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index dc24dec..8e451f30 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1951,11 +1951,19 @@ config MODULE_COMPRESS
 	  This option compresses the kernel modules when 'make
 	  modules_install' is run.
 
-	  The modules will be compressed either using gzip or xz depend on the
-	  choice made in "Compression algorithm".
-
-	  module-init-tools has support for gzip format while kmod handle gzip
-	  and xz compressed modules.
+	  The module files will be compressed either using gzip or xz
+	  depending on the choice made in "Compression algorithm".
+
+	  Obviously one will then need appropriate userspace parts
+	  which are actually able to deal with compressed files, too:
+	  module-init-tools has support for gzip format
+	  while kmod handles gzip and xz compressed modules.
+	  However, we observed that in several environments
+	  module loader binaries do not have that enabled (yet?)
+	  and thus bootup will fail fatally -
+	  manually doing ldd on these binaries
+	  to detect compression libraries
+	  is a tell-tale sign of having support enabled.
 
 	  When a kernel module is installed from outside of the main kernel
 	  source and uses the Kbuild system for installing modules then that
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/