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]

Date:   Wed, 15 Apr 2020 08:44:26 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     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>,
        Masahiro Yamada <masahiroy@...nel.org>,
        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

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