linux-kernel - Re: [PATCH 0/2] kmod /usr support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7LNASEdXPiP0_i5=1uLW-W0kZ9LiMt9r5aq0Gu5nK2yP5wDA@mail.gmail.com>
Date: Fri, 23 Aug 2024 22:03:05 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Michal Suchánek <msuchanek@...e.de>
Cc: Lucas De Marchi <lucas.demarchi@...el.com>, linux-modules@...r.kernel.org, 
	Takashi Iwai <tiwai@...e.com>, Lucas De Marchi <lucas.de.marchi@...il.com>, 
	Michal Koutný <mkoutny@...e.com>, 
	Jiri Slaby <jslaby@...e.com>, Jan Engelhardt <jengelh@...i.de>, Nathan Chancellor <nathan@...nel.org>, 
	Nick Desaulniers <ndesaulniers@...gle.com>, Nicolas Schier <nicolas@...sle.eu>, 
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] kmod /usr support

On Thu, Aug 22, 2024 at 5:36 PM Michal Suchánek <msuchanek@...e.de> wrote:
>
> Hello,
>
> On Thu, Aug 22, 2024 at 01:05:11AM -0500, Lucas De Marchi wrote:
> > On Tue, Dec 19, 2023 at 05:37:31PM GMT, Masahiro Yamada wrote:
> > > On Thu, Dec 7, 2023 at 3:37 AM Lucas De Marchi <lucas.demarchi@...el.com> wrote:
> > > >
> > > > On Fri, Nov 10, 2023 at 01:13:53PM +0100, Michal Suchanek wrote:
> > > > >Hello,
> > > > >
> > > > >This is resend of the last patch in the series that adds prefix support
> > > > >to kernel module location together with additional patch for validating
> > > > >the user supplied input to options that are interpreted as directories.
> > > > >
> > > > >Thanks
> > > >
> > > > applied, thanks
> > > >
> > > > Lucas De Marchi
> > >
> > >
> > >
> > > If I understood this correctly, MODULE_DIRECTORY is determined
> > > by "configure --with-module-directory=...", and there is no
> > > way to change it after that.
> > >
> > >
> > > If so, how to work with cross-building?
> > >
> > > Cross-building is typical when building embedded Linux systems.
> >
> > I was thinking the `pkg-config --variable=module_directory`
> > from the target would be sufficient, but...
> >
> > >
> > >
> > > Consider this scenario:
> > >
> > > - Your build machine adopts
> > >    MODULE_DIRECTORY=/usr/lib/modules
> > > - The target embedded system adopts
> > >    MODULE_DIRECTORY=/lib/modules
> > >
> > > (or vice a versa)
> > > depmod is used also for cross-building because
> > > it is executed as a part of "make module_install".
> > >
> > >
> > > The counterpart patch set for Kbuild provides
> > > KERNEL_MODULE_DIRECTORY, which only changes
> > > the destination directory to which *.ko are copied.
> > >
> > > You cannot change the directory where the
> > > depmod searches for modules, as it is fixed
> > > at the compile-time of kmod.
> > >
> > >
> > >
> > >
> > > In this case, what we can do is to build another
> > > instance of kmod configured for the target system,
> >
> > the target system may not even have depmod actually, so using just the
> > host one seems more appropriate. But target should have the kmod.pc for
> > the pkg-config call to work.
> >
> > > and use it for modules_install:
> > >
> > > 1. In the kmod source directory
> > >    ./configure --with=module-directory=/lib/modules
> > >    make
> > >
> > > 2. make modules_install INSTALL_MOD_PATH=<staging-dir>
> > >     KERNEL_MODULE_DIRECTORY=/lib/modules
> > >     DEPMOD=<new-depmod-you-has-just-built>
> > >
> > >
> > >
> > > If you use OpenEmbedded etc., this is what you do
> > > because host tools are built from sources.
> > >
> > > But, should it be required all the time?
> > > Even when the target embedded system uses
> > > busybox-based modprobe instead of kmod?
> >
> > no, I don't think we can rely on depmod from the target.
> >
> > >
> > >
> > >
> > > depmod provides --basedir option, which changes
> > > the prefix part, but there is no way to override
> > > the stem part, MODULE_DIRECTRY.
> > >
> > > In the review of the counter patch set,
> > > I am suggesting an option to override MODULE_DIRECTRY
> > > (let's say --moduledir) at least for depmod.
> >
> > ok
> >
> > >
> > > (Perhaps modinfo too, as it also supports --basedir)
> > >
> > >
> > >
> > > Then, we can change scripts/depmod.sh so that
> > > Kbuild can propagate KERNEL_MODULE_DIRECTORY
> > > to depmod.
> > >
> > >
> > > if  <depmod supports --moduledir>; then
> > >    set -- "$@"  --moduledir "${KERNEL_MODULE_DIRECTORY}"
> > > fi
> > >
> > >
> > >
> > > Does it make sense?
>
> It does not make sense for the common case: building kernel for the host
> system.
>
> Then overriding the directory is wrong, and using what kmod was compiled
> with is needed to get correct module directory layout.


NACK.

scripts/Makefile.modinst and depmod must agree about
the install destination.

Both must refer to the same ${KERNEL_MODULE_DIRECTORY}.




>
> Or it would make sense if both was done:
>
> Default KERNEL_MODULE_DIRECTORY to what kmod was compiled with, and
> then pass the actual value to depmod so that depmod uses the compiled-in
> value by default, and the user-provided value when
> KERNEL_MODULE_DIRECTORY was overridden by the user.
>
> Thanks
>
> Michal



-- 
Best Regards
Masahiro Yamada