[PATCH] Statclock aliasing by LAPIC

[Bruce Evans]

On Wed, 2 Dec 2009, Bruce Evans wrote:

> ...  However, the
> defaults with the lapic timer give an even larger beat frequency than
> before, so I don't see how using the lapic timer can increase the
> problem much.  (The beat frequency of (1000, 128) is 16000.  The beat
> frequency of (1000, 133) is 133000.  The latter means that, with
> defaults, statclock and hardclock() ticks are only perfectly synced
> once in every 133 seconds.  Misconfiguring hz to a multiple of 128 can
> give perfect synchronization, which may be a more of a problem, or a
> fix -- see below).

PS (the see below part): with perfect sync, statclock() ticks can be
kept perfectly out of phase, and this might work well.  E.g.:

(1) hz = 1000, stathz = 125, lapic_timer_hz = 2000: hz ticks on lapic
     ticks # 0, 2, 4, ...; stathz ticks on lapic ticks # 7, 15, 23, ...
     Malicious programs can still easily hide from statclock().

(2) hz = 100, stathz = 100, lapic_timer hz = 200: hz ticks on lapic
     ticks # 0, 2, 4, ...; stathz ticks on lapic ticks # 1, 3, 5, ...
     Malicious programs can easily predict statclock(), but can't
     easily use more than half of the CPU: e.g.,
     - run from hz tick N+epsilon to N+0.5-epsilon (seems to need frequent
       clock_gettime() calls to determine when to give up control;
       timeouts are no use since none can occur until tick N+1-epsilon)
     - usleep(1) and/or give up control to another process.  If the
       former only, then there can be no timeout until hz tick N+1-epsilon,
       and we can hog at most half the CPU.  If the latter, then we
       will need to find a different one quite often, else the victim
       processes will accumulate ticks instead of use and they will be
       de-scheduled instead of us.  fork() by us must not be cost-free,
       else we can generate cooperating victim processes too easily for
       this and other types of hogging.

With a randomized statclock(), the randomness would have to be quite
large and not just a small glitch on the increment like I said before,
else maliciousness like in (2) would work to the extent that the
non-glitch part is large.

Bruce