linux-kernel - Re: gettimeofday() jumping into the future

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1f1b08da0804111611i39a8c4ddh9cda7dd68edac791@mail.gmail.com>
Date:	Fri, 11 Apr 2008 16:11:09 -0700
From:	"john stultz" <johnstul@...ibm.com>
To:	"James Courtier-Dutton" <James@...erbug.co.uk>
Cc:	"Andi Kleen" <andi@...stfloor.org>, "Tim Ricketts" <tr@...th.li>,
	"Michael Smith" <msmith@...h.org>, linux-kernel@...r.kernel.org,
	"Andy Wingo" <wingo@...endo.com>, tglx@...utronix.de,
	"Ingo Molnar" <mingo@...e.hu>
Subject: Re: gettimeofday() jumping into the future

On Thu, Apr 3, 2008 at 5:44 AM, James Courtier-Dutton
<James@...erbug.co.uk> wrote:
>  It should be:
>  treat cycle_now and cycle_last as unsigned.
>  unsigned tmp;
>  tmp = cycle_now - cycle_last;
>  if (tmp > max_difference_threshold) cycle_now = cycle_last;
>
>  This correctly handles cycle_now going backwards as well as wrap around.
>
>  The only way to catch all edge cases is to be able to make an assumption
>  on the maximum acceptable difference between cycle_now and cycle_last,
>  where difference is the shortest distance between values if they were
>  pointers into a ring buffer. The other assumption made here is that the
> wrap around only happens at max_uint of cycle_now.

Yea. I see Thomas' patch was applied then reverted as it caused
problems with the TSC reseting over suspend and resume (since the
timekeeping core doesn't have a hook into the tsc clocksource to
inform it that the comparision is invalid, so the resume-time read
will always return the cycle_last value and not the actual smaller TSC
value).

This suggested bounding of how much a negative value is considered
valid would resolve this issue, since really the scope of this fix is
very small negative offsets due to the TSC being ever so slightly out
of sync between processors (but not enough to warrent throwing the TSC
out as a valid clock source).

-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/