linux-kernel - Re: Clang build of arm64 kernel fails

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 22 Mar 2018 11:55:24 -0700
From:   Matthias Kaehlcke <mka@...omium.org>
To:     Dave Martin <Dave.Martin@....com>
Cc:     Robin Murphy <robin.murphy@....com>,
        Andrey Konovalov <andreyknvl@...gle.com>,
        ard.biesheuvel@...aro.org, Marc Zyngier <marc.zyngier@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        Kostya Serebryany <kcc@...gle.com>,
        linux-arm-kernel@...ts.infradead.org,
        Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: Clang build of arm64 kernel fails

El Thu, Mar 01, 2018 at 10:31:02AM +0000 Dave Martin ha dit:

> On Thu, Mar 01, 2018 at 09:45:24AM +0000, Robin Murphy wrote:
> > Hi Andrey,
> > 
> > On 28/02/18 19:32, Andrey Konovalov wrote:
> > >Hi Marc!
> > >
> > >I've tried to pull in new upstream commits and the kernel build
> > >started failing for me with the following errors (see below).
> > >
> > >It seems that the reason is your commit "arm64: Add
> > >ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support". It seems that Clang
> > >doesn't like 32 bits registers being used in 64 bits build.
> > 
> > I'd say this is really a bug in Clang. Architecturally, the register in
> > AArch64 state is still named "r0"; "x0"/"w0" are assembler operands which
> > additionally encode the size of the corresponding *access* to r0.
> > 
> > I note that GCC's documentation on register variables[1] does just say "the
> > name of the register", which implies this code is not incorrect. Given that
> > Clang already likes to infer the operand size from the argument type in
> > actual inline asms, it seems funny that its register allocator should care
> > in this non-instruction context.
> 
> +1
> 
> rN is perfectly reasonable here and has always been supported by GCC for
> AArch64 AFAIK.
> 
> (IMHO rN is preferable, because this separates the register allocation
> specification from how that register is used to encode the data type --
> GCC has no choice about the latter, but using "w"/"x" gives the
> misleading impression of control over this.)
> 
> > >Would you mind sending a fix?
> > 
> > That said, I guess it's a bug we might have to work around anyway. Oh well.
> 
> It would be preferable to see evidence of the llvm community committing
> to fix this before we consider merging a bodge into Linux for it.
> 
> Although this one issue is easy-ish to work around, we're on a slippery
> slope towards allowing the LLVM and GCC inline assemblers to diverge if
> we don't push back on worthless incompatibilities.

For the record, a LLVM bug was opened to add support for the rN names
in constraints: https://bugs.llvm.org/show_bug.cgi?id=36862 . I know
Manoj intends to submit a fix once the scope has been clarified.

I plan to send a kernel fix soon, unless someone beats me to it.

Matthias