Bug reported by Ben Hutchings <ben@decadent.org.uk>:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970871
Now that the kernel provides module information for potentially
modular code that's actually built-in, it's possible to query these
built-ins with "modinfo -F". However, this doesn't work quite right:
$ modinfo -Flicense e1000e
GPL v2
$ modinfo -Flicense bitrev
name: bitrev
GPL
The Makefile helpfully warns that some tests will fail when
--sysconfdir != /etc, but there are no provisions to easily disable
those. This commit provides an escape hatch.
[ Lucas: add comment detailing the purpose of the field ]
We need a macro indirection for UNIQ to work. Otherwise it won't be
unique at all since it will just append "UNIQ" to the name:
In file included from testsuite/test-init.c:30:
testsuite/testsuite.h:142:27: error: redefinition of ‘stest_load_resourcesUNIQ’
The file is always created and unless we return an error, the temporary
file is renamed to its final destination. All other places write the
index without checking if the index is empty, so just do the same.
Reported-by: Joe Buehler <aspam@cox.net>
kmod_log_null() does not change ctx (does nothing).
Fix warnings
In file included from libkmod/libkmod-index.c:33:
libkmod/libkmod-index.c: In function ‘index_mm_open’:
libkmod/libkmod-index.c:757:6: warning: passing argument 1 of ‘kmod_log_null’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
757 | DBG(ctx, "file=%s\n", filename);
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
idx is allocated in the beginning but it's not freed if there is
a failure after the allocation.
Change the error path: return immediately if idx allocation fails
and then free it in both success and error path at the end.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
The function allocates array but on building it if get_string()
fails it returns the error leaving the array allocated. The caller
does not care about it in error case either.
Free it to fix memory leak.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
I changed the style of the hackargs variable in autogen.sh to multiline
because said line was becoming a bit long with the new --with-zstd arg
added.
A previous version of this patch has been running on my two Arch Linux
installations (with an accompanying mkinitcpio patch) for several months
over many kernel updates without any issues.
Any additional testing and/or patch review would of course be appreciated.
Signed-off-by: Torge Matthies <openglfreak@googlemail.com>
When calling kmod_load_resources() we could end up getting a bogus
return value -ENOMEM due to several other reasons, like the index not
existing. Change index_mm_open() to propagate the failure reason so we
can take actions on it or return to the caller.
When we try to lookup a module and builtin.modinfo.bin is missing, we
would do the right thing because the caller was replacing the return
code with 0 (and the list was not modified).
Make it simpler by allowing the caller to check and differentiate the
errors between module not found and index not found.
index_write() relies on fseek/ftell to manage the position to which we
are write and thus needs the file stream to support it.
Right now when trying to write the index to stdout we fail with:
depmod: tools/depmod.c:416: index_write: Assertion `initial_offset >= 0' failed.
Aborted (core dumped)
We have no interest in outputting our index to stdout, so just skip it
like is done with other indexes.
While at it, add/remove some newlines to improve readability.
Reported-by: Yanko Kaneti <yaneti@declera.com>
Fix: b866b2165a ("Lookup aliases in the modules.builtin.modinfo")
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).
New modules.builtin.modinfo duplicates modules.builtin in the built-in
module name search. If it exists, then we can use this file, but if not,
then we need to fallback to the old file.
Signed-off-by: Alexey Gladkov <gladkov.alexey@gmail.com>
The kernel since version v5.2-rc1 exports information about built-in
modules in the modules.builtin.modinfo. Information is stored in
the same format as in the separate modules (null-terminated string
array). The module name is a prefix for each line.
$ tr '\0' '\n' < modules.builtin.modinfo
ext4.softdep=pre: crc32c
ext4.license=GPL
ext4.description=Fourth Extended Filesystem
ext4.author=Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others
ext4.alias=fs-ext4
ext4.alias=ext3
ext4.alias=fs-ext3
ext4.alias=ext2
ext4.alias=fs-ext2
md_mod.alias=block-major-9-*
md_mod.alias=md
md_mod.description=MD RAID framework
md_mod.license=GPL
md_mod.parmtype=create_on_open:bool
md_mod.parmtype=start_dirty_degraded:int
...
Signed-off-by: Alexey Gladkov <gladkov.alexey@gmail.com>
Commit 1d14ef82f4 does not completely fix
the build with python 3.8 as we still get link failure due to
'-z undefs' being ignored by some versions of ld.
Indeed, -z undefs was added by commit
97a232d7335f3bd0231fd9cd39455bde1d563922 in upstream binutils, and this
commit was first present in binutils 2.30.
So any toolchain using binutils version older than that won't have
-z undefs and will build fail on:
/home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/mips-linux-gnu/5.3.0/../../../../mips-linux-gnu/bin/ld: warning: -z undefs ignored.
/home/naourr/work/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/aarch64_be-linux-gnu/7.3.1/../../../../aarch64_be-linux-gnu/bin/ld: warning: -z undefs ignored.
So filter -Wl,--no-undefined to fix the issue
Fixes:
- http://autobuild.buildroot.org/results/e9645d9969481b09f507f6e0d0b35faaa283eb60
- http://autobuild.buildroot.org/results/06a6d865b6b7d8ebd793bde214f4a4c40e0962e1
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
This is when building the kernel modules for testsuite:
Makefile:718: Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler
gcc: error: unrecognized command line option ‘-fstack-protector-strong’
Just drop gcc 4.8 from running tests. Failure not really related to kmod.
If there are built-in dependencies and any of them is built-in in
the kernel, modprobe -r fails with
modprobe: FATAL: Module module_name is builtin.
It makes sense to ignore such dependencies for the case when
removing is called for non-top level module.
Example: cifs module, it declares bunch of softdeps and the first
one fails on some kernel configs:
modprobe: FATAL: Module gcm is builtin.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
kmod's configure.ac uses the -Wl,--no-undefined linker flag to verify
at link time that all symbols of shared libraries are available, and
that there are no undefined symbols.
This make perfect sense for regular shared libraries. However, for
Python extensions, which will be dlopen()ed inside the Python
interpreter, it makes less sense.
Since Python 3.8, there is a change in python-config script and
Python's pkg-config file: it no longer links Python extensions with
the libpython library. See
https://docs.python.org/dev/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build
which states:
On the other hand, pkg-config python3.8 --libs no longer contains
-lpython3.8. C extensions must not be linked to libpython (except on
Android and Cygwin, whose cases are handled by the script); this
change is backward incompatible on purpose. (Contributed by Victor
Stinner in bpo-36721.)
So, when linking the kmod Python extensions, it currently fails with
numerous unresolved symbols, that were previously provided by
libpython:
/home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-buildroot-linux-gnu/7.4.0/../../../../powerpc64-buildroot-linux-gnu/bin/ld: libkmod/python/kmod/.libs/list_la-list.o: in function `__Pyx_PyObject_GetAttrStr':
list.c:(.text.__Pyx_PyObject_GetAttrStr+0x48): undefined reference to `PyObject_GetAttr'
/home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-buildroot-linux-gnu/7.4.0/../../../../powerpc64-buildroot-linux-gnu/bin/ld: libkmod/python/kmod/.libs/list_la-list.o: in function `__pyx_tp_dealloc_4kmod_4list_ModListItem':
list.c:(.text.__pyx_tp_dealloc_4kmod_4list_ModListItem+0x78): undefined reference to `PyObject_CallFinalizerFromDealloc'
/home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-buildroot-linux-gnu/7.4.0/../../../../powerpc64-buildroot-linux-gnu/bin/ld: libkmod/python/kmod/.libs/list_la-list.o: in function `__pyx_tp_dealloc_4kmod_4list_ModList':
list.c:(.text.__pyx_tp_dealloc_4kmod_4list_ModList+0x30): undefined reference to `PyErr_Fetch'
[Complete log at http://autobuild.buildroot.net/results/79a/79a5a0398723e8cfea0d0aa3dec5f7649aee4c63/build-end.log]
Linking with libpython is no longer recommended: those symbols should
remain unresolved in the Python extensions, as they wil be properly
resolved when the Python extension gets loaded into the Python
interpreter.
Since we want to keep -Wl,--no-undefined globally in kmod, we leave
the configure.ac file unchanged, and instead, specifically in the
LDFLAGS used to build the Python extensions, we override
-Wl,--no-undefined with -Wl,-z,undefs. Ideally, -Wl,--no-undefined is
the same as -Wl,-z,defs, and the effect of these options can be
canceled on the linker command line by a following -Wl,-z,undefs (see
the ld man page for details).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Victor Stinner <victor.stinner@gmail.com>
Linux uses either PKCS #7 or CMS for signing modules (see
scripts/sign-file.c). CMS is not supported by LibreSSL or older OpenSSL,
so PKCS #7 is used on systems with these libcrypto providers.
CMS and PKCS #7 formats are very similar. CMS is newer but is as much as
possible backward compatible with PKCS #7 [1]. PKCS #7 is supported in
the latest OpenSSL as well as CMS. The fields used for signing kernel
modules are supported both in PKCS #7 and CMS.
For now modinfo uses CMS with no alternative requiring OpenSSL 1.1.0 or
newer.
Use PKCS #7 for parsing module signature information, so that modinfo
could be used both with OpenSSL and LibreSSL.
[1] https://tools.ietf.org/html/rfc5652#section-1.1
Changes v1->v2:
- Don't use ifdefs for keeping redundant CMS code, just use PKCS #7 both
with OpenSSL and LibreSSL.
Signed-off-by: Stefan Strogin <steils@gentoo.org>
Currently, check_module_inuse returns a wrong user message
if the kernel is built without module unloading support.
Fix it by returning a more specific error, in case 'refcnt'
attribute is missing.
In the previous build setup, libkmod.so would link to not just
libcrypto.so, but also libssl.so:
$ readelf -d /lib/libkmod.so | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [liblzma.so.5]
0x0000000000000001 (NEEDED) Shared library: [libz.so.1]
0x0000000000000001 (NEEDED) Shared library: [libssl.so.1.1]
0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
We don't need any symbols from libssl, though. This patch ensures that
we pass 'libcrypto' to pkgconfig rather than 'openssl', getting only the
library that we need:
$ readelf -d ./libkmod/.libs/libkmod.so.2.3.4 | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [liblzma.so.5]
0x0000000000000001 (NEEDED) Shared library: [libz.so.1]
0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
