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: <20230911195048.GK8826@kitsune.suse.cz>
Date:   Mon, 11 Sep 2023 21:50:48 +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.
> 
> 
> I am thinking of split the variable into two:
> MODLIB -  installation path for modules
> VDSOLIB - installation path for debug vdso (not affected by kmod config)
> 
> I think that is the way to do this correctly.

The source and build symlinks that point at the kernel tree are not
modules either yet they are in the module directory as well.

Thanks

Michal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ