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.