Busybox modprobe hitch with kernel 5.10
vda.linux at googlemail.com
Thu Dec 31 00:50:57 UTC 2020
On Thu, Dec 31, 2020 at 1:45 AM Qu Wenruo <wqu at suse.com> wrote:
> >> Ah, I see what's happening. modprobe normally tries finit_module()
> >> first, and falls back to init_module() for compressed modules, which
> >> is the case here. We added new error messages as part of an effort to
> >> demystify module loader errors, since sometimes we don't always know
> >> why a module fails to load (See upstream kernel commit: 14721add58ef).
> >> Since loading compressed modules will always produce this message from
> >> finit_module(), I would be fine with removing the message for now as a
> >> workaround. Perhaps the long-term solution would be to teach
> >> finit_module() to work with compressed modules. Wenruo, since you were
> >> the commit author, would you be fine with dropping the pr_err() message?
> Not exactly.
> In fact, the error message matches what the
> init_module(2)/finit_module(2) says:
> init_module() loads an ELF image into kernel space, performs any
> necessary symbol relocations ...
> We're not supposed to load compressed data from the very first place,
> thus the ELF header check is valid, and doing its work.
> And consider such case, where a kernel module is really corrupted,
> without the message, how would the end user really know what's going wrong?
> Not every end user would be able to add extra pr_*() calls into the
> kernel and find out the problem.
> Really, it's the user space module loader not doing it proper checking.
User space module loader has no idea whether kernel can accept
a gzipped or xz-ed module via finit_module().
> > I can add a condition to not try finit_module() on compressed modules,
> > however, I anticipate needing to revert it when kernel learns how to load
> > compressed modules as well.
> If kernel is really going to detect compressed module, the decompression
> should happen before we check the ELF header, thus the error message
> should still be there.
I was talking from the userspace perspective: is there a reasonable way
to be more careful for userspace? No, unless userspace assumes
that finit_module() will *never* be extended to handle .ko.gz modules.
More information about the busybox