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]
Date:   Mon, 20 Aug 2018 23:33:31 +0200
From:   Michal Suchánek <msuchanek@...e.de>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Takashi Iwai <tiwai@...e.de>, Andreas Schwab <schwab@...e.de>,
        Michal Kubecek <mkubecek@...e.cz>,
        Michal Marek <michal.lkml@...kovi.net>,
        Jonathan Corbet <corbet@....net>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Rich Felker <dalias@...c.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jeff Dike <jdike@...toit.com>,
        Richard Weinberger <richard@....at>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ulf Magnusson <ulfalizer@...il.com>,
        Jeff Mahoney <jeffm@...e.com>,
        "Peter Zijlstra," <peterz@...radead.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Frederic Weisbecker <frederic@...nel.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Nicholas Piggin <npiggin@...il.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Linux-sh list <linux-sh@...r.kernel.org>,
        sparclinux <sparclinux@...r.kernel.org>,
        linux-um@...ts.infradead.org
Subject: Re: due to kconfig changes kernel config file is no longer
 sufficient for configuring the kernel

Hello,

On Tue, 21 Aug 2018 03:15:12 +0900
Masahiro Yamada <yamada.masahiro@...ionext.com> wrote:

> 2018-08-07 3:07 GMT+09:00 Michal Suchánek <msuchanek@...e.de>:
> > On Mon, 30 Jul 2018 17:02:42 +0900
> > Masahiro Yamada <yamada.masahiro@...ionext.com> wrote:
> >  
> >> 2018-06-28 18:16 GMT+09:00 Michal Suchánek <msuchanek@...e.de>:  
> >> > On Wed, 27 Jun 2018 23:07:21 +0900
> >> > Masahiro Yamada <yamada.masahiro@...ionext.com> wrote:
> >> >  

> >>
> >>
> >>  
> >> >>
> >> >> out-of-tree modules are built with exactly the same
> >> >> configuration as used for the kernel.  
> >> >
> >> > It is not true. And that is the problem. You need the config file
> >> > and dump of the environment passed to the make command at
> >> > configuration time to get the exact same configuration. The
> >> > environment is not saved anywhere, though.  
> >>
> >>
> >> Why dump of the environment?
> >>
> >>
> >> If you are building external modules natively
> >> your distribution provides /lib/modules/$(uname -r)/build,
> >> which contains files enough for building external modules.
> >>
> >> You can pass the directory path to M=... parameter.  That's it.  
> >
> > No, that's not it. Since passing ARCH=i386 is the de-facto standard
> > to configure a 32bit kernel and the result of passing that was not
> > saved you need to pass it to make as well.  
> 
> 
> If you pass ARCH= for the configuration phase,
> you need to pass the same ARCH= in the build phase.
> 
> 
> 
> 
> What I can suggest for you is:
> 
> 
> $ make ARCH=i386 defconfig
> $ make ARCH=i386
> 
>    OR
> 
> $ make i386_defconfig
> $ make

Maybe you missed that but I do not want to build the defconfig. I want
to build a *particular* config which has been saved in a file
beforehand.
> 
> > And you need to patch a number of
> > 3rd party build scripts that build a kernel module as part of a
> > bigger project.  
> 
> 
> You do not need to patch a number of scripts.
> 
> Just one liner fix.
> Add 'export ARCH=i386' in the top level script.

And that does not work because there is no toplevel script. rpm has
three toplevel scripts - prep, build and install.

Building out-of-tree module is another toplevel script.

And it does not suffice to 'export ARCH=i386'. What if it was a 64bit
config? How do I tell?

With more and more options left out of the config that depend on
compiler features, environment variables, phase of the moon or whatnot
you can't even tell what kind of kernel the user is running by looking
at the config.

Thanks

Michal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ