Date: Sat, 16 Jan 2010 13:09:38 +0100 From: Attilio Rao <attilio@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: FreeBSD Arch <arch@freebsd.org>, Ed Maste <emaste@freebsd.org> Subject: Re: [PATCH] Statclock aliasing by LAPIC Message-ID: <3bbf2fe11001160409w1dfdbb9j36458c52d596c92a@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
2010/1/16 Bruce Evans <brde@optusnet.com.au>: > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe11001160409w1dfdbb9j36458c52d596c92a>