[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150428212839.GA12933@openwall.com>
Date: Wed, 29 Apr 2015 00:28:39 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [Johnny] Task 1.4.2 fork and OpenMP
Mathieu,
On Tue, Apr 28, 2015 at 04:40:35PM -0400, Mathieu Laprise wrote:
> Here is my daily progress.
Thank you! Please note that this does not eliminate the need to also
post weekly reports, as I requested here:
http://www.openwall.com/lists/john-dev/2015/04/28/7
Daily and weekly reports serve somewhat different purposes, so they can
co-exist well. What we expect under GSoC is weekly reports (what's done
and what's planned) and daily communication on the project.
> I added --fork to Johnny and played with John
> and Johnny to understand sessions, .rec files and johnny code better. The
> bug that I'm working on at the moment is : when we start the first attack,
> it's working with fork but when we pause/resume attack, the first .rec file
> is okay but all others from the other processes are locked. I guess ALL
> .rec files from the fork are important, right ?
Yes, all .rec files are important.
> Output :
>
> Crash recovery file is locked: /home/math07/.john/johnny/default.2.rec
>
> Crash recovery file is locked: /home/math07/.john/johnny/default.3.rec
>
> My hypothesis is that it is caused by the way Johnny kills John at the
> moment :
Most certainly yes.
> by terminating the process abruptly.
This could have been fine, depending on how exactly the abrupt
termination is done. The parent "john" does intercept some signals, and
would kill its children properly upon receipt of those.
> Locks on files might not be released for that reason.
It's not just locks on files. The locks being used are tied to the
processes still running. There's no way to have these locks and not
have the processes still running.
What this means is that you actually have a bigger yet simpler problem:
not all processes are killed. And no, this does not mean that Johnny
should kill all of them. Rather, it means that it should kill the
parent process in a way that would enable that process to terminate its
children.
> My plan is to send "q" or CTLR-C to john process via stdin
tty, not stdin.
While this could work, I think that (possibly except when using a GPU),
it's preferable to kill the parent "john" process with a signal. You
just need to do it right. SIGTERM should just work. What signal is
being used now?
As to my remark about "using a GPU", there was(?) an issue in AMD's
OpenCL library where e.g. Ctrl-C would result in unclean termination,
IIRC with an "assertion failed" somewhere in their code. "q" actually
avoids that. But perhaps we need another mechanism for Johnny, such as
another signal.
BTW, "q" was not supported in older versions, some of which might be
still in use. It's a relatively recent addition. So Johnny shouldn't
solely use "q" now. (Not to mention the hassle and portability issues
of allocating a pty.)
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.
