[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 Mar 2013 13:50:23 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: clock err in timers (alarm, status ...) and fix
On Thu, Mar 14, 2013 at 09:15:27AM +0100, Costin Enache wrote:
> John uses for the alarm, status, save and probably other timers the
> sysconf(_SC_CLK_TCK) value, which, at least on Linux, is hard coded to a
> value of 100.
Actually, it varies by arch, and glibc obtains the value from the
AT_CLKTCK element in the auxiliary vector passed by the kernel on the
stack of the newly started program. (This avoids having to make a
syscall to find this value out from the kernel.) The hard-coded value
of 100 in glibc is only a fallback for the case that AT_CLKTCK is
somehow not present. On recent kernels, this fallback should not be
occurring.
Then, this value is not used by JtR as extensively as you seem to imply.
It is used to convert the values returned by times(2) to seconds.
I think this is correct. It is also used in a few other places
(relatively unimportant), but it is not used for setting up timer
intervals with the kernel. Instead, TIMER_INTERVAL (normally 1) is
passed directly into setitimer() via the tv_sec field.
> This means that the timers do not really work. On my system,
> an abort timer set at 10 sec will abort after approx. 8 seconds.
Hmm. Does your system somehow use HZ=125? What arch? What kernel
build? - a distro's or your custom (is the config custom too)? What
glibc version and build?
Does your build of JtR have OS_TIMER enabled?
Thanks,
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.
