[openssl-dev] [openssl.org #3714] OpenSSL 1.0.2 "make test" bus error in evp_test (Solaris 10 Sparc, sun4u)
Rainer Jung via RT
rt at openssl.org
Mon Feb 23 15:13:33 UTC 2015
2nd attempt. First sent on Feb 7th.
I get a failure for 1.0.2 running make test on Solaris 10.
It might be related to #3688, but I don't think so.
Mine is a sun4u machine, so neither T2 nor T4.
Compilation done with gcc 4.9.1 with v9 target.
Failure is a bus error in evp_test.
gdb shows the following details:
(gdb) bt full
#0 CRYPTO_ccm128_decrypt (ctx=0x6cbd0, inp=0xffbfd091
"\232_...230dxg&f042382d949b43b7d6bb2b9864786726",
out=0xffbfdfe8 "...", len=32) at ccm128.c:300
temp = <optimized out>
n = 32
i = <optimized out>
L = 1
flags0 = 121 'y'
block = 0xff1ee3c0 <AES_encrypt>
key = 0x6cac0
scratch = {u = {14547399086359111669, 7716584104704463675}, c =
"..."}
#1 0xff26d774 in aes_ccm_cipher (ctx=0xffbfcf5c, out=0xffbfdfe8 "...",
in=0xffbfd091 "...", len=32) at e_aes.c:1893
rv = -1
cctx = 0x6cac0
ccm = 0x6cbd0
#2 0xff267f6c in EVP_DecryptUpdate (ctx=ctx at entry=0xffbfcf5c,
out=out at entry=0xffbfdfe8 "...", outl=outl at entry=0xffbfcf40,
in=in at entry=0xffbfd091 "...", inl=inl at entry=32) at evp_enc.c:437
fix_len = <optimized out>
b = <optimized out>
#3 0x0001301c in test1 (encdec=<optimized out>, tn=16, tag=<optimized
out>, an=<optimized out>, aad=<optimized out>, cn=32,
ciphertext=0xffbfd091 "...", pn=32,
plaintext=0xffbfd050 "...", in=<optimized out>,
iv=0xffbfd035 "...", kn=<optimized out>, key=<optimized out>,
c=0xff342150) at evp_test.c:346
ctx = {cipher = 0xff342150, engine = 0x0, encrypt = 0, buf_len
= 0, oiv = '\000' <repeats 15 times>, iv = "...",
buf = "...", '\000' <repeats 15 times>, num = 0, app_data =
0x0, key_len = 32, flags = 257, cipher_data = 0x6cac0, final_used = 0,
block_mask = 0, final = '\000' <repeats 31 times>}
outl = 32
out = "..."...
outl2 = 0
mode = <optimized out>
#4 test_cipher (encdec=<optimized out>, tn=16, tag=<optimized out>,
an=<optimized out>, aad=<optimized out>, cn=32,
ciphertext=0xffbfd091 "...", pn=32,
plaintext=0xffbfd050 "...", in=<optimized out>,
iv=0xffbfd035 "...", kn=<optimized out>, key=<optimized out>,
cipher=<optimized out>) at evp_test.c:390
c = 0x13920
#5 main (argc=<optimized out>, argv=<optimized out>) at evp_test.c:546
line = "aes-256-ccm..."...
encdec = <optimized out>
tag = <optimized out>
an = <optimized out>
tn = 16
p = <optimized out>
aad = <optimized out>
szTestFile = <optimized out>
f = <optimized out>
Funny is, that a bus error on Sparc often is due to an alignment
problem, and line 300 where it crashes is:
289 while (len >= 16) {
290 #if defined(STRICT_ALIGNMENT)
291 union {
292 u64 u[2];
293 u8 c[16];
294 } temp;
295 #endif
296 (*block) (ctx->nonce.c, scratch.c, key);
297 ctr64_inc(ctx->nonce.c);
298 #if defined(STRICT_ALIGNMENT)
299 memcpy(temp.c, inp, 16);
300 ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
301 ctx->cmac.u[1] ^= (scratch.u[1] ^= temp.u[1]);
302 memcpy(out, scratch.c, 16);
303 #else
304 ctx->cmac.u[0] ^= (((u64 *)out)[0] = scratch.u[0] ^
((u64 *)inp)[0]);
305 ctx->cmac.u[1] ^= (((u64 *)out)[1] = scratch.u[1] ^
((u64 *)inp)[1]);
306 #endif
307 (*block) (ctx->cmac.c, ctx->cmac.c, key);
308
309 inp += 16;
310 out += 16;
311 len -= 16;
312 }
so inside a "STRICT_ALIGNMENT" block ...
Now ctx->cmac.u[0] and scratch.u[0] seem to be aligned correct to me:
(gdb) print &ctx->cmac.u[0]
$10 = (u64 *) 0x6cbe0
(gdb) print &scratch.u[0]
$12 = (u64 *) 0xffbfcdd0
but temp is not available in gdb:
(gdb) print temp.u[0]
value has been optimized out
It is defined as
290 #if defined(STRICT_ALIGNMENT)
291 union {
292 u64 u[2];
293 u8 c[16];
294 } temp;
295 #endif
gdb command "info registers" says:
g0 0x0 0
g1 0x2 2
g2 0x6c 108
g3 0x4d0000 5046272
g4 0xb0009600 -1342138880
g5 0x3b 59
g6 0x0 0
g7 0xff392a00 -13030912
o0 0xffbfdfe8 -4202520
o1 0xffbfcdd0 -4207152
o2 0x10 16
o3 0x41 65
o4 0x0 0
o5 0x4 4
sp 0xffbfcd60 0xffbfcd60
o7 0xff208064 -14647196
l0 0xffbfcdd0 -4207152
l1 0xff1ee3c0 -14752832
l2 0x6cac0 445120
l3 0x10 16
l4 0xffbfdff8 -4202504
l5 0x6cbe0 445408
l6 0x1 1
l7 0xff338dd8 -13398568
i0 0xffffffff -1
i1 0xffbfd091 -4206447
i2 0xffbfdfe8 -4202520
i3 0x20 32
i4 0xffbfd091 -4206447
i5 0x6cbd0 445392
fp 0xffbfcde0 0xffbfcde0
i7 0xff26d76c -14231700
y 0x0 0
psr 0xfe001001 [ #0 EF #25 #26 #27 #28 #29 #30 #31 ]
wim *value not available*
tbr *value not available*
pc 0xff208114 0xff208114 <CRYPTO_ccm128_decrypt+532>
npc 0xff208118 0xff208118 <CRYPTO_ccm128_decrypt+536>
fsr 0x0 [ ]
csr *value not available*
So the addresses of ctx->cmac.u[0] (0x6cbe0) and scratch.u[0]
(0xffbfcdd0) are in registers l5 resp. l0.
Looking at disassembly around CRYPTO_ccm128_decrypt+532 (decimal 532 =
0x214):
CRYPTO_ccm128_decrypt+0x1d8: 12 40 00 0f bne,pn %icc, +0x3c
<CRYPTO_ccm128_decrypt+0x214>
CRYPTO_ccm128_decrypt+0x1dc: c2 2f 60 0b stb %g1, [%i5 + 0xb]
CRYPTO_ccm128_decrypt+0x1e0: c2 0f 60 0a ldub [%i5 + 0xa], %g1
CRYPTO_ccm128_decrypt+0x1e4: 82 00 60 01 add %g1, 0x1, %g1
CRYPTO_ccm128_decrypt+0x1e8: 80 88 60 ff btst 0xff, %g1
CRYPTO_ccm128_decrypt+0x1ec: 12 40 00 0a bne,pn %icc, +0x28
<CRYPTO_ccm128_decrypt+0x214>
CRYPTO_ccm128_decrypt+0x1f0: c2 2f 60 0a stb %g1, [%i5 + 0xa]
CRYPTO_ccm128_decrypt+0x1f4: c2 0f 60 09 ldub [%i5 + 0x9], %g1
CRYPTO_ccm128_decrypt+0x1f8: 82 00 60 01 add %g1, 0x1, %g1
CRYPTO_ccm128_decrypt+0x1fc: 80 88 60 ff btst 0xff, %g1
CRYPTO_ccm128_decrypt+0x200: 12 40 00 05 bne,pn %icc, +0x14
<CRYPTO_ccm128_decrypt+0x214>
CRYPTO_ccm128_decrypt+0x204: c2 2f 60 09 stb %g1, [%i5 + 0x9]
CRYPTO_ccm128_decrypt+0x208: c2 0f 60 08 ldub [%i5 + 0x8], %g1
CRYPTO_ccm128_decrypt+0x20c: 82 00 60 01 add %g1, 0x1, %g1
CRYPTO_ccm128_decrypt+0x210: c2 2f 60 08 stb %g1, [%i5 + 0x8]
CRYPTO_ccm128_decrypt+0x214: f4 1f 00 00 ldd [%i4], %i2
CRYPTO_ccm128_decrypt+0x218: b8 07 20 10 add %i4, 0x10, %i4
CRYPTO_ccm128_decrypt+0x21c: c4 1f bf f0 ldd [%fp - 0x10], %g2
CRYPTO_ccm128_decrypt+0x220: d8 1f 3f f8 ldd [%i4 - 0x8], %o4
CRYPTO_ccm128_decrypt+0x224: b0 1e 80 02 xor %i2, %g2, %i0
CRYPTO_ccm128_decrypt+0x228: b2 1e c0 03 xor %i3, %g3, %i1
CRYPTO_ccm128_decrypt+0x22c: c4 1f bf f8 ldd [%fp - 0x8], %g2
CRYPTO_ccm128_decrypt+0x230: f0 3f bf f0 std %i0, [%fp - 0x10]
CRYPTO_ccm128_decrypt+0x234: 84 1b 00 02 xor %o4, %g2, %g2
CRYPTO_ccm128_decrypt+0x238: 86 1b 40 03 xor %o5, %g3, %g3
CRYPTO_ccm128_decrypt+0x23c: d8 1f 60 10 ldd [%i5 + 0x10], %o4
CRYPTO_ccm128_decrypt+0x240: c4 3f bf f8 std %g2, [%fp - 0x8]
CRYPTO_ccm128_decrypt+0x244: b4 1b 00 18 xor %o4, %i0, %i2
CRYPTO_ccm128_decrypt+0x248: b6 1b 40 19 xor %o5, %i1, %i3
CRYPTO_ccm128_decrypt+0x24c: d8 1f 60 18 ldd [%i5 + 0x18], %o4
CRYPTO_ccm128_decrypt+0x250: f4 3f 60 10 std %i2, [%i5 + 0x10]
CRYPTO_ccm128_decrypt+0x254: b4 1b 00 02 xor %o4, %g2, %i2
CRYPTO_ccm128_decrypt+0x258: b6 1b 40 03 xor %o5, %g3, %i3
CRYPTO_ccm128_decrypt+0x25c: 40 04 c3 3a call +0x130ce8
<0x1b8e44>
If the 0x214 address is correct, then the statement would be:
CRYPTO_ccm128_decrypt+0x214: f4 1f 00 00 ldd [%i4], %i2
Content of %i4 is 0xffbfd091, which is an odd number, so probably not a
good address to load a double word from.
That's all I can see. I hope Adny has a better idea of what's happening
here.
If there is need, I can provide more data and test (debug) patches.
Thanks a bunch!
Rainer
More information about the openssl-dev
mailing list