Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Mar 2015 17:34:49 +0800
From: Lei Zhang <>
Subject: Re: [GSoC] building JtR for MIC


I’ve posted a pull request on GitHub with the changes I made and a new README file.

There’re two minor issues:
1. I made two patches which is used to build GMP and OpenSSL on MIC. I don’t know where to put them, and now I temporarily put them under john/src/unused. Maybe you have some better solutions.

2. There is a variable ‘OPENSSL_LIBS’ which is supposed to be bound to “-lssl -lcrypto” in the configure script. But when targeting MIC, it’s bound to an empty string, and those linker flags are not added into Makefile. I have to add them to LDFLAGS manually, like this:
	$ LDFLAGS=“-lssl -lcrypto” ./configure
I haven’t figure out how to resolve this yet.


> On Mar 12, 2015, at 1:56 AM, Solar Designer <> wrote:
> On Thu, Mar 12, 2015 at 12:41:15AM +0800, Lei Zhang wrote:
>> I'm finally able to build john-jumbo for MIC. It can run on MIC now, but still has some problem. I'll describe the building process first, and then how it runs.
> Great!
> Could you please post patches or make a pull request on GitHub
> corresponding to your changes to get jumbo to build and work on MIC?
>> When I started building, I found there're some libraries that are required by john-jumbo but not natively available on MIC. They are OpenSSL, GMP and Zlib. I had to download and build them for MIC manually, which also took me a while.
> I think we'll need to have this described in a README-MIC file or/and
> have it scripted.
> We may also distribute a tarball with jumbo and these libraries
> pre-built for MIC.
>> With all library dependencies resolved, there're still some source files that failed to compile.
> Please share with us your patches to get these to compile.
>> Will run 240 OpenMP threads
>> Benchmarking: descrypt, traditional crypt(3) [512/512]... (240xOMP) DONE
>> Many salts:	3744K c/s real, 30881 c/s virtual
> This is 20x+ slower than the performance I reported here:
> Your other benchmark results are also slower than they should be, but
> not by that much.
> Are you using this MIC card exclusively, or is it running some other
> code at the same time?
> You need to figure out this unexpected slowness.  It might be related to
> other issues you'd be running into, such as the one with scrypt:
>> Benchmarking: scrypt (16384, 8, 1) [Salsa20/8 32/64]... (240xOMP) Killed
>> -------------------------------------------------------------------------
>> It seems the process got killed when running ???scrypt???. I'm still looking for the cause of this problem. 
>> Suggestions are welcome.
> scrypt is special in that it needs much memory.  Our test vectors appear
> to require up to 16 MB.  For 240 threads, that's just below 4 GB.  Since
> your 5110P has 8 GB RAM, it should probably successfully run this test,
> but maybe much of its RAM is occupied by something else? e.g. some large
> files uploaded to its RAM filesystem, or someone using it concurrently?
> The "Killed" diagnostic is consistent with the out-of-memory theory.
> The MIC card's Linux kernel's OOM killer was likely triggered.
> 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.