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  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:   Tue, 21 Aug 2018 18:25:18 +0100
From:   Robin Murphy <>
To:     Ard Biesheuvel <>,
        Nick Desaulniers <>
Cc:     Herbert Xu <>,
        Catalin Marinas <>,
        Will Deacon <>,
        LKML <>,
        "David S. Miller" <>,
        Linux ARM <>
Subject: Re: [PATCH] arm64/crypto: remove non-standard notation

On 21/08/18 18:00, Ard Biesheuvel wrote:
> On 21 August 2018 at 18:50, Nick Desaulniers <> wrote:
>> On Tue, Aug 21, 2018 at 5:23 AM Ard Biesheuvel
>> <> wrote:
>>> Hi Nick,
>>> On 21 August 2018 at 00:40, Nick Desaulniers <> wrote:
>>>> It seems that:
>>>> ldr q8, =0x30000000200000001
>>>> is a GNU as convience notation for:
>>>> ldr q8, .Lconstant
>>>> .Lconstant
>>>> .word 0x00000001
>>>> .word 0x00000002
>>>> .word 0x00000003
>>>> .word 0x00000000
>>>> based on this comment in binutils' source [0]. I've asked for this
>>>> non-standard convience notation to be added to other assemblers [1], but
>>>> until then, we can remove it and get equivalent disassembly:
>>> What do you mean by 'non-standard convenience notation'? Which asm
>>> 'standard' does Clang actually claim to implement?
>> Well, for assembly 'standard' is a bit nebulous.  But it's frustrating
>> when you can't find what the `=0x...` notation means in either the ARM
>> or GNU as manuals.  The source of truth happened to be a comment in
>> the source [0] that explained that this was a "programmer friendly
>> notation."  Sure, if you can find it.
> Well, it is documented in the ARM manuals as the 'ldr pseudo
> instruction' for 32-bit ARM, and originally, it would only emit a
> literal if the value could not be loaded using a ordinary mov.

FWIW It's certainly well-documented by common A64 assemblers too:

> For AArch64, I don't think that occurs any longer, i.e., a ldr is
> always emitted as an ldr. However, it is used widely in the ARM code
> (although not as much in arch/arm64) for loading compile time
> constants and even symbol addresses into general purpose registers.
> The FP variant may actually be a GNU invention, but given that there
> is no standard to begin with, playing the 'GNU is non-standard' card
> again is just a bit annoying.

I note that GAS just says "register" rather than explicitly calling out 
GPRs as armasm does, so in some ways it's not even all that unexpected 
that FP registers also work there, even if it is a bit funky.


Powered by blists - more mailing lists