Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 17 Jul 2012 09:29:06 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: New core (?) LM fails alignment

> On Tues, July 17, 2012 8:29 AM, Solar Designer wrote:
>On Sun, Jul 15, 2012 at 08:52:04PM +0200, magnum wrote:
>> 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*().

I think that 32 bit alignment requirement is what 'most' of the require
alignment bin_hash*() need.  I think most of the cmp_*() also require this,
or less. There likely ARE exceptions.

Tavis' binary() return alignment is 4 bytes (and array us u_int32's).  NOTE,
on my athon64 at home, that format cores. The alignment does not matter. I
used a static pointer, allocated to 16 byte alignment, and it still cores.
Old cygwin gcc.  I simply comment that format out, on that machine, within
the john.c.  This was the same gcc that when I tried to do this:

static union xx {
	uint32_t u32[SHA1_DIGEST_WORDS];
	__m128i junk;
} u;
uint32_t *result = u.u32;

also failed to align to 16 bytes (other GCC's aligned to 16 just fine, using
this construct).  For this compiler, I instead used 

static uint32_t *result = 0;
if (!result) result = mem_alloc_tiny(SHA1_DIGEST_WORDS*sizeof(uint32_t),
16);

This 'passed' the validation check for alignment, but still cores.  That is
where I simply gave up, and commented john.c on that machine.

As for alignment 16, I do not think it is needed, and likely will only gain
a percent or 2, when benchmarking, and not when running for real.  I think
align 4 is all that is needed.

Jim.

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ