From owner-freebsd-arch@FreeBSD.ORG Sat Jan 16 10:36:32 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F00A91065679; Sat, 16 Jan 2010 10:36:32 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 7CC158FC14; Sat, 16 Jan 2010 10:36:32 +0000 (UTC) Received: from c220-239-227-214.carlnfd1.nsw.optusnet.com.au (c220-239-227-214.carlnfd1.nsw.optusnet.com.au [220.239.227.214]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o0GAaSZ9021775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Jan 2010 21:36:30 +1100 Date: Sat, 16 Jan 2010 21:36:28 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Attilio Rao In-Reply-To: <3bbf2fe11001150706y765159a2jbd37c7ae4cf378f0@mail.gmail.com> Message-ID: <20100116205752.J64514@delplex.bde.org> References: <3bbf2fe10911271542h2b179874qa0d9a4a7224dcb2f@mail.gmail.com> <200911301305.30572.jhb@freebsd.org> <3bbf2fe11001150706y765159a2jbd37c7ae4cf378f0@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Arch , Ed Maste Subject: Re: [PATCH] Statclock aliasing by LAPIC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2010 10:36:33 -0000 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