Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 May 2015 05:53:21 +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

Hi,

On Mon, May 25, 2015 at 04:00:51PM -0700, writeonce@...ipix.org wrote:
> The midipix runtime layer is now being tested in preparation for its
> pre-alpha release, and JtR (john-1.8.0) has been very useful for testing
> times(2), setitimer(2), and signal delivery. To get an idea of where
> things currently stand, attached is the output of ./john --test along
> with the corresponding strace report.

Thanks!  I'm glad you've reached this milestone.

While are the reported speeds so low?  I guess you're running this under
a VM, but even then the speeds are surprisingly low.  Are timings
possibly way off?

> The profile used for building was linux-x86-64, which means that
> x86-64.S was compiled without any knowledge of the actual target or its
> ABI. I suspect this has something to do with the two failed tests, but
> haven't had time to identify the exact spot.

This is quite possible.  Maybe a difference in what registers are
supposed to be callee-saved?

It is interesting that descrypt and tripcode passed the test.  They use
very similar code in x86-64.S.  Specifically, they use DES_bs_crypt_25,
whereas bsdicrypt and LM use DES_bs_crypt and DES_bs_crypt_LM.  Maybe
DES_bs_crypt and DES_bs_crypt_LM clobber more registers, or maybe (more
likely?) the C code for descrypt and tripcode just didn't happen to
depend on the clobbered registers being preserved in this lucky build.

These are just some guesses, which might be right or wrong.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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