[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120316224104.GA14033@openwall.com>
Date: Sat, 17 Mar 2012 02:41:04 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Compile john in Windows 64 bits
On Tue, Mar 13, 2012 at 07:44:31AM -0700, Alain Espinosa wrote:
> Compilation finishes fine and when execute:
> $ ../run/john.exe --test
> Benchmarking: Traditional DES [128/128 BS SSE2-16]...
> john crashed. A look at disassembly(image attached) show access in SSE
> code to a memory unaligned at 16 byte. Other formats works (testing in
> a Celeron 430 1.8GHz CPU, Win7 SP1 64 bits):
I did not realize this needed a comment from me until magnum mentioned
that apparently it did.
Unaligned accesses were a common problem on Windows - with Cygwin as
well - although it's been a while since I last heard of them (maybe
something was fixed in Cygwin lately).
We have ALIGN_FIX in some .S files for that, which may have to be
defined on some Windows builds. Apparently, a similar thing occurs with
Mingw-x64. x86-64.S lacks the ALIGN_FIX thing, so this needs to be
added and enabled (set to 8) when needed (that is, when a given build
crashes on self-test).
The screenshot appears to correspond to LM hash code, even though the
above says Traditional DES. On the screenshot, we see that k is in rdx,
*k is in rcx - and the latter turns out to be misaligned. This suggests
that the entire DES_bs_all is misaligned.
When not using the x86-64.S code yet building without OpenMP, DES_bs_all
is declared in DES_bs.c like this:
DES_bs_combined CC_CACHE_ALIGN DES_bs_all;
Whether this actually guarantees sufficient alignment (not only inside
the section, but also for the section itself) or not is once again
platform-specific.
With OpenMP-enabled builds, DES_bs_all is aligned by DES_bs_init():
DES_bs_all_p = mem_alloc_tiny(
++n * DES_bs_all_size, MEM_ALIGN_PAGE);
so the problem should not occur no matter what platform.
...Oh, it just occurred to me that the screenshot also shows that
DES_bs_all.B is correctly aligned. Now this is puzzling - why would
.B be aligned and .K not aligned? Or does *k somehow not point to a K[]
element? Things to check: addresses of DES_bs_all_K and DES_bs_all_B in
x86-64.o, whether rcx is within DES_bs_all_K or not, if not then why
not: initialization code in DES_bs_init(), sizeof(DES_bs_vector).
My current best guess: maybe the struct fields in x86-64.S do not match
those in DES_bs.h due to different/incorrect types used in C. I'd start
by checking sizeof(DES_bs_vector).
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.
