Some are outdated, misleading or just repeat the same thing over and
over. Remove them as they are not needed.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://lore.kernel.org/r/20240723185921.1005569-3-lucas.de.marchi@gmail.com
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Drop the lengthy license from each file and just use SPDX like most
projects nowadays. This doesn't have any change to license, just how
they are recorded in each file.
This follows the kernel approach: header files use '/*' for comments
while .c files use '//'. For .m4, use "#".
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://lore.kernel.org/r/20240723185921.1005569-2-lucas.de.marchi@gmail.com
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Move zstd-related function to a separate file so it's easier to isolate
the dependency on each decompression library.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/58
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Move zlib-related function to a separate file so it's easier to isolate
the dependency on each decompression library.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/58
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Move xz-related function to a separate file so it's easier to isolate
the dependency on each decompression library.
Declare struct kmod_file in a shared libkmod-internal-file.h that will
be included only by sources implementing kmod_file decompression
routines.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/58
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Add the new weak API, to a separate section in the version script. These
will be exposed with the upcoming v33 release and not with v5 as the
symbol tag implies.
Cc: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Fixes: 05828b4 ("libkmod: add weak dependecies")
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20240719-abi-fixes-v1-3-1e6d99a2846b@gmail.com
The symbol was introduced with v30, yet was erroneously added in the v5
section. Move it to the correct place.
In theory this might cause an issue - severity depends on how the
runtime linker is setup. From a harmless warning (on stderr/stdout) to
failure to load the library.
In practise this shouldn't be a problem, since there are seemingly no
external users of the API.
Fixes: 9becaae ("libkmod: Add lookup from module name")
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20240719-abi-fixes-v1-2-1e6d99a2846b@gmail.com
The extra enum was introduced a few years ago, although the (only)
function using it did not have it's documentation updated.
The commit itself has caused an ABI break with kmod v27, since the
KMOD_INDEX_MODULES_BUILTIN value has changed.
A search through Google, Github and Arch packages have shown one user of
kmod_dump_index() - the only API that uses the enum.
In that case and all others, no projects referencing the changed enum
were found. Although since recent and/or supported distros use kmod v27
or later we've decided to only update the documentation.
Cc: Alexey Gladkov <gladkov.alexey@gmail.com>
Fixes: b866b21 ("Lookup aliases in the modules.builtin.modinfo")
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20240719-abi-fixes-v1-1-1e6d99a2846b@gmail.com
The use of .alias (alongside .conf) was added for compatibility with the
original module-init-tools project and has been living in kmod ever
since.
In practise, all the linux distributions that I can see are using .conf
files alone, as instructed by modprobe.d(5) and the only instance of an
.alias file is the modules.alias as shipped in the kernel.
The latter is already handled by other parts of the kmod project, so
let's enforce what our documentation says.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20240717-rm-alias-v1-1-58874caf343a@gmail.com
The allocator in glibc has a particular quirk that successive
reallocs on the same pointer are cheap, at the cost of excess
memory fragmentation. Other allocators generally do not do this,
so excessive reallocs become relatively expensive.
Reducing the number of reallocations by using a more agressive
strategy for buffer size increase makes performance better on
those setups, e.g. musl libc, or generally any other allocator;
on my Chimera Linux setup with Scudo allocator (LLVM) it doubles
to triples the performance of running e.g. depmod.
Signed-off-by: q66 <q66@chimera-linux.org>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
It has been seen that for some network mac drivers (i.e. lan78xx) the
related module for the phy is loaded dynamically depending on the current
hardware. In this case, the associated phy is read using mdio bus and then
the associated phy module is loaded during runtime (kernel function
phy_request_driver_module). However, no software dependency is defined, so
the user tools will no be able to get this dependency. For example, if
dracut is used and the hardware is present, lan78xx will be included but no
phy module will be added, and in the next restart the device will not work
from boot because no related phy will be found during initramfs stage.
In order to solve this, we could define a normal 'pre' software dependency
in lan78xx module with all the possible phy modules (there may be some),
but proceeding in that way, all the possible phy modules would be loaded
while only one is necessary.
The idea is to create a new type of dependency, that we are going to call
'weak' to be used only by the user tools that need to detect this situation.
In that way, for example, dracut could check the 'weak' dependency of the
modules involved in order to install these dependencies in initramfs too.
That is, for the commented lan78xx module, defining the 'weak' dependency
with the possible phy modules list, only the necessary phy would be loaded
on demand keeping the same behavior, but all the possible phy modules would
be available from initramfs.
A new function 'kmod_module_get_weakdeps' in libkmod will be added for
this to avoid breaking the API and maintain backward compatibility. This
general procedure could be useful for other similar cases (not only for
dynamic phy loading).
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Link: https://lore.kernel.org/r/20240327141116.97587-1-jtornosm@redhat.com
It's cleaner to handle all compression types and load functions in the
same style.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
We're about to reference it in comp_types with next commit.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
This commit cleans up the indentation and the error path of the
function. It bears no functional changes.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
[ Move assert to avoid warning with -Wdeclaration-after-statement ]
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Since all the compression magic is always available now, we don't need
to loop at runtime nor use alloca - latter of which comes with a handful
of caveats.
Simply throw in a few assert_cc(), which will trigger at build-time.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
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 <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
When dealing with an elf, we don't know or care about loading the file.
The kmod_elf subsystem/API will deal with the required parts itself.
Which in this case, already calls kmod_file_load_contents() as
applicable.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Propagate any errors during decompression further up the call stack.
Without this we could easily pass NULL as mem to init_module(2).
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
With the previous commits, we removed the need for a distinct unload
callback.
So nuke the struct all together and only use/keep the load one around.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
On mmap failure file->memory is set to -1, which we'll happily pass down
to munmap later on.
More importantly, since we do a NULL check in kmod_file_load_contents()
we will exit the function without (re)attempting the load again.
Since we ignore the return code for the load function(s), one can end up
calling kmod_elf_get_memory() and feed that -1 into init_module.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
These are used to protect a free(file->memory), within their respective
unload functions. Where the sole caller of the unload function already
does a NULL check prior.
Even so, free(NULL) is guaranteed to be safe by the standard.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
There is no need to keep the root gzFile context open for the whole
duration. Once we've copied the decompressed module to file->memory we
can close the handle.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
The gzdopen() API used, takes ownership of the fd. To make that more
explicit we clear it (-1) as applicable.
Yet again, kmod has explicit API to return the fd to the user - which
currently is used solely when uncompressed, so we're safe.
Regardless - simply duplicate the fd locally and use that with zlib.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Python bindings are not well maintained. Currently it's just broken when
trying to build with cython 3.0.8:
make --no-print-directory all-recursive
Making all in .
CYTHON libkmod/python/kmod/kmod.c
Error compiling Cython file:
------------------------------------------------------------
...
# details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with python-kmod. If not, see <http://www.gnu.org/licenses/>.
cimport _libkmod_h
^
Nothing really touched those bindings for 10 years already.
I postponed the removal since they were at least building, but that just
changed. So let's drop it and allow any interested people to give it
a better life outside of libkmod.
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Now that modprobe.d is searched under ${prefix}/lib, allow a complete
transition to files only under ${prefix} by adding a ${module_directory}
configuration. This specifies the directory where to search for kernel
modules and should match the location where the kernel/distro installs
them.
With this distributions that do not want to ship files in /lib can also
move kernel modules to /usr while others can keep them in /lib.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Link: https://lore.kernel.org/r/a3765f4e8ae3ce29c0847a0132d4a8d51ad040a9.1699618135.git.msuchanek@suse.de
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Switch to using OBJ_obj2txt() to calculate and print the pkcs7
signature hash name. This eliminates the need to duplicate libcrypto
NID to name mapping, detect SM3 openssl compile-time support, and
enables using any hashes that openssl and kernel know about. For
example SHA3 are being added for v6.7 and with this patch are
automatically supported.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Link: https://lore.kernel.org/r/20231029010319.157390-1-dimitri.ledkov@canonical.com
There is an ongoing effort to limit use of files outside of /usr (or
${prefix} on general). Currently all modprobe.d paths are hardcoded to
outside of $prefix. Teach kmod to load modprobe.d from ${prefix}/lib.
On some distributions /usr/lib and /lib are the same directory because
of a compatibility symlink, and it is possible to craft configuration
files with sideeffects that would behave differently when loaded twice.
However, the override semantic ensures that one 'overrides' the other,
and only one configuration file of the same name is loaded from any of
the search directories.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Link: https://lore.kernel.org/r/a290343ce32e2a3c25b134e4f27c13b26e06c9e0.1689681454.git.msuchanek@suse.de
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
When creating the context, read /sys/kernel/compression to check what's
the compression type supported by the kernel. This will later be used
when loading modules to check if the decompression step has to happen in
userspace or if it can be delegated to the kernel.
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Do not only set the type as direct, but also keep track of the
compression being used. This will allow using the in-kernel compression
in future.
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Extract 2 functions to handle finit_module vs init_modules differences,
with a fallback from the former to the latter.
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Add a separate function to load the file contents when it's needed.
When it's not needed on the path of loading modules via finit_module(),
there is no need to mmap the file. This will help support loading
modules with the in-kernel compression support.
This is done differently than the lazy initialization for
kmod_file_get_elf() because on the contents case there is also the
file->size to be updated. It would be a weird API to return the pointer
and have the size changed as a side-effect.
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
An attempt to pass too long module name to, say, rmmod, may
cause an out-of-bounds memory access (as repoted by UBSan):
$ rmmod $(for i in $(seq 0 4200); do echo -ne x; done)
libkmod/libkmod-module.c:1828:8: runtime error: index 4107 out of bounds for type 'char [4096]'
This is because 'snprintf(path, sizeof(path), ...)' may return the
value which exceeds 'sizeof(path)' (which happens when an output
gets truncated). To play it safe, such a suspicious output is
better to be rejected explicitly.
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Link: https://lore.kernel.org/r/20230519074638.402045-1-dmantipov@yandex.ru
When the module is definitely present but CONFIG_MODVERSIONS is
disabled, the following error message may be somewhat confusing:
modprobe --dump-modversions /path/to/module.ko.xz
modprobe: FATAL: could not get modversions of /path/to/module.ko.xz: No such file or directory
Choosing among the convenient errno values, I would suggest to use
ENODATA when the module lacks a particular ELF section (and vermagic
as well). So now it is expected to be:
modprobe: FATAL: could not get modversions of /path/to/module.ko.xz: No data available
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Link: https://lore.kernel.org/r/20230519093630.474185-1-dmantipov@yandex.ru
It's no longer used outside the compilation unit, as of last commit.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
The last and only user was removed with commit 0246e06 ("depmod: Stop
opening modules.modinfo once per module")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Currently if we see unknown algorithm, we'll do an OOB read in
pkey_hash_algo. This can happen for example if OPENSSL_NO_SM3 is set and
the kernel module uses a SM3 hash.
Cc: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Example kernel module:
https://file-store.rosalinux.ru/download/7281f97e0c04c0f818ad3f936706f4a407e8dc7e
(/lib/modules/5.15.67-generic-1rosa2021.1-x86_64/kernel/drivers/usb/host/xhci-pci.ko.zst)
It is signed with Streebog 512.
libkmod v30 crashed in libkmod-module.c:2413 in this code:
n = kmod_module_info_append(list,
"sig_hashalgo", strlen("sig_hashalgo"),
sig_info.hash_algo, strlen(sig_info.hash_algo));
because strlen() got null.
SM3 has been supported in kernel and cryptographic libraries like openssl.
This patch adds support for the SM3 algorithm of kmod.
Signed-off-by: HuaxinLu <luhuaxin1@huawei.com>
Slightly different than kmod_module_new_from_lookup(): it doesn't
consider aliases, only module names. This is useful for cases we want to
force a tool to handle something as the module name, without trying to
interpret it as an alias.
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
New indexes were created without updating the documentation about the
order in kmod_module_new_from_lookup(). Add them to the documentation.
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
The CHECK_ERR_AND_FINISH macro with conditional code flow changes has
been a source of bugs. Get rid of it replacing with a helper function
to iterate an array of lookup functions. This helper may also be useful
in future to create different lookup APIs in libkmod.
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
When kmod_module_new_from_lookup() resolves to an alias, `err` will be
set to a positive value from the lookup function. Do not return a
positive value to follow the behavior when it matches a module name
and the documentation.
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
The modules.builtin.alias.bin is way larger than the
modules.builtin.bin. On a normal "distro kernel":
21k modules.builtin.alias.bin
11k modules.builtin.bin
From the kernel we get both modules.builtin and modules.builtin.modinfo.
depmod generates modules.builtin.bin and modules.builtin.alias.bin
from them respectively. modules.bultin is not going away: it's not
deprecated by the new index added. So, let's just stop duplicating the
information inside modules.builtin.alias.bin and just use the other
index.
A recent bug report showed that modinfo doesn't give the signature
information for certain modules, and it turned out to happen only on
the modules that are built-in on the running kernel; then modinfo
skips the signature check, as if the target module file never exists.
The behavior is, however, inconsistent when modinfo is performed for
external modules (no matter which kernel version is) and the module
file path is explicitly given by a command-line argument, which
guarantees the presence of the module file itself.
Fixes: e7e2cb61fa ("modinfo: Show information about built-in modules")
Link: https://lore.kernel.org/linux-modules/CAKi4VAJVvY3=JdSZm-GD1hJqyCPYaYz-jBJ_REeY5BakVb6_ww@mail.gmail.com/
BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1189537
Suggested-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
When you use pass the -v argument to modprobe we bump
the log level from the default modprobe log level of
LOG_WARNING (4) to LOG_NOTICE (5), however the library
only has avaiable to print:
#define DBG(ctx, arg...) kmod_log_cond(ctx, LOG_DEBUG, ## arg)
#define INFO(ctx, arg...) kmod_log_cond(ctx, LOG_INFO, ## arg)
#define ERR(ctx, arg...) kmod_log_cond(ctx, LOG_ERR, ## arg)
LOG_INFO (6) however is too high of a level for it to be
effective at printing anything when modprobe -v is passed.
And so the only way in which modprobe -v can trigger the
library to print a verbose message is to use ERR() but that
always prints something and we don't want that in some
situations.
We need to add a new log level macro which uses LOG_NOTICE (5)
for a "normal but significant condition" which users and developers
can use to look underneath the hood to confirm if a situation is
happening.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
