[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 29 May 2015 18:40:49 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev <john-dev@...ts.openwall.com>
Subject: Re: Signal handling within john formats.
On Fri, May 29, 2015 at 2:05 PM, Solar Designer <solar@...nwall.com> wrote:
> Hi Sayantan,
>
> On Thu, May 28, 2015 at 03:23:27PM +0530, Sayantan Datta wrote:
> > On Wed, May 27, 2015 at 1:01 PM, Sayantan Datta <std2048@...il.com>
> wrote:
> > > I'd like to use signal handling functions - alarm() and sigaction()
> within
> > > a format.
>
> As you're probably aware, you should not.
>
> > > Howver using them disrupts status checking, even if I restore to
> > > the previous signal handler after I'm done using signals.
> > >
> > > The sequence of function calls within the format is as follows:
> > >
> > > sigaction(SIGALARM, &set_signal, &old_signal);
> > > alarm(x);
> > > .
> > > .
> > > .
> > > alarm(0);
> > > sigaction(SIGALARM, &old_signal, NULL);
> > >
> > >
> > > But the above sequence fails to restore normal JtR signal handling. So,
> > > what's missing?
>
> > Turns out restoring previous signal handler is not enough; alarm()
> function
> > interferes with setitimer() function. So, set setitimer() must also be
> > saved before using alarm() and then restored after calling alarm().
>
> How exactly setitimer() interacts with alarm() may vary across systems.
> You should not mix them. You may do what you need with setitimer()
> alone, but even then you still have a race condition between replacing
> the signal handler and replacing the timer settings (and ditto when
> restoring them). To avoid it, you may block/unblock the signal. Once
> finally implemented correctly, this should actually work... but it gets
> complicated.
It's not that I must go according to my plans use alarm() or setitimer(),
but just out of curiosity, I'd like to know why there is a race condition
between replacing the signal handler and replacing the timer settings. If
the process is single threaded, then how does the race condition arise.
> As an alternative, you could add support for registering
> of your additional handlers (or just one additional handler) to the
> global alarm handler in JtR. This would be JtR-specific, which is good
> in that it won't introduce dependency on extra features of the
> underlying system working correctly.
>
I don't understand! Till now, I only know that there could only be one
signal handler at any moment for every signal, in my case SIGALRM. So how
can I register additional handler for SIGALRM and how would the system know
which one to use ?
>
> Better yet, though, you'd avoid the need for this. Why exactly do you
> need it? Let's discuss the actual problem you're trying to solve first.
>
> Thanks,
>
> Alexander
>
This is a part of my experiment/learning exercise/tinkering scheme and it
may or may not make its way into jumbo. The problem is, I'm using a
randomized algorithm and sometimes it is profitable(performance wise) to
bail out and restart the algorithm with new set of parameters. When I see
there is not enough progress within a stipulated amount of time, I'd like
to bail out and restart. This is why I need alarm()/setitimer(). I need to
run the algorithm within fmt->restart() and within fmt->crypt_all() once in
a while(i.e after some hashes are cracked).
Regards,
Sayantan
Content of type "text/html" skipped
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.
