On Tue, 15 Dec 2020, George Kadianakis wrote: > Bernhard Übelacker <bernha...@mailbox.org> writes: > > > Dear Maintainer, > > I tried to collect some more information and compared this > > situation on real hardware armv5tel with an armv7 and > > it looks like in keccak_finalize the following instruction > > stores different data to memory depending on the arm hardware: > > > > 0x005c4ac0 <keccak_finalize+192>: f0 20 c4 e1 strd r2, [r4] > > > > In the failing case this is stored: > > (gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a > > 0xbeffef5c: 0x6f 0x6e 0x20 0x63 0x00 0x00 0x00 > > 0x00 > > > > And in the good case this: > > (gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a > > 0xbeffef5c: 0x2e 0x6f 0x6e 0x69 0x6f 0x6e 0x20 > > 0x63 > > > > While on both the registers r2 and r3 contain: > > r2 0x696e6f2e 1768845102 > > r3 0x63206e6f 1663069807 > > > > In the attached files are some more details leading to the above result. > > > > Woah Bernhard, that's some top-notch detective work! > > I wonder what this means? Does this mean that strd is broken on that > armv5tel, or that we are running gcc with the wrong flags for this > architecture?
Arnd Bergmann on #debian-arm points out that 113 setout8(const uint8_t *src, uint8_t *dst, size_t len) { 114 const uint64_t *si = (const uint64_t*)src; // Always aligned. line 114 of src/ext/keccak-tiny/keccak-tiny-unrolled.c has undefined behavior and that 0xbeffef5c is not actually aligned. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `- https://www.debian.org/