Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 27 Oct 2013 22:50:46 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Compile john in Windows 64 bits

On 2012-03-16 23:41, Solar Designer wrote:
> 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):
(...)
> 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).

Solar,

I added ALIGN_FIX support in x86-64.S for Dhiru to try out (he has added 
a mingw64 target now and NT crashes). But I don't quite get how it's 
supposed to work:

#define DO_ALIGN(log)                  .align log; .space ALIGN_FIX

So if we get an unaligned address, 8 bytes space are added and we're 
set. But what if we happened to get an aligned address in the first 
place? Then we will *become* unaligned, no?

magnum

Powered by blists - more mailing lists

Your e-mail address:

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