[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 21 Jun 2007 23:26:26 +0200
From: "Frank Dittrich" <frank_dittrich@...mail.com>
To: john-users@...ts.openwall.com
Subject: Strange bug when testing --format=ssha
Hi all,
I patched john-1.7.2 with the latest jumbo patch version (1.7.2-all-7),
built and tested the linux-x86-mmx version on my core duo notebook,
and got a failed test:
Benchmarking: Netscape LDAP SSHA MMX [salted SHA1]... FAILED (get_hash[0])
Repeating the test, it succeded.
Then I discovered that the test fails or succeeds depending on
which of the two CPUs runs the test.
If I run two tests in parallel, one of them fails,
the other succeeds.
It doesn't matter whether I add the --format=ssha parameter or not,
it's just the Netscape LDAP SSHA MMX test that fails.
As long as I don't reboot, it's always the same CPU which causes
the test to fail.
(If I run just one session, I can find out which CPU runs the test
by checking the output of /proc/cpuinfo.
The CPU which is busy runs at 1667 MHz, the other at 1000 MHz.)
The test doesn't fail immediately.
It fails more or less in the middle of the total time
for a successful test:
>time ../run/john --test --format=ssha
Benchmarking: Netscape LDAP SSHA MMX [salted SHA1]... DONE
Many salts: 1501K c/s real, 1501K c/s virtual
Only one salt: 1112K c/s real, 1112K c/s virtual
real 0m10.012s
user 0m9.993s
sys 0m0.016s
vs.
>time ./john --test --format=ssha
Benchmarking: Netscape LDAP SSHA MMX [salted SHA1]... FAILED (get_hash[0])
real 0m5.005s
user 0m5.004s
sys 0m0.000s
Since john runs a benchmark for many salts and for a single salt,
I suspect the bug is triggered immediately after switching
the number of salts to test.
Some information about the hardware and software environment:
Genuine Intel(R) CPU T2300 @ 1.66GHz
opensuse 10.3 Alpha 4
>uname -srvmpio
Linux 2.6.21-8-default #1 SMP Fri May 11 11:31:08 UTC 2007 i686 i686 i386
GNU/Linux
>gcc --version
gcc (GCC) 4.1.3 20070430 (prerelease) (SUSE Linux)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Trying
>make clean
>make linux-x86-sse2
provided the same results (testing ssha fails on one of the CPUs),
but a generic version doesn't fail.
I tried to rule out hardware and (alpha!) tool chain errors,
that's why I repeated the tests on the same machine,
but booting from a Knoppix 5.20 DVD:
$ uname -srvmpio
Linux 2.6.19.5 #4 SMP PREEMPT Sat Mar 3 02:19:32 CET 2007 i686 GNU/Linux
$ gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I just built the x86-mmx version, and it reliably failed on one of
the CPUs.
Then I built the linux-x86-64 version on an Athlon 64 X2 machine.
This one didn't fail.
But running the linux-x86-mmx version built on my core duo machine,
exposed the bug as well.
This time, however, the test fails on both CPUs, if I run two
instances simultaneously.
If I just run one instance of john, it "randomly" fails or succeeds.
(On this box, it's harder to tell which of the CPUs is occupied,
because they can't be clocked down individually.)
Some information about the CPU and the kernel:
AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
>uname -srvmpio
Linux 2.6.21-8-default #1 SMP Fri May 11 11:31:08 UTC 2007 x86_64 x86_64
x86_64 GNU/Linux
(This is an opensuse 10.3 Alpha 4 system as well.)
>time ./john --test --format=ssha
Benchmarking: Netscape LDAP SSHA MMX [salted SHA1]... FAILED (get_hash[0])
real 0m5.013s
user 0m5.012s
sys 0m0.004s
Rebooting this AMD machine from the Knoppix 5.20 DVD and building
and running the linux-x86-mmx version triggered the bug at least
at on of the CPUs when running two instances in parallel,
and randomly when running a single instance.
I'd like to know if anybody else is able to reproduce the problem.
I tried to further track down the problem, and changed the test set:
These are the test cases in NSLDAPS_fmt.c:
{"{SSHA}ypkVeJKLzbXakEpuPYbn+YBnQvFmNmB+kQhmWQ==", "qVv3uQ45"},
{"{SSHA}cKFVqtf358j0FGpPsEIK1xh3T0mtDNV1kAaBNg==", "salles"},
{"{SSHA}WTT3B9Jjr8gOt0Q7WMs9/XvukyhTQj0Ns0jMKQ==", "Password9"},
Just keeping one of the three tests makes the bug disappear.
Removing just the 3rd test still triggers the bug on one of the CPUs.
Removing just the 1st or the 2nd test instead removes (hides)
the bug.
If I remove the 3rd test and switch the first two tests,
the bug disappears as well.
Any ideas what else I could test are welcome.
Regards,
Frank
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
--
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.
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.
