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/
