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.