Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 17 Jul 2012 17:28:41 +0400
From: Solar Designer <>
Subject: Re: New core (?) LM fails alignment

On Sun, Jul 15, 2012 at 08:52:04PM +0200, magnum wrote:
> I'm using this in formats.h:
> /*
>  * Default alignment (used unless known)
>  */
> #else
> #endif
> Many formats will probably benefit from using 4 bytes alignment instead
> of MEM_ALIGN_NONE, should we consider using that instead?

I suggest that you use simply:


unconditionally, unless you are available to implement the heuristics
that I suggested before.

In the new self-test revision currently in CVS, misalignment of binary()
and salt() return values results in warnings being printed rather than
in the test failing.  So this should be acceptable for the period while
we revise formats to specify the alignment they actually provide and

> I set Tavis' binary alignment to MEM_ALIGN_SIMD

Jim mentioned that raw-sha1-ng was failing self-test in a certain build
for that reason.  Perhaps its binary() does not actually provide that
alignment (I did not check)?  We're currently specifying only one
alignment - the same for what binary() provides and what binary_hash*()
and cmp_*() expect.  So if the latter expect MEM_ALIGN_SIMD, then
binary() has to provide that.  For binary() vs. binary_hash*() this is
actually required in the loader.  For binary() vs. cmp_*(), this is not
strictly required, but the self-test currently assumes it.  So the
simplest fix is in those special cases to provide the alignment in
binary().  I think there are very few cases of cmp_*() having greater
alignment requirements than binary_hash*().


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.