[PATCH] Statclock aliasing by LAPIC

[Bruce Evans]

On Fri, 15 Jan 2010, Attilio Rao wrote:

> I still see clock_lock in place (and no particular critical section
> code in that paths) or you meant to say that the clock_lock doesn't
> still provide enough protection alone?
> BTW, you were right about the lapic_timer_hz (I forgot to revert to
> hz). There is an updated patch:
> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/statclock_aliasing/statclock_aliasing4.diff

It seems to have the same fundamental bugs as the previous version.
The atrtc interrupt is too slow to use for anything, so it should never
be used if there is something better like the lapic timer available
(even the i8254 is better), and using it here doesn't even fix the
problem (malicious applications can very easily hide from statclock
by default since the default hz is much larger than the default stathz,
and malicious applications can not so easily hide from statclock irrespective
of the misconfiguration of hz, since statclock is not random).  See my
previous reply and ftp://ftp.ee.lbl.gov/papers/statclk-usenix93.ps.Z for
more details.

I checked that the simple exploit in that old paper is too simple to
exploit FreeBSD-~5.2 with SCHED_4BSD, hz = 100 and no lapic timer.
Under FreeBSD-8 with defaults (ref8-i386), it is too simple to exploit
even its own equal share of the cycles (it tries to hide from stathz
but assumes stathz = 100, and my simple attempts to improve this didn't
work, so it apparently loses due to misprediction -- a naive CPU hog
got about 20% more cycles than this simplistic hog).  I tested only
with 1 naive CPU hog and 2 simplistic hogs (from the fork) per CPU.

Bruce