Basically I just want to say "good analysis" and confirm that yes, everything points at compiler bug. I also don't sent this to rt, but to openssl-dev, in order to prevent case reopen.
> Looking at disassembly around CRYPTO_ccm128_decrypt+532 (decimal 532 = > 0x214): > > CRYPTO_ccm128_decrypt+0x214: f4 1f 00 00 ldd [%i4], %i2 > CRYPTO_ccm128_decrypt+0x218: b8 07 20 10 add %i4, 0x10, %i4 I want to point out instruction that follows the ldd. If %i4 was temp, then why would compiler have to increment it? Actually, if it was temp, which can only be stack-based, then compiler would address it through %fp, just like it addresses scratch in next instruction below. Also note that %i4 value is the same as inp in your stack backtrace presented in original message. Bottom line here is that compiler optimized away memcpy by assuming that input is aligned, despite the fact that it's declared char. That's compiler bug. > 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 If you still have 4.9.1 lying around, I wonder if it would help to declare temp as volatile? It's really just a wonder, so don't feel obligated to answer if you don't have time or energy. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev