Hi Bernhard! On Sun, 13 Dec 2020, Bernhard Übelacker wrote:
> 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. Can you try to rebuild tor with __attribute__((aligned(8))) for the keccak_state as suggested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977#44 and then let us know if the issue is still there? -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `- https://www.debian.org/
