linux-kernel - Re: [PATCH kmod v5 0/5] 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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230821062252.GF8826@kitsune.suse.cz>
Date:   Mon, 21 Aug 2023 08:22:52 +0200
From:   Michal Suchánek <msuchanek@...e.de>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     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 kmod v5 0/5] kmod /usr support

On Sat, Aug 19, 2023 at 08:25:52PM +0900, Masahiro Yamada wrote:
> On Fri, Aug 18, 2023 at 12:15 PM Michal Suchánek <msuchanek@...e.de> wrote:
> >
> > Hello,
> >
> > On Tue, Jul 18, 2023 at 02:01:51PM +0200, Michal Suchanek wrote:
> > > Hello,
> > >
> > > with these patches it is possible to install kernel modules in an arbitrary
> > > directory - eg. moving the /lib/modules to /usr/lib/modules or /opt/linux.
> > >
> > > While the modprobe.d and depmod.d search which already includes multiple
> > > paths is expanded to also include $(prefix) the module directory still
> > > supports only one location, only a different one under $(module_directory).
> > >
> > > Having kmod search multiple module locations while only one is supported now
> > > might break some assumption about relative module path corresponding to a
> > > specific file, would require more invasive changes to implement, and is not
> > > supportive of the goal of moving the modules away from /lib.
> > >
> > > Both kmod and the kernel need to be patched to make use of this feature.
> > > Patched kernel is backwards compatible with older kmod.  Patched kmod
> > > with $(module_directory) set to /lib/modules is equivalent to unpatched kmod.
> >
> > The patch to kernel to support autodetection of module directory is
> > rejected. However, a workaround like
> >
> > make MODLIB='$(INSTALL_MOD_PATH)/usr/lib/modules/$(KERNELRELEASE)'
> >
> > is suggested.
> >
> > Can you consider inluding the kmod changes?
> 
> 
> Hi.
> 
> I have a question about your original patch
> for the Kbuild change.
> 
> In your patch, Kbuild runs 'kmod config' or
> 'pkg-config --variable=module_directory kmod',
> then sets the returned string to MODLIB.
> 
> 
> If kmod is configured to use /usr/lib/modules,
> /opt/modules, or whatever,
> should we change the installation path of the debug
> vdso accordingly?
> 
> Currently, the debug vdso is always installed
> to /lib/modules/$(KERNELRELEASE)/vdso/.
> 
> However, modules and vdso are unrelated to each other.
> kmod does not care about vdso.
> 
> 
> The following commits started to install debug vdso.
> 
> Commit 8150caad0226 ("[POWERPC] powerpc vDSO: install unstripped
> copies on disk")
> Commit f79eb83b3af4 ("x86: Install unstripped copy of 64bit vdso to disk")
> 
> 
> I do not know why they chose $(MODLIB)/vdso as the install destination.

It's the only directory that exists per-kernel-release.

While technically vdso has nothing to do with modules there is no other
place where it can be stored where it would not conflict between kernel
releases so far.

In fact the distro followed the pattern and started dumping other things
not related to kernel modules into $(MODLIB) for this very reason. Also
from the distribution point of view $(MODLIB) is listed as owned by the
kernel package, and additional files that might be there sometimes need
not be specially handled.

Finally any tools that can find vdso today will search for it in
$(MODLIB), and consequently moving it elsewhere is not practical.

If the makefiles grow a VDSOLIB it should default to MODLIB. It may be
useful for somebody to have this flexibility in the future but I am not
interested for my use case.

Thanks

Michal