From owner-freebsd-arch@FreeBSD.ORG Sat Jan 16 12:09:48 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 40D6D1065697; Sat, 16 Jan 2010 12:09:48 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 7899B8FC17; Sat, 16 Jan 2010 12:09:46 +0000 (UTC) Received: by fxm27 with SMTP id 27so907982fxm.3 for ; Sat, 16 Jan 2010 04:09:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=SdCB0Yyh65L5inMqZkNZ1eFChZ3OfQQn02UnA5vsGy4=; b=xlm7oCu0/qzL2FXNJnw5Z+AvftNIa/vdPjMtspn5pAfMGgkz/WWDn6M46qVwesPslj JppiV6w8PWpOdGYR0HwwBVTfXy+pdMdeFf+jAEWx4WPXdyEBCPIEjr5bmpZy0/jbx6Ld ocOt2KvMova6KeZIu4l+Sya1GLMmlETHwUtg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=tC/J4v9AjhGOXWv9IZR91f3qnmg6RA45eivrtzltaSfz6ALFcAp1IqTeVDzeOqCoSH Ito0rG33EVhIR9IwwaOXJZn8wXR1DACUUnV1Tynxc/ITvc+K5STn//Wu+Y0ayVxCazJa LMBitmeC1mJkGDDa+dvA4hQsZbSvpZXIqKb6Q= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.76.142 with SMTP id c14mr4020206fak.92.1263643778940; Sat, 16 Jan 2010 04:09:38 -0800 (PST) In-Reply-To: <20100116205752.J64514@delplex.bde.org> References: <3bbf2fe10911271542h2b179874qa0d9a4a7224dcb2f@mail.gmail.com> <200911301305.30572.jhb@freebsd.org> <3bbf2fe11001150706y765159a2jbd37c7ae4cf378f0@mail.gmail.com> <20100116205752.J64514@delplex.bde.org> Date: Sat, 16 Jan 2010 13:09:38 +0100 X-Google-Sender-Auth: 05ef76d70944c239 Message-ID: <3bbf2fe11001160409w1dfdbb9j36458c52d596c92a@mail.gmail.com> From: Attilio Rao To: Bruce Evans Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 12:09:48 -0000 2010/1/16 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/sta= tclock_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). =C2=A0See = my > previous reply and ftp://ftp.ee.lbl.gov/papers/statclk-usenix93.ps.Z for > more details. Well, the primary things I wanted to fix is not the hiding of malicious programs but the clock aliasing created when handling all the clocks by the same source. About the slowness -- I'm fine with whatever additional source to LAPIC we would eventually use thus would you feel better if i8254 is used replacing atrtc? Also note that atrtc is the default if LAPIC cannot be used. I don't understand why another source, even simpler (eg. i8254) would have been used in that specific case by the 'old' code. What I mean, then is: I see your points, I'm not arguing that at all, but the old code has other problems that gets fixed with this patch (having different sources make the whole system more flexible) while the new things it does introduce are secondarilly (but still: I'm fine with whatever second source is picked up for statclock, profclock) if you really see a concern wrt atrtc slowness. Attilio --=20 Peace can only be achieved by understanding - A. Einstein