On 7/30/2016 8:18 PM, Andy Polyakov via RT wrote:
>>> (gdb) bt full
>>> #0 0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
>>> No symbol table info available.
>>> #1 0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
>>> No symbol table info available.
>>> #2 0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
>>> No symbol table info available.
>>> #3 0x000149cc in cipher_test_run ()
>>> No symbol table info available.
>>> #4 0x0001408c in setup_test ()
>>> No symbol table info available.
>>> #5 0x00011a48 in main ()
>>> No symbol table info available.
>>
>> OK, -O1 failed to reproduce it; but -O2 reproduced it:
>
> Well, what can I say? This is first indication that it's a compiler bug...
>
>> (gdb) r test/evptests.txt
>> Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>>
>> Program received signal SIGBUS, Bus error.
>> CRYPTO_ccm128_decrypt (ctx=ctx@entry=0x33788,
>> inp=inp@entry=0x33649
>> "\232_\314ʹ\317\004\347)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
>> out=<optimized out>,
>> out@entry=0x335d8
>> "\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
>> len=len@entry=0x20) at crypto/modes/ccm128.c:253
>> 253 ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
>> (gdb)
>
> This line is within #if defined(STRICT_ALIGNMENT), which means that
> compiler is responsible for aligning data, and SIGBUS means that it
> failed. And indeed, looking at disassembler output it crashes in vld1.64
> {d16-d17}, [r6 :64], instruction that requires 64-bit alignment. So
> compiler generated the instruction, but didn't care to ensure the
> alignment. There is no other conclusion one can draw but that is indeed
> a compiler bug.
Problematic option seems to be -mfpu=crypto-neon-fp-armv8.
> Besides, default ./config works just fine and (once
> again) I see no compelling reason for not using it.
For reference, specifying -mfpu doesn't really give you an advantage in
OpenSSL. There are no floating-point calculations on
performance-critical paths. And performance-critical cases when NEON is
used for crypto operations, it's done irregardless -mfpu flag. I mean it
will use NEON even if you don't pass -mfpu. In other words, stick to
default configuration...
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
