[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: Busybox modprobe hitch with kernel 5.10
From:       Denys Vlasenko <vda.linux () googlemail ! com>
Date:       2020-12-31 0:50:57
Message-ID: CAK1hOcPO9WqRz_ZEdwNm--qTu1JPdQmJE-xndLYBFcpehhtGyg () mail ! gmail ! com
[Download RAW message or body]

On Thu, Dec 31, 2020 at 1:45 AM Qu Wenruo <wqu@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.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]