linux-kernel - Re: [RFC] Fast assurate clock readable from user space and NMI handler

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]

Message-ID: <20070227044724.GB17546@Krystal>
Date:	Mon, 26 Feb 2007 23:47:24 -0500
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Daniel Walker <dwalker@...sta.com>
Cc:	mbligh@...gle.com, linux-kernel@...r.kernel.org,
	johnstul@...ibm.com, mingo@...e.hu
Subject: Re: [RFC] Fast assurate clock readable from user space and NMI handler

* Daniel Walker (dwalker@...sta.com) wrote:
> On Mon, 2007-02-26 at 22:54 -0500, Mathieu Desnoyers wrote:
> > If an NMI nests over the spinlock, we have a deadlock.
> 
> Maybe not completely safe ...
> 
> > In addition, clock->cycle_last is a cycle_t, defined as a 64 bits on
> > x86. If is therefore not updated atomically by change_clocksource,
> > timekeeping_init, timekeeping_resume and update_wall_time. If an NMI
> > fires right on top of the update, especially around the 32 bits wrap
> > around, the time will be really fuzzy.
> 
> I'm not sure that is particularly significant considering that it's just
> a possible bad timestamp, and the probability of that happening seems
> rather low .. You could also modify NMI calls so they use a different
> time stamping method, like reading the clocksource directly .
> 

Since you do not disable interrupts around the clocksource read, the
same problem applies to interrupt handlers of higher priority than the
cycle_last updating code.

A bad timestamp can make a trace quite hard to follow and more
error-prone. When someone is looking for _the_ failing case in a system,
the infrastructure used to debug must be reliable. Sometimes error cases
takes days before showing up : we can't afford to be unsure about the
precision of the tracer.

Also, the goal is to have a generic monotonic timestamp readable from
everywhere. Excluding execution contexts doesn't seem like such a great
idea (it just replicates the same problem somewhere else).

> The pit clocksource could be dropped pretty easy with my clocksource
> update patches, which I'm still working on but you could easily drop
> clock sources that aren't atomic like the pit .. Also the pit is
> generally undesirable, so it's not going to be missed.
> 

Still important for old architectures where PIT is the only available
clock source I guess. However, the clocksource struct should at least 
tell if the time can be read atomically and offer a different API for
atomic vs non atomic read of time source, returning an error if no
atomic time source is available.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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/