linux-kernel - Re: [PATCH] time/fs - file's time race with vgettimeofday

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 07 Jul 2010 09:20:38 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	eric.dumazet@...il.com, oleg@...hat.com
Subject: Re: [PATCH] time/fs - file's time race with vgettimeofday

On Wed, 2010-07-07 at 12:47 +0200, Jiri Olsa wrote:
> On Tue, Jul 06, 2010 at 04:11:40PM -0700, john stultz wrote:
> > [PATCH] x86: Fix vtime/file timestamp inconsistencies
> > 
> > Due to vtime calling vgettimeofday(), its possible that an application
> > could call  time();create("stuff",O_RDRW);  only to see the file's
> > creation timestamp to be before the value returned by time.
> > 
> > The proper fix is to make vtime use the same time value as
> > current_kernel_time() (which is exported via update_vsyscall) instead of
> > vgettime().
> 
> hm, this would be solution for the time() call.
> 
> But I think the issue still stays for gettimeofday and clock_gettime
> (CLOCK_REALTIME/CLOCK_MONOTONIC) because they call vread from
> clocksource to get the real time.
> 
> Thats where I'm not sure if this race is that "bad", compared either
> to performance hit or inaccuracy of user time calls.. which are possible
> solutions..

Right, so as long as the file timestamps are tick-granular (like other
tick-granular interfaces: current_kernel_time(), time(),
CLOCK_REALTIME_COARSE) you will have the possibility of inconsistencies
against the clocksource resolution interfaces (gettimeofday(),
CLOCK_REALTIME, etc).

But that is to be expected as a constraint of the granularity. So I
don't really see this as an issue.

Folks may want to increase the granularity of filesystem timestamps, but
that will come at the possibly very expensive cost of reading the
clocksource hardware (which can have different access latencies between
architectures and even machines of the same arch). I suspect its not
worth it.

The concerning issue here that you pointed out are the inconsistencies
could be seen between vsyscall time() and time() (or filesystem
timestamps). That is a problem, and my patch should resolve that one.

thanks
-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/