This option is equivalent to basedir, with the small difference being
that's where the meta-data files are generated. In other words, this
allows us to have read-only input modules and modules.dep, while still
being able to generate the meta-data files.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
[ Move files to a different dir so input files (produced by kernel build
system is separate from the files generated by depmod (output) ]
Signed-off-by: Lucas De Marchi <lucas.demarchi@gmail.com>
This is useful to kernel module developers for testing a just compiled
module: instead of using insmod, they can load the module from the path
while getting all the benefits of modprobe (e.g. module dependency
resolution).
v2:
- Add test for relative path as well. (Lucas)
- Add note warning about modules with dependencies not matching the
installed depmod database. (Lucas)
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
It was reported that grub mangles the kernel cmdline. It turns
acpi_cpufreq.dyndbg="file drivers/cpufreq/acpi-cpufreq.c +mpf"
into
"acpi_cpufreq.dyndbg=file drivers/cpufreq/acpi-cpufreq.c +mpf"
However, even though we could blame grub for doing that, the kernel
happily accepts and re-quotes it when the module is built-in.
So, it's better if kmod also understands it this way and does the same.
Here we basically add additional code to un-mangle it, moving the quote
in way that is acceptable to pass through init_module(). Note that the
interface [f]init_module() gives us mandates the quote to be part of the
value: the module name is not passed and the options are separated by
space.
Reported-by: Jiri Slaby <jirislaby@kernel.org>
Tested-by: Jessica Yu <jeyu@kernel.org>
Link: https://bugzilla.suse.com/show_bug.cgi?id=1181111#c10
Commit ca3bf5d47cec ("iommu/amd: Introduces ivrs_acpihid kernel parameter")
in the kernel introduced an ill-formed kernel parameter, ivrs_acpihid.
The problem is that it may have a dot on the key side:
"ivrs_acpihid[00:14.5]=AMD0020:0". This could potentially trip our
parser of module options, but right now it's working as intended: the
only thing that happens is that after deciding "ivrs_acpihid[00:14" is a
module name, it will fail the underscores() routine and the option will
be ignored from the kmod pov (not kernel's pov since that driver parsers
the kernel command line by itself).
Use the same approach to generate the signed module, like in the
old signature test: just append the pregenerated binary signature
to the module (the signature check will fail).
In case of need of generating correct signature, from the linux
kernel makefiles (certs/Makefile) it could be like:
$ openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509
-config ./x509.genkey -outform PEM -out signing_key.pem -keyout signing_key.pem
$ /lib/modules/$(uname -r)/build/scripts/extract-cert signing_key.pem signing_key.x509
$ /lib/modules/$(uname -r)/build/scripts/sign-file sha256 signing_key.pem signing_key.x509 module.ko
where x509.genkey is:
```
[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
prompt = no
string_mask = utf8only
x509_extensions = myexts
[ req_distinguished_name ]
CN = Build time autogenerated kernel key
[ myexts ]
basicConstraints=critical,CA:FALSE
keyUsage=digitalSignature
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid
```
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
Simple test to check if depmod honors override keyword. Uses
mod-simple.ko for foo/ and override/ directories, search.conf to
search in foo and built-in and simple override configuration:
override mod-simple 4.4.4 override
The resulting modules.dep should point to the override directory.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
The following tests added:
- depmod_search_order_external_first -- checks if external module
is taken in use when it has higher priority;
- depmod_search_order_external_last -- checks if external module
is skipped when it has lower priority;
- test_modinfo_external -- checks if modinfo is able to look up
correct external module;
- modprobe_external -- checks if modprobe is able to look up
correct external module and loads it.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
The patch adds nested loops configuration for the loop test:
mod-loop-h -> mod-loop-i -> mod-loop-j -> mod-loop-k
^ | |
--------------------------- |
| |
-------------------------------------------
making 2 loops with common edges:
mod-loop-h -> mod-loop-i -> mod-loop-j -> mod-loop-h
mod-loop-h -> mod-loop-i -> mod-loop-j -> mod-loop-k -> mod-loop-h
The actual output for the loops is:
depmod: ERROR: Cycle detected: mod_loop_h -> mod_loop_h
depmod: ERROR: Cycle detected: mod_loop_i -> mod_loop_j -> mod_loop_k -> mod_loop_h -> mod_loop_i
(the order in the second doesn't matter, but the first one is
incorrect)
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
Add some tests in which we quotes in kernel cmdline and also spaces
inside quotes. This doesn't yet cover the case in which quotes are used
for module name, wihch should be forbidden.
Only print actual cyclic dependencies. Print count of all the modules
in cyclic dependency at the end of the function so that dependent
modules which are not in cyclic chain can be ignored.
Printing dependent modules which are not in cyclic chain causes buffer
overflow as m->modnamesz is not included in buffer size calculations
(loop == m is never true). This buffer overflow causes kmod to crash.
Update depmod test to reflect the change as well.
Reported-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@suse.com>
The second test, that creates the module by name and then retrieves the
initstate was broken before b95fa91 ('Fix race while loading modules').
We would check /sys and return either builtin (if the module has
parameters) or give an error because we don't find the module (even if
it's in the modules.builtin index)
We use a "fake signature" to sign the modules. As far as kmod is
concerned the signature fields are informational only. It's the kernel
the responsible for checking it's valid.
So what we are doing here is: pick the signatures of the ext4-x86_64.ko
module and save as dummy.{hashalgo}. This signature is appended to the
mod-simple.ko module so the ext4-x86_64.ko module can be removed from
tree.
Rename modinfo_jonsmodules() to test_modinfo_signature(): now this test
is responsible only for the signed modules.
The other tests use specific flags to modinfo in order to print only
one field, so we can filter out those fields that are expect to change
if the module is recompiled.
Instead of shipping pre-compiled module, this prepares the build system
to be able to compile the necessary modules from module-playground. This
preparations starts by replacing md5.ko with our own dummy
mod-simple.ko, built from source. It works by copying the modules to
their final location while preparing the rootfs.
This partially reverts ad7f175 ("Add test for depmod using search dirs
with same prefix"). Testing it twice in the inverted order doesn't
ensure we get the bug with wrong ordering.
As put by Anssi Hannula <anssi@mageia.org>:
So the bug is triggered only if the shorter name is higher-prio _and_
shorter name is traversed first. If the long name is traversed first,
the bug don't trigger with either "search" directive order (and on my
"make check" runs this is the case).
Test depmod with search dirs "foo" and "foobar". Previously to 49b33c1
("depmod: do not allow partial matches with "search" directive") we were
failing this test due to matching the prefix without checking if
it's the full dir name.
We are adding 2 tests here in order to catch the case we only pass the
test due to processing the directories in a favourable order.
In kcmdline it's possible to have a dot in the param's value. The
support for this was added in 66f3228 ("libkmod: Add support for '.' in
module parameter on kcmdline") and is needed to correctly support some
modules that depend on it.
This test was added in order to make sure the commit aa87854
("libkmod-config: Only match dot before '=' in /proc/cmdline") didn't
break it. Although that commit message says it's allowing to match a
dot before '=' it's actually enforcing the first part of the string to
be always in the format "<module-name>.param". Dots after '=' are still
correctly allowed.
Strings unrelated to modules and modprobe should be ignored and not
appear in the output of "modprobe -c".
This adds a test for the fix provided in aa87854 ("libkmod-config: Only
match dot before '=' in /proc/cmdline").
Use "modprobe -c" to dump the configuration. Since we configure our
rootfs to have only a /proc/cmdline file, this should dump the knowledge
we have from its parsed content.
Test if <module>.option, without any value is correctly parsed, as fixed
in commit 493dc65 ("libkmod: Fix getting param with no value from kcmdline")
Emil Velikov
Gustavo Sousa
Lucas De Marchi
Yauheni Kaliuta
Mian Yousaf Kaukab
Caio Marcelo de Oliveira Filho
Michal Marek