[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20101127001041.GA4798@openwall.com>
Date: Sat, 27 Nov 2010 03:10:41 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: jumbo patch Makefile LDFLAGS modifications
On Thu, Nov 18, 2010 at 09:15:04PM +0100, Till Maas wrote:
> On Fri, Nov 12, 2010 at 04:18:56PM +0300, Solar Designer wrote:
> > http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/john/john.spec
>
> Ah, I did not know about this. I will update the SPEC to make use of
> this.
Thank you! Please let me know once you have an updated spec file for my
review, if you like.
> I will have to check with the Fedora Guidelines. The current optflags
> that are mandatory are these:
>
> x86_64:
> -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
>
>
> x86:
> -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom
> -fasynchronous-unwind-tables
It may be a good idea to add -momit-leaf-frame-pointer to both sets of
flags above, distribution-wide. This improves performance while not
breaking debugging, at least in our experience with Owl. You might want
to discuss this possible change with other Fedora folks.
As to JtR in particular, you could want to add -fomit-frame-pointer in
the spec file, and also consider removing -fstack-protector by spec file
means (e.g., invoke sed to do it).
For -fstack-protector, you could want to do benchmarks with/without this
option first. I'd be curious of your results. I think they may vary by
hash type and number of hashes/salts loaded. I'd expect faster hashes
to be affected the most, whereas slow ones to be almost unaffected by
-fstack-protector.
> What do you think about adding some code to john to allow having several
> binaries with several feature sets similar to the different binaries for
> different CPU optimizations with the fall-back mechanism. E.g. the john
> binary would have all patches and based on hash to be cracked and
> the amount of CPUs it uses the john-plain or john-up-jumbo binary. Then
> the user only needs to run john and there would not be any diversion
> between distributions, if other distributions provide patched versions,
> too.
I don't like doing this for clean vs. patched versions. The jumbo patch
purposefully makes more changes than just adding more hash types. Some
users will want to have those extra changes (e.g., buffering of wordlist
reads is currently only in jumbo), whereas some others will prefer the
stability of clean JtR. (It is true that many if not most will not
know/care, though...)
However, I am considering doing this for OpenMP-enabled builds when
invoked on a single-CPU system or when forced to use just one thread.
Such a build could reasonably fallback to a non-OpenMP build, which will
typically run faster.
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.
