|
Message-ID: <20120717132841.GA29359@openwall.com> Date: Tue, 17 Jul 2012 17:28:41 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com 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) > */ > #ifdef ARCH_ALLOWS_UNALIGNED > #define DEFAULT_ALIGN MEM_ALIGN_NONE > #else > #define DEFAULT_ALIGN MEM_ALIGN_WORD > #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: #define DEFAULT_ALIGN MEM_ALIGN_WORD 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 expect. > 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*(). Alexander
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.