Re: [reSIProcate] Timer vulnerability

[Alan Hawrylyshen <alan@xxxxxxxxxx>]

On Apr 12, 2005, at 12.38, kenho@xxxxxxxxxxxxxx wrote:

> Alan,
>
> I presume the scenario you described is very real and is possible to 
> happen to QueryPerformanceCounter() and the likes, but GetTickCount()?
> Although I have verify this myself, MSDN library clearly states that 
> GetTickCount() returns the number of *milliseconds* that have elapsed 
> since the system was started (note that it also says on WinCE, it 
> excludes time suspended, but I failed to find similar statement 
> regarding other windows families).
>
> Ken
>
> Alan Hawrylyshen wrote:
>
> > One of the BIG problems with GetTickCount and families is that they 
> > no longer produce monotonically increasing results.
> > On devices with Intel SpeedStep technology (for example) or other 
> > power management technologies, the TickCount can move in very 
> > unpredictable ways. This results is wildly inaccurate timers. Care 
> > must be taken to select a replacement (if done) that does not make 
> > use of a fundamental that varies non-linearly.  On a plus side, we 
> > can get rid of any direct calls to time() since having a contained 
> > Time utility class is a Good Thing™.
> >
> > Alan
> >
> > a l a n a t j a s o m i d o t c o m

Ken;

I suspect that GetTickCount() may not suffer this exact problem, I just 
wanted to raise awareness of the problems we have seen in the past.  If 
GetTickCount is assured to be n-milliseconds since last restart, it may 
form a useful basis for the timer refactoring.  sysinfo() on linux may 
have a reasonable similar behaviour.  For solaris and other systems I'd 
recommend just implementing a layer over the gettimeofday() call like 
we already do. People can address this vulnerability as they see fit on 
those platforms.

Alan

a l a n a t j a s o m i d o t c o m