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@entry=0xffbfcf5c, out=out@entry=0xffbfdfe8 "...", outl=outl@entry=0xffbfcf40, in=in@entry=0xffbfd091 "...", inl=inl@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 _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev