linux-kernel - Re: [PATCH] kbuild: Include external modules compile flags

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:   Sun, 2 Feb 2020 15:07:21 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Gregory Rose <gvrose8192@...il.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dev@...nvswitch.org, dsahern@...il.com
Subject: Re: [PATCH] kbuild: Include external modules compile flags

On Thu, Jan 30, 2020 at 3:09 AM Gregory Rose <gvrose8192@...il.com> wrote:
>
>
> On 1/28/2020 7:37 AM, Gregory Rose wrote:
> > On 1/27/2020 7:35 PM, Masahiro Yamada wrote:
> >> On Tue, Jan 28, 2020 at 6:50 AM Greg Rose <gvrose8192@...il.com> wrote:
> >>> Since this commit:
> >>> 'commit 9b9a3f20cbe0 ("kbuild: split final module linking out into
> >>> Makefile.modfinal")'
> >>> at least one out-of-tree external kernel module build fails
> >>> during the modfinal make phase because Makefile.modfinal does
> >>> not include the ccflags-y variable from the exernal module's Kbuild.
> >> ccflags-y is passed only for compiling C files in that directory.
> >>
> >> It is not used for compiling *.mod.c
> >> This is true for both in-kernel and external modules.
> >>
> >> So, ccflags-y is not a good choice
> >> for passing such flags that should be globally effective.
> >>
> >>
> >> Maybe, KCFLAGS should work.
> >>
> >>
> >> module:
> >>         $(MAKE) KCFLAGS=...  M=$(PWD) -C /lib/modules/$(uname
> >> -r)/build modules
> >>
>
> Hi Masahiro,
>
> I'm unable to get that to work.  KCFLAGS does not seem to be used in
> Makefile.modfinal.


I quickly tested it, and confirmed
KCFLAGS works for external modules, too.


Makefile.modfinal includes scripts/Makefile.lib


So,  c_flags contains $(KCFLAGS)

 c_flags -> KBUILD_CFLAGS -> KCFLAGS






> [snip]
> >>> --- a/scripts/Makefile.modfinal
> >>> +++ b/scripts/Makefile.modfinal
> >>> @@ -21,6 +21,10 @@ __modfinal: $(modules)
> >>>   modname = $(notdir $(@:.mod.o=))
> >>>   part-of-module = y
> >>>
> >>> +# Include the module's Makefile to find KBUILD_EXTRA_SYMBOLS
> >>> +include $(if $(wildcard $(KBUILD_EXTMOD)/Kbuild), \
> >>> +             $(KBUILD_EXTMOD)/Kbuild)
> >>> +
>
> I continue to wonder why this it is so bad to include the external
> module's Kbuild.


Because it is not correct behavior.


> It used to be included in Makefile.modpost and did no harm, and in fact
> was what
> made our external build work at all in the past.  Without the ability to
> define our
> local kernel module build environment during the modfinal make I see no
> way forward.


As I said, ccflags-y is not intended to be
passed to *.mod.c
Upstream modules never rely on it.

External module should not rely on it either.


>
> That said, I'm no expert on the Linux kernel Makefile
> interdependencies.  If you
> have some other idea we could try I'm game.

-- 
Best Regards
Masahiro Yamada