Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 26 May 2015 09:14:08 +0300
From: Solar Designer <solar@...nwall.com>
To: writeonce@...ipix.org
Cc: john-dev@...ts.openwall.com, Rich Felker <dalias@...c.org>
Subject: Re: update: JtR for Windows using musl libc

On Mon, May 25, 2015 at 10:19:17PM -0700, writeonce@...ipix.org wrote:
> I have now looked at x86-64.h and DES_bs.h and have added a few sysv_abi
> hints which did not change the outcome. My understanding is that someone
> familiar with JtR would have an easier time debugging this.

Yes, but we don't have your setup ready for debugging on.  And many of
us don't have Windows.

Can you try building for -avx?  The issue should be gone then (in that
build), as that disables use of the assembly code.

> As for performance: at some point I commented out the code in times(2)
> which converts NT measures (units of 100ns) to clock_t (1/100 sec)...
> the test was run natively on i3-2100 pc, and with the fixed __sys_times
> the numbers now finally seem correct. As an aside, an additional factor
> that might slow things down a bit (but nothing like *100000) is that the
> entire stack (libc, runtime library, john) is built with -g3 -O0.

Yes, the speeds look sane now, and clearly those with no assembly code
are impacted by -O0 a lot.

One thing that is still unclear to me is why you have a 2x gap between
real and virtual times.  It looks like the virtual times are doubled,
much like they would be when running 2 threads, but I think you are not
(the DES code in x86-64.S isn't even thread-safe).  So I am puzzled.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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