Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 24 Mar 2013 13:04:24 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: inlining strzncpy - and others?

On 24 Mar, 2013, at 12:20 , Solar Designer <solar@...nwall.com> wrote:
> On Sun, Mar 24, 2013 at 03:16:17AM +0100, magnum wrote:
>> I just replaced Dhiru's four identical instances of inlined _memmem() with a shared jtr_memmem() in misc.h (using a faster implementation while at it) and made it 'extern inlined' as per the portable model described in http://www.greenend.org.uk/rjk/tech/inline.html (i.e. with function source in misc.h instead of misc.c).
> 
> Now we have these warnings:
> 
> In file included from unafs.c:8:0:
> misc.h: In function 'jtr_memmem':
> misc.h:149:7: warning: implicit declaration of function 'memcmp' [-Wimplicit-function-declaration]

Oops, fixed. It did not show in OSX.

>> Do you have any opinions or wisdom on such inlining?
> 
> It might be the way to go, but so far I avoided it in part because we
> still try to support old C compilers that lack "inline".  (Maybe we
> should not.)  

We can tweak the current #if stack the same way but Jumbo contains "inline" in a lot of places anyway.


>> I tested this briefly with strnzpy. The john binary grews with about 20 KB. A benchmark of raw-sha0 (using strnzpy in set_key) shows a one percent boost. That's not a lot but with slight boosts also in the rule engine, cracking modes and other parts of John it will add up to more.
> 
> This may be a fine change to make, but regardless I think we should also
> review those uses of strnzcpy() where this matters, and try to optimize
> them.  In rules.c, there are such uses in just 3 commands: 'x', '1', and
> '2'.  Of these, maybe we only care about 'x' (since '1' and '2' are for
> single crack mode only, which rarely runs for long and usually has other
> bottlenecks anyway; there are also uses of strnz*() in single.c).  We
> may try the strncat() trick for 'x' (need to benchmark it on multiple
> systems/libc's).

I'll do some more testing. It looks like OSX' strncat is slower than the original strnzcpy, inlined or not :-/  Not that I care much about ultimate OSX performance.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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