linux-kernel - Re: [patch 54/55] timekeeping: Provide fast and NMI safe access to CLOCK_MONOTONIC[

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:	Mon, 14 Jul 2014 11:45:58 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: [patch 54/55] timekeeping: Provide fast and NMI safe access to
 CLOCK_MONOTONIC[_RAW]

On Mon, Jul 14, 2014 at 11:04:39AM +0200, Thomas Gleixner wrote:
> On Mon, 14 Jul 2014, Peter Zijlstra wrote:
> > On Fri, Jul 11, 2014 at 01:45:19PM -0000, Thomas Gleixner wrote:
> > > Tracers want a correlated time between the kernel instrumentation and
> > > user space. We really do not want to export sched_clock() to user
> > > space, so we need to provide something sensible for this.
> > > 
> > > Using separate data structures with an non blocking sequence count
> > > based update mechanism allows us to do that. The data structure
> > > required for the readout has a sequence counter and two copies of the
> > > timekeeping data.
> > > 
> > > On the update side:
> > > 
> > >   tkf->seq++;
> > >   smp_wmb();
> > >   update(tkf->base[0], tk;
> > >   tkf->seq++;
> > >   smp_wmb();
> > >   update(tkf->base[1], tk;
> > > 
> > > On the reader side:
> > > 
> > >   do {
> > >      seq = tkf->seq;
> > >      smp_rmb();
> > >      idx = seq & 0x01;
> > >      now = now(tkf->base[idx]);
> > >      smp_rmb();
> > >   } while (seq != tkf->seq)
> > > 
> > > So if NMI hits the update of base[0] it will use base[1] which is
> > > still consistent. In case of CLOCK_MONOTONIC this can result in
> > > slightly wrong timestamps (a few nanoseconds) accross an update. Not a
> > > big issue for the intended use case.
> > 
> > But it breaks monotonicity, right? ;-)
> 
> It can in theory, but does it really matter for tracing?

Not so much; but I think the interfaces aren't quite as explicit as they
maybe should be about this.

> > Also, what happens when TSC is not available as a clocksource? There's
> > still a metric ton of hardware (including the latest generation HSW)
> > that has fucked firmware/TSC.
> 
> Well, bad luck then. You end up using hpet or worse, but it's still
> your decision whether to base your instrumentation on that or not. For
> sane clock sources (i.e. almost anything except TSC) it works
> perfectly fine.

So I can imagine clock sources themselves not being NMI safe on a
hardware level. But also, I'm fairly sure you do not want HPET reads in
a function tracer :-)

And I absolutely detest this configurability muck. I want a single
'clock'.

But yes, we can do what you suggested, we can do something like:

	if (tsc-stable)
		return nmi-mono
	else
		return sched_clock

Seeing how with tsc-unstable the sched_clock muck is synched to clock
monotonic.



Content of type "application/pgp-signature" skipped