[openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

[via RT]

Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry
Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto
extensions, but includes vmull and crc32 (vmull include arrangements
other than u8). The gadget also runs Raspian, which is a 32-bit OS
with hard floats.

$ make test V=1

ok 1 - running enginetest
../util/shlib_wrap.sh ./enginetest => 0
ok
../test/recipes/30-test_evp.t ..............
1..1
not ok 1 - running evp_test evptests.txt
../util/shlib_wrap.sh ./evp_test ../test/evptests.txt => 135

# Failed test 'running evp_test evptests.txt'
# at ../test/recipes/30-test_evp.t line 18.
# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/30-test_evp_extra.t ........
1..1
PASS

**********

$ ./config -march=armv8-a+crc -mtune=cortex-a53
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
Operating system: armv7l-whatever-linux2
Configuring for linux-armv4
Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
no-asan [default] OPENSSL_NO_ASAN (skip dir)
no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
no-crypto-mdebug-backtrace [default]
OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-egd [default] OPENSSL_NO_EGD (skip dir)
no-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir)
no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (skip dir)
no-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir)
no-md2 [default] OPENSSL_NO_MD2 (skip dir)
no-msan [default] OPENSSL_NO_MSAN (skip dir)
no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
no-sctp [default] OPENSSL_NO_SCTP (skip dir)
no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir)
no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir)
no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir)
no-ubsan [default] OPENSSL_NO_UBSAN (skip dir)
no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
no-zlib [default]
no-zlib-dynamic [default]
Configuring for linux-armv4
CC =gcc
CFLAG =-Wall -O3 -pthread -march=armv8-a+crc
-mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
-march=armv7-a -Wa,--noexecstack
SHARED_CFLAG =-fPIC
DEFINES =DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS
OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_BN_ASM_MONT
OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM AES_ASM BSAES_ASM
GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
LFLAG =
PLIB_LFLAG =
EX_LIBS =-ldl
APPS_OBJ =
CPUID_OBJ =armcap.o armv4cpuid.o
UPLINK_OBJ =
BN_ASM =bn_asm.o armv4-mont.o armv4-gf2m.o
EC_ASM =ecp_nistz256.o ecp_nistz256-armv4.o
DES_ENC =des_enc.o fcrypt_b.o
AES_ENC =aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o
BF_ENC =bf_enc.o
CAST_ENC =c_enc.o
RC4_ENC =rc4_enc.o rc4_skey.o
RC5_ENC =rc5_enc.o
MD5_OBJ_ASM =
SHA1_OBJ_ASM =sha1-armv4-large.o sha256-armv4.o sha512-armv4.o
RMD160_OBJ_ASM=
CMLL_ENC =camellia.o cmll_misc.o cmll_cbc.o
MODES_OBJ =ghash-armv4.o ghashv8-armx.o
PADLOCK_OBJ =
CHACHA_ENC =chacha-armv4.o
POLY1305_OBJ =poly1305-armv4.o
BLAKE2_OBJ =
PROCESSOR =
RANLIB =ranlib
ARFLAGS =
PERL =/usr/bin/perl

THIRTY_TWO_BIT mode
BN_LLONG mode
RC4 uses unsigned char

Configured for linux-armv4.

[Andy Polyakov via RT]

Post by via RT
Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry
Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto
extensions, but includes vmull and crc32 (vmull include arrangements
other than u8).

??? If you're referring to polynomial multiplication, then it's p8, not
u8. But even if you are implying that it implements p64, then I'd ask
where does this information come from? And how would it align with
Cortex-A53 reference manual which says that AES extension and PMULL
availability is denoted by one and same flag? I mean according to
reference there shouldn't be PMULL-capable processor, which is not also
AES-capable...

Post by via RT
The gadget also runs Raspian, which is a 32-bit OS
with hard floats.
$ make test V=1
ok 1 - running enginetest
../util/shlib_wrap.sh ./enginetest => 0
ok
../test/recipes/30-test_evp.t ..............
1..1
not ok 1 - running evp_test evptests.txt
../util/shlib_wrap.sh ./evp_test ../test/evptests.txt => 135
# Failed test 'running evp_test evptests.txt'
# at ../test/recipes/30-test_evp.t line 18.
# Looks like you failed 1 test of 1.

Could you execute it manually and tell with line in evptests.txt it fails?

[via RT]

Post by Andy Polyakov via RT

Post by via RT
$ make test V=1
ok 1 - running enginetest
../util/shlib_wrap.sh ./enginetest => 0
ok
../test/recipes/30-test_evp.t ..............
1..1
not ok 1 - running evp_test evptests.txt
../util/shlib_wrap.sh ./evp_test ../test/evptests.txt => 135
# Failed test 'running evp_test evptests.txt'
# at ../test/recipes/30-test_evp.t line 18.
# Looks like you failed 1 test of 1.

Could you execute it manually and tell with line in evptests.txt it fails?

$ LD_LIBRARY_PATH=".:$LD_LIBRARY_PATH" test/evp_test test/evptests.txt
Bus error

Probing further:

$ LD_LIBRARY_PATH=".:$LD_LIBRARY_PATH" gdb test/evp_test
GNU gdb (GDB) 7.11.1
...
Reading symbols from test/evp_test...(no debugging symbols found)...done.
(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.
0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
(gdb) where
#0 0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
#1 0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
#2 0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
#3 0x000149cc in cipher_test_run ()
#4 0x0001408c in setup_test ()
#5 0x00011a48 in main ()

(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.

I've added every directory that has symbols ab object files using 'set
debug-file-directory' and 'set solib-search-path'. It looks like
Aarch64 is another platform GDB is broken on:

(gdb) show debug-file-directory
The directory where separate debug symbols are searched for is
"/usr/local/lib/debug".
(gdb)

Jeff

[via RT]

Post by via RT
(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:

(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=***@entry=0x33788,
inp=***@entry=0x33649
"\232_\314ʹ\317\004\347)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
out=<optimized out>,
***@entry=0x335d8
"\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
len=***@entry=0x20) at crypto/modes/ccm128.c:253
253 ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
(gdb)


Jeff

[Andy Polyakov via RT]

Post by via RT

Post by via RT
(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.

Well, what can I say? This is first indication that it's a compiler bug...

Post by via RT
(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.
"\232_\314ʹ\317\004\347)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
out=<optimized out>,
"\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
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. Besides, default ./config works just fine and (once
again) I see no compelling reason for not using it.

[Andy Polyakov via RT]

Post by Andy Polyakov via RT

Post by via RT

Post by via RT
(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.

Well, what can I say? This is first indication that it's a compiler bug...

Post by via RT
(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.
"\232_\314ʹ\317\004\347)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
out=<optimized out>,
"\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
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.

Post by Andy Polyakov via RT
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...

[via RT]

Post by Andy Polyakov via RT

Post by via RT
(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.
"\232_\314ʹ\317\004\347)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
out=<optimized out>,
"\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
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. Besides, default ./config works just fine and (once
again) I see no compelling reason for not using it.

I think these are the lines:

#if defined(STRICT_ALIGNMENT)
union {
u64 u[2];
u8 c[16];
} temp;
#endif

...

#if defined(STRICT_ALIGNMENT)
memcpy(temp.c, inp, 16);
ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
ctx->cmac.u[1] ^= (scratch.u[1] ^= temp.u[1]);
...
#endif

I *thought* accessing a union member through its inactive member is
undefined behavior. Once 'scratch.c' and 'temp.c' were used, using
'temp.c' and 'temp.u' leads to the UB.

Maybe my wires are crossed somewhere....

Jeff

[Andy Polyakov via RT]

Post by Andy Polyakov via RT

Post by Andy Polyakov via RT

Post by via RT
(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.
"\232_\314ʹ\317\004\347)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
out=<optimized out>,
"\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
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. Besides, default ./config works just fine and (once
again) I see no compelling reason for not using it.

#if defined(STRICT_ALIGNMENT)
union {
u64 u[2];
u8 c[16];
} temp;
#endif
...
#if defined(STRICT_ALIGNMENT)
memcpy(temp.c, inp, 16);
ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
ctx->cmac.u[1] ^= (scratch.u[1] ^= temp.u[1]);
...
#endif
I *thought* accessing a union member through its inactive member is
undefined behavior.

Really? It says "When a value is stored in a member of an object of
union type, the bytes of the object representation that do not
correspond to that member but do correspond to other members take
unspecified values." Referred members fully overlap and there are no
bytes that correspond to one and not another.

Post by Andy Polyakov via RT
Once 'scratch.c' and 'temp.c' were used, using
'temp.c' and 'temp.u' leads to the UB.

But either way union with u64 member has to be aligned, so references to
.u should not cause SIGBUS.