builtin modules are handled in libkmod by looking at the modules.builtin
index. There's no need to check again for the module's initstate to
decide if it's builtin.
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)
usecase: two sd cards are being mounted in parallel at same time on
dual core. example modules which are getting loaded is nls_cp437.
While one module is being loaded , it starts creating sysfs files.
meanwhile on other core, modprobe might return saying the module
is KMOD_MODULE_BUILTIN, which might result in not mounting sd card.
Experiments done to prove the issue in kmod.
Added sleep in kernel module.c at the place of creation of sysfs files.
Then tried `modprobe nls_cp437` from two different shells.
While the first was still waiting for its completion ,
the second one returned saying the module is built-in.
[ Lucas:
The problem is that the creation of /sys/module/<name> and
/sys/module/<name>/initstate are not atomic. There's a small window in
which the directory exists but the initstate file was still not
created.
Built-in modules can be handled by searching the modules.builtin file.
We actually lose some "modules" that create entries in /sys/modules
(e.g. vt) and are not in modules.builtin file: only those that can be
compiled as module are present in this file.
We enforce mod->builtin to always be up-to-date when
kmod_module_get_initstate() is called. This way if the directory
exists but the initstate doesn't, we can be sure this is because the
module is in the "coming" state, i.e. kernel didn't create the file
yet, but since builtin modules were already handled by checking our
index the only reason for that to happen is that we hit the race
condition.
I also added some tweaks to the patch, so we don't repeat the code for builtin
lookup. ]
Since we pass -std=gnu99 to the compiler __STDC_VERSION__ is defined to
199901. Even in this case we can use _Noreturn. Delegate the testing to
the configure phase with a compile test.
In future we want to stop using AC_PROG_CC_99 and start using the new
AC_PROG_CC from autoconf 2.70, which tries to choose the most recent
standard.
- There's no need for the various AC_PROG_CC* macros
- No need for AC_C_BIGENDIAN: the only place we care about endianness,
we use __BYTE_ORDER
- Organize calls to be in similar order as systemd
- Disable --disable-largefile. We already had possible bugs in the
index implementation if this were passed. It's now fixed, but it's
never tested. Disable it.
- Bump autoconf requirement to 2.64
malloc(0) can return != NULL. We need to pass the pointer to free().
This happens if index__haschildren(node) returned true, but
child_count is set to 0.
Reusing the root variable was a bad idea. Doing so we could call free()
on a variable that was not allocated. For example: "depmod -b / -h".
Since we would jump to cmdline_failed, root would not be duplicated.
Instead of fighting the order in the options, just used the cleanup
attribute and remove the calls to free() on "config_paths" and "root".
gcc does not support testing for negated warnings. See here for details:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63499
This patch changes CC_CHECK_FLAG_APPEND to always test for the non-negated
warnings.
All tests for compiler support were failing with:
/usr/bin/ld: /tmp/ccwnVc2A.o: relocation R_ARM_MOVW_ABS_NC against `a' can not be used when making a shared object; recompile with -fPIC
Use AC_LINK_IFELSE instead of AC_COMPILE_IFELSE to test for flags that
might succeed during compilation but not during linking. An example is gcc
compiled with libssp support but gnu-ld without it. In this case
-fstack-protector works fine during compilation but fails during linking
as several internal helpers are missing.
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.
This is for convenience for development and testing since we don't want
to needlessly cross-compile the modules. There's a README file
explaining the building process for those who want to update them.
These files are compiled from their respective .c and thus have LPGL
license.
If we were expecting output on stdout or stderr but the test didn't
produce any, we were incorrectly assuming the test was successful.
Now test on exit if there was activity on the monitored fd. If there
was, check also if the file size to check for output is > 0 for the
cases in which we want to assert there was no activity on certain fd.
This adds the needed infra to cross-compile modules so we can test them
in our testsuite. Right now we are only compiling mod-simple.ko for x86,
x86_64 and sparc64.
The makefiles are organized in a way it's easy to force a rebuild of a
module by calling the Makefile.arch directly and that allows the rule in
Makefile to not trigger in case we want to ship the modules
pre-compiled.
A segmentation fault occurs if a module has an empty key attached to
its signature. This is mostly likely due to a corrupted module.
The crash happens because kmod_module_get_info() assumes that
kmod_module_signature_info() returns a signature of at least 1 byte.
The fix is based on a patch from Tobias Stoeckmann
<tobias@stoeckmann.org>, but rather than changing kmod_module_get_info()
to fix the crash, this changes kmod_module_signature_info() to
consider the signature as invalid.
If kmod has been configured with --disable-largefile on a 32 bit
system, off_t will be 32 bit. In that case, the parsed sig_len can
bypass a validation check (it's _unsigned_ 32 bit).
Due to the unlikeliness of people using --disable-largefile, this is
a mere validation fix. With an explicit signed 64 bit cast, there is
no binary change for 99.9% of Linux systems out there. ;)
In function kmod_elf_new, the file size has to be properly validated against
section offset. Currently, the file size is considered valid based on
ELF header size + section header size * section count. That is not sufficient.
In fact, ELF specifies a section header offset, which doesn't have to be the
size of the ELF header. The supplied test cases even cover this.
The correct test is: section offset + section header size * section count
This patch also verifies that this value won't overflow. I don't know a way
to crash a tool due to this bug, because later on the offset check would
prevent out-of-bounds access. An overflow would just mean to access a wrong
part in elf->memory. Yet it's a validation error.
Please note: The file size does not have to be validated against the size
of the ELF header again, elf_identify did this already.
Use _builtin_uaddll_overflow/_builtin_uaddl_overflow when available,
abstracting the type to use it with uint64_t.
Otherwise fallback to the implementation as added in 67466f2 ("Prevent
offset + size overflow.").
This also adds the tests for this new helper in the testsuite.
In order to let us use "#if HAVE__BUILTIN_*" without checking if it's
actually define, make sure we define it to 0 in config.h when the
function is not available.
it is possible to overflow uint64_t by summing variables offset and
size up in elf_get_section_info. Thee values are extracted from module
file and are possibly maliciously tampered with.
If offset is in valid range and size very large, the result will
overflow and the size check passes. Later on, this will most likely
lead to a segmentation fault due to accessing uninitialized memory.
Attached please find a proof of concept module, which will trigger
a segmentation fault on modinfo. Tested on amd64:
tobias:~$ modinfo poc.ko
filename: /home/tobias/poc.ko
Segmentation fault
There are more errors of this type in the ELF handling code that will be
fixed in other patches.
Lucas De Marchi
Harish Jenny K N
Colin Walters
David Herrmann
Zbigniew Jędrzejewski-Szmek
Marcus Meissner
Tobias Stoeckmann