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.