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:   Fri, 5 May 2017 20:22:55 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     mka@...omium.org, md@...gle.com, tglx@...utronix.de, hpa@...or.com,
        torvalds@...ux-foundation.org, grundler@...omium.org,
        linux-kernel@...r.kernel.org, ghackmann@...gle.com,
        keescook@...omium.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 07:50:39PM +0200, Ingo Molnar wrote:

> > > The constraint "rm" allows the compiler to put mix_const into memory.
> > > When the input operand is a memory location then MUL needs an operand
> > > size suffix, since Clang can't infer the multiplication width from the
> > > operand.
> > 
> > *sigh*, this is another shining example of how LLVM is a better, faster
> > moving compiler?
> 
> Well, I don't like it - but we already have similar patterns to cover some asm 
> complications so I didn't mind. Apparently Clang is very close to being able to 
> build a working Linux kernel, right?
> 
> In that sense it would be unfair to expect it to not have various legacies, 
> missing features and quirks - just like the kernel has dozens of GCC related 
> workarounds.

The distinction is that GCC can actually compile the kernel, and has
been able for a long while. Therefore we actually have to deal with old
versions.

LLVM otoh has never compiled the kernel, so I don't see why we need to
care about its old versions.

The argument made last time is that LLVM is a fast moving compiler etc..
all I'm agitating against is that false claim. You're right that this
patch isn't too bad, but some of them were pretty hideous and until
they've fixed their compiler to deal with those, I don't see the point
of taking these.

Also, LLVM is still lacking some major features like asm goto and asm
flags output operands. Without them supporting those whatever kernel
they do manage to compile is just not worth the trouble.

So rather than try and fudge the kernel source to build on this inferior
compiler, I'd rather see them prove their point and shift LLVM into gear
and build a compiler you'd want to use.