linux-kernel - Re: [PATCH v2] x86/boot: define CC_HAVE_ASM

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: <20181001173227.GE7269@zn.tnic>
Date:   Mon, 1 Oct 2018 19:32:27 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     mingo@...hat.com, Thomas Gleixner <tglx@...utronix.de>,
        hpa@...or.com, x86@...nel.org,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Kees Cook <keescook@...omium.org>,
        Cao jin <caoj.fnst@...fujitsu.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] x86/boot: define CC_HAVE_ASM_GOTO

On Thu, Sep 27, 2018 at 03:17:41PM -0700, Nick Desaulniers wrote:
> That's another case that I look at and wonder "why does this exist?"
> The _SETUP guard exists in only one place:
> $ grep -rP 'ifdef\s+_SETUP'
> arch/x86/boot/cpucheck.c:#ifdef _SETUP
> 
> which is already under arch/x86/boot/. arch/x86/boot/Makefile
> unconditionally sets -D_SETUP, so what/who are we guarding against?
> Looks like a guard that's ALWAYS true (and thus could be removed).

Looks like cpucheck.c was used somewhere else before and that guard was
for when it is being built in arch/x86/boot/...

Also, hpa says the override is because some 64-bit flags fail the 32-bit
compile:

https://lkml.kernel.org/r/56442061-7f55-878d-5b26-7cdd14e901d2@zytor.com

> Or, or... we don't redefine KBUILD_CFLAGS in arch/x86/boot/Makefile
> (or any Makefile other than the top level one), and simply filter out
> the flags we DONT want, a la:
> 
> drivers/firmware/efi/libstub/Makefile:
>  16 cflags-$(CONFIG_ARM64)    := $(subst -pg,,$(KBUILD_CFLAGS)) ...
> 
> ie, using Make's subst function to copy KBUILD_CFLAGS, filter out
> results, then use that for cflags-y.
> https://www.gnu.org/software/make/manual/html_node/Text-Functions.html

Hmm, definitely sounds like an interesting idea to try...

> I'm curious to know Masahiro's thoughts on this?  I can't help but
> shake the feeling that reassigning KBUILD_CFLAGS should be considered
> an anti-pattern and warned from checkpatch.pl.  For the reasons
> enumerated above AND in v1:
> https://lore.kernel.org/lkml/CAKwvOdmLSVH7EVGY1ExU1Fh_hvL=FUzhq-80snDfZ+QhCT2FOA@mail.gmail.com/
> (though there may be additional context from hpa answering
> https://lore.kernel.org/lkml/20180926090841.GC5745@zn.tnic/).
> 
> Relying on the compiler's default/implicit C standard (which changed
> in gcc 5) for parts of the kernel but not others I feel like should be
> a big red flag.

I sure see your point. But then there's also the opposing argument where
having stuff leak from kernel proper into .../boot/ is simply breaking
the build.

But then we have headers including stuff from kernel proper so I guess
*that* last fact kinda wants us to not redefine KBUILD_CFLAGS ...

Oh boy.

> Shall I prototype up what such a change might look like (not
> reassigning KBUILD_CFLAGS in arch/x86/boot/Makefile)?  Maybe it's
> harder/uglier than I imagine?

Sounds to me like a good thing to try. If anything, we'll know more
whether it makes sense at all.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.