[kmod,08/13] libkmod: always detect the module compression

Commit Message

Emil Velikov via B4 Relay Feb. 12, 2024, 5:23 p.m. UTC

From: Emil Velikov <[e-mail]>

Currently, when built w/o given compression we'll incorrectly report a
"compression_none".

As we reach do_finit_module(), we'll naively assume that the kernel can
handle the compressed module, yet omit the MODULE_INIT_COMPRESSED_FILE
flag.

As result the kernel will barf at us, do_finit_module will fail with non
-ENOSYS and we won't end in the do_init_module codepath (which will also
fail).

In other words: with this change, you can build kmod without zstd, xz
and zlib support and the kernel will load the modules, assuming it
supports the format \o/

Signed-off-by: Emil Velikov <[e-mail]>
---
 libkmod/libkmod-file.c | 27 ++++++++++++++++++---------
 1 file changed, 18 insertions(+), 9 deletions(-)

Comments

Emil Velikov Feb. 13, 2024, 4:33 p.m. UTC | #1

On Mon, 12 Feb 2024 at 17:23, Emil Velikov via B4 Relay
<[e-mail]> wrote:
>
> From: Emil Velikov <[e-mail]>
>
> Currently, when built w/o given compression we'll incorrectly report a
> "compression_none".
>
> As we reach do_finit_module(), we'll naively assume that the kernel can
> handle the compressed module, yet omit the MODULE_INIT_COMPRESSED_FILE
> flag.
>
> As result the kernel will barf at us, do_finit_module will fail with non
> -ENOSYS and we won't end in the do_init_module codepath (which will also
> fail).
>
> In other words: with this change, you can build kmod without zstd, xz
> and zlib support and the kernel will load the modules, assuming it
> supports the format \o/
>

Important part to note here is that the above is only valid for insmod
and modprobe.

Tools such as depmod and modinfo, still depend on kmod being built
with e.g. zstd, in order for `.ko.zstd` modules to be considered valid
entries.
I'm not 100% sure about modinfo, at a glance those tools require
decompression support in order to parse the elfs and extract the
required module information.

Regardless of this caveat I do see value in this series:
 - it notably simplifies the codebase
 - You can use different kmod on the build vs target system.

Namely: Yocto recipe with full blown kmod/depmod generates the mutable
modules.xxx files, yet the target system uses compression-less kmod
for insmod/modprobe/rmmod/lsmod.

HTH
Emil

Patch

diff --git a/libkmod/libkmod-file.c b/libkmod/libkmod-file.c
index 3a79464..b69f1ef 100644
--- a/libkmod/libkmod-file.c
+++ b/libkmod/libkmod-file.c
@@ -174,9 +174,14 @@  out:
 	free((void *)zst_outb.dst);
 	return ret;
 }
+#else
+static int load_zstd(struct kmod_file *file)
+{
+	return -ENOSYS;
+}
+#endif
 
 static const char magic_zstd[] = {0x28, 0xB5, 0x2F, 0xFD};
-#endif
 
 #ifdef ENABLE_XZ
 static void xz_uncompress_belch(struct kmod_file *file, lzma_ret ret)
@@ -275,9 +280,14 @@  static int load_xz(struct kmod_file *file)
 	lzma_end(&strm);
 	return ret;
 }
+#else
+static int load_xz(struct kmod_file *file)
+{
+	return -ENOSYS;
+}
+#endif
 
 static const char magic_xz[] = {0xfd, '7', 'z', 'X', 'Z', 0};
-#endif
 
 #ifdef ENABLE_ZLIB
 #define READ_STEP (4 * 1024 * 1024)
@@ -339,9 +349,14 @@  error:
 	gzclose(gzf); /* closes the gzfd */
 	return err;
 }
+#else
+static int load_zlib(struct kmod_file *file)
+{
+	return -ENOSYS;
+}
+#endif
 
 static const char magic_zlib[] = {0x1f, 0x8b};
-#endif
 
 static const struct comp_type {
 	size_t magic_size;
@@ -349,15 +364,9 @@  static const struct comp_type {
 	const char *magic_bytes;
 	int (*load)(struct kmod_file *file);
 } comp_types[] = {
-#ifdef ENABLE_ZSTD
 	{sizeof(magic_zstd),	KMOD_FILE_COMPRESSION_ZSTD, magic_zstd, load_zstd},
-#endif
-#ifdef ENABLE_XZ
 	{sizeof(magic_xz),	KMOD_FILE_COMPRESSION_XZ, magic_xz, load_xz},
-#endif
-#ifdef ENABLE_ZLIB
 	{sizeof(magic_zlib),	KMOD_FILE_COMPRESSION_ZLIB, magic_zlib, load_zlib},
-#endif
 	{0,			KMOD_FILE_COMPRESSION_NONE, NULL, NULL}
 };