Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 8 Aug 2016 03:34:01 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: specify home ($JOHN) at compiletime

On Sun, Aug 07, 2016 at 08:15:21PM +0200, Matus UHLAR - fantomas wrote:
> On 04.08.16 13:51, Solar Designer wrote:
> >I think Debian overrides CFG_FULL_NAME because of their policy to have
> >all config files under /etc.  This policy is inconsistent with JtR's,
> >and vice versa, where JtR checks a set of directories for several of its
> >files, including the config file and more.  By overriding CFG_FULL_NAME
> >like above, if it worked, you'd break some desirable functionality -
> >namely, being able to override the system-wide config file at runtime by
> >placing a local one in ~/.john/john.conf.  Just how do Debian package
> >users make edits to their john.conf?  Edit the global file as root?
> 
> I thought this is what JOHN_SYSTEMWIDE is for - using CFG_FULL_NAME as
> system-wide config file and JOHN_PRIVATE_HOME/john.conf for users' config

You're right.  I think I misrecalled how CFG_FULL_NAME is used, and that
we also have and use a separate CFG_PRIVATE_FULL_NAME in system-wide
builds anyway.  So what Debian does might be OK, and we might need to
add that #ifndef, after all.

> I'd also like to configure non-omp fallbacks, just I'm not sure which
> fallback applies first (cpu or omp)

It should not matter which applies first.  All of the binaries
(including the fallback ones, except for the last resort binary, which
neither has OpenMP support nor requires any special CPU) will be able to
initiate fallbacks, so eventually you end up with the right binary
actually running.

That said, here are the fallbacks I observe on a Pentium 3:

$ OMP_NUM_THREADS=1 strace -e execve john > /dev/null
execve("/usr/bin/john", ["john"], [/* 33 vars */]) = 0
execve("/usr/libexec/john/john-omp-avx", ["john"], [/* 33 vars */]) = 0
execve("/usr/libexec/john/john-omp-sse2", ["john"], [/* 33 vars */]) = 0
execve("/usr/libexec/john/john-omp-mmx", ["john"], [/* 33 vars */]) = 0
execve("/usr/libexec/john/john-mmx", ["john"], [/* 33 vars */]) = 0

Here, "/usr/bin/john" has OpenMP and XOP.  It first fallbacks based on
the CPU type (lacking anything better than MMX here, so it stops at MMX)
and then based on needing to run only 1 thread (so it avoids OpenMP).

I think you can enable the OpenMP fallbacks without even enabling CPU
fallbacks.  This would also sidestep the (non-)issue.

> >I guess the exact escaping needed varies between Debian's invocation
> >from a script and your invocation from the command-line.
> 
> I'm afraid this applies for different variables at config time:

Of course.

My suggestion is that you don't override any of these pathnames at all.
Just let JtR use /usr/libexec/john and /usr/share/john.

If you insist, please see how the RPM spec file on Owl does it:

CPU_FALLBACK='\"john-omp-avx\"'
OMP_FALLBACK='\"john-xop\"'
%__make linux-x86-xop CFLAGS="%cflags -fopenmp -DCPU_FALLBACK=1 -DCPU_FALLBACK_BINARY='$CPU_FALLBACK' -DOMP_FALLBACK=1 -DOMP_FALLBACK_BINARY='$OMP_FALLBACK'"  OMPFLAGS=-fopenmp

This example is for fallback binary names, but the same should work for
other strings.

With autoconf, it'd be a little bit different, but perhaps the same
trick with setting and then using separate env vars for the pathnames
will work.

> >Hopefully, you have
> >at least tens of similar machines to make this exercise worthwhile.
> 
> in fact, yes... (even when talking about physical machines)

My advice is that you simply tar up the run directory.

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.