On Mon, May 15, 2017 at 04:13:58PM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Mon, May 15, 2017 at 3:58 PM, Marc Stevens <m...@marc-stevens.nl> wrote: > > Hi Aevar, > > > > Thank you for notifying us of this issue. > > Big endianness is a tricky issue, also since I don't have access or > > accurate knowledge about all big endian systems. > > Our github repo does check correct functioning, including an endianness > > mistake, with 'make test'. > > But I guess this is not included for SHA1DC in Git. > > > > Anyway, we can easily add the _BIG_ENDIAN macrotest to the git repo and > > will do so soon. > > > > I don't think the segfault is caused by buffer overflow, inproper access, > > or the endianness issue. > > But I did notice an unexpected issue: the message block pointer m=0x398ad5 > > is odd. > > Can you confirm whether loading an uint32_t from an odd address triggers a > > hardware interrupt on your platform? > > This is not problem for x86, but maybe for your platform it is? > > If it is then we should always copy buffer contents to the sha1context to > > avoid this issue. > > I don't have access to the box in question, Michael was testing this > code for me. But unaligned access is probably the cause, although > according to some info I found online that should give a SIGBUS not a > SIGSEGV, but that may have changed: Yeah, I would have expected SIGBUS there. If we have alignment issues, though, I'd expect that ARM systems will experience problems. Block-sha1 uses a macro which allows unaligned loads on platforms that support it, and otherwise does the endian conversion on the fly as we load the bytes into a local variable (which presumably happens all in-register). That may be faster than doing a mass copy of the buffer. -Peff
