linux-kernel - Re: [PATCH] ARM: do not assemble iwmmxt.S with LLVM toolchain

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: <CAK7LNAS-juF8dpeSVCuYQPwJ5HSQypFqOvesGFQR4bzTf23nUg@mail.gmail.com>
Date:   Fri, 17 Apr 2020 23:12:35 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Ard Biesheuvel <ardb@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Kristof Beyls <Kristof.Beyls@....com>,
        Stephen Hines <srhines@...gle.com>,
        Luis Lozano <llozano@...gle.com>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Arnd Bergmann <arnd@...db.de>, Jian Cai <caij2003@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Peter Smith <Peter.Smith@....com>,
        Stefan Agner <stefan@...er.ch>,
        David Howells <dhowells@...hat.com>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Manoj Gupta <manojgupta@...gle.com>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        "Joel Fernandes (Google)" <joel@...lfernandes.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        Ilie Halip <ilie.halip@...il.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Steven Rostedt (VMware)" <rostedt@...dmis.org>,
        Jian Cai <jiancai@...gle.com>,
        Doug Anderson <armlinux@...isordat.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Patrick Bellasi <patrick.bellasi@....com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Tejun Heo <tj@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] ARM: do not assemble iwmmxt.S with LLVM toolchain

Hi

On Thu, Apr 16, 2020 at 12:44 AM Kees Cook <keescook@...omium.org> wrote:
>
> On Wed, Apr 15, 2020 at 12:32:17PM +0200, Ard Biesheuvel wrote:
> > To reiterate my point: I strongly prefer minor asm surgery over
> > elaborate Kconfig plumbing if it means we can retain the functionality
> > even when using LLVM tools. In particular, the use of macros to
> > implement missing ISA support should be considered before any other
> > solution, as these are already being used widely across architectures
> > to fill in such gaps.
>
> Yeah, this seems like the right place to start from. It sounded like
> there were cases where the people with knowledge needed to accomplish
> the macro creation were not always immediately available. But, yes,
> let's get iwmmxt fixed up.
>
> > This code has been around since 2004. It has never been possible to
> > assemble it with Clang's assembler. So the only thing this patch gives
> > you is the ability to switch from a .config where IWMMXT was disabled
> > by hand to one where it gets disabled automatically by Kconfig.
>
> Right -- I meant "let's fix iwmmxt with macro magic" not "let's disable
> it". I did want to point out the Kconfig disabling may be needed in
> other cases.
>
> > So what hard-won ground are we losing here? Did IWMMXT recently get
> > enabled in a defconfig that you care about?
>
> It's a CI's ability to do randconfig builds to catch new stuff. (i.e.
> where "disabled by hand" isn't part of the process.) Since there are
> multiple CIs doing multi-architecture builds we need to get these things
> fixed upstream, not a CI's local patch stacks or Kconfig whitelists,
> etc. And when the expertise isn't available to fix arch-specific stuff,
> Kconfig negative depends seems like a reasonable middle ground. I, too,
> prefer fixes that allow Clang to do its work without wrecking things
> for GNU as.
>
> > I am not disagreeing with you here, and I have worked with Nick,
> > Nathan and Stefan on numerous occasions to get Clang related build
> > issues solved.
>
> Yup! Totally; this thread just looked very familiar to me from doing
> treewide stuff and I didn't want what I thought looked like the core
> points to get lost in the details. :)
>
> --
> Kees Cook



When I started to read this thread,
I just slightly preferred
    depends on $(as-instr, <some iwmmxt instructions>)
over
    depends on AS_IS_CLANG

because it is what we recently did for x86.
commit 5e8ebd841a44b895e2bab5e874ff7d333ca31135


But, Ard's macro approach seems even better.


I do not know how difficult to replace
the arch/x86/Kconfig.assembler with .macro

Anyway, arch/x86/Kconfig.assembler will be gone
when we raise the binutils version next time.


-- 
Best Regards
Masahiro Yamada