[PATCH] Statclock aliasing by LAPIC

Attilio Rao attilio at freebsd.org
Sat Jan 16 12:09:48 UTC 2010


2010/1/16 Bruce Evans <brde at 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/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.

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


-- 
Peace can only be achieved by understanding - A. Einstein


More information about the freebsd-arch mailing list