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: <20170506081635.GE4626@worktop.programming.kicks-ass.net>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ