Date: Sat, 16 Jan 2010 21:36:28 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Attilio Rao <attilio@freebsd.org> Cc: FreeBSD Arch <arch@freebsd.org>, Ed Maste <emaste@freebsd.org> Subject: Re: [PATCH] Statclock aliasing by LAPIC Message-ID: <20100116205752.J64514@delplex.bde.org> In-Reply-To: <3bbf2fe11001150706y765159a2jbd37c7ae4cf378f0@mail.gmail.com> References: <3bbf2fe10911271542h2b179874qa0d9a4a7224dcb2f@mail.gmail.com> <200911301305.30572.jhb@freebsd.org> <3bbf2fe11001150706y765159a2jbd37c7ae4cf378f0@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100116205752.J64514>