linux-kernel - Re: [tip:x86/urgent] x86/mm/kaslr: Use the _ASM_MUL macro for multiplication to work around Clang incompatibility

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:   Sat, 6 May 2017 10:16:35 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Michael Davidson <md@...gle.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Anvin <hpa@...or.com>, grundler@...omium.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Greg Hackmann <ghackmann@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        "linux-tip-commits@...r.kernel.org" 
        <linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:x86/urgent] x86/mm/kaslr: Use the _ASM_MUL macro for
 multiplication to work around Clang incompatibility

On Fri, May 05, 2017 at 01:36:34PM -0700, Michael Davidson wrote:

> There are a few lingering places in the kernel which use variable
> length arrays in structs (eg the raid10 driver) which don't build with
> clang and that is about it.

So the other point I raised is lack of asm goto (and asm flags output).

Without that our static key infrastructure reverts to runtime branches
and affects performance.

> So, while I completely understand the resistance to adding arbitrary
> hacks to the kernel just to support another compiler it is important
> to also understand just how close things are to "just working".

Reading up on the LLVM thread on asm goto they appear to want to provide
an intrinsic to allow doing the patchable branch thing. That would be
fairly limiting, and the proposal I've seen doesn't even cover the two
(or rather 4) states of patchable branches we have in the kernel.

Not to mention that such an intrinsic doesn't even begin to cover all
the other (perhaps creative) uses we have got asm goto used.

But my main point is that we'd have to rewrite and maintain _two_
versions of the static key infrastructure if we were to support LLVM's
intrinsic and the GCC asm goto. That is a very undesirable place to be.

So while they'll say they support the feature, I'll say its worthless
since I'm not inclined to support their variant of it. As is, I'm not
getting the feeling the LLVM team really cares about Linux.