When kernel is built with CONFIG_MODULE_DECOMPRESS=y, it can handle 1 algorithm for module decompression with finit_module(). When that algorithm matches the one used in the module we are trying to load, prefer using the in-kernel decompression. This way the kernel can also apply any additional security measures based on where the module is coming from. In future, if the kernel supports more algorithms at a time, libkmod could even be compiled without them and just let the kernel handle it. Since it's likely a distro kernel supports all of them, that would seem a good thing to do (on the other hand, tools like modinfo and depmod wouldn't be able read the module information). For zstd, this needs the following fix on the kernel side: https://lore.kernel.org/linux-modules/ZHkQNQK5zrzo4Cq2@xxxxxxxxxxxxxxxxxxxxxx/ Lucas De Marchi (5): libkmod: Do not inititialize file->memory on open libkmod: Extract finit_module vs init_module paths libkmod: Keep track of compression type libkmod: Keep track of in-kernel compression support libkmod: Use kernel decompression when available libkmod/libkmod-elf.c | 5 ++ libkmod/libkmod-file.c | 46 +++++++++----- libkmod/libkmod-internal.h | 13 +++- libkmod/libkmod-module.c | 127 ++++++++++++++++++++++++------------- libkmod/libkmod.c | 42 ++++++++++++ 5 files changed, 170 insertions(+), 63 deletions(-) -- 2.40.1
