Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 17 Mar 2015 17:22:31 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] building JtR for MIC

On 2015-03-17 10:38, Lei Zhang wrote:
> I reran the benchmarks on MIC, with or without OpenMP, and got some statistics.
> 
> *With OpenMP:*
> The result is a bit different from last time. The program didn't get killed when 
> running /mschapv2-naive/, but aborted later when running /mysql/, with error 
> message: *****mem_alloc(): Cannot allocate memory trying to allocate 5190451200 
> bytes*****

Wow that's pretty heavy for a single allocation. Note the following
lines in mysql_fmt_plug.c:

#define OMP_SCALE			81920
(...)
#define MAX_KEYS_PER_CRYPT		8

This is your problem. You will ending up allocating 81920*8*240*33 bytes
for the plaintext buffer (btw the "33" is [PLAINTEXT_LENGTH + 1]).

So this OMP_SCALE is obviously not suitable for MIC. Try something like this

+ #ifdef __MIC__
+ #define OMP_SCALE			128
+ #else
   #define OMP_SCALE			81920
+ endif

Then you may tweak it by doubling it until it doesn't get faster (or
just gets silly high).

Nearly all OpenMP formats use this exact scheme so you can fix most
formats the same way. I'm pretty sure the NETLM* and NETNTLM* formats
are just as bad or worse.

magnum


Powered by blists - more mailing lists

Your e-mail address:

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