Date: Wed, 2 Dec 2009 03:31:56 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Bruce Evans <brde@optusnet.com.au> Cc: Attilio Rao <attilio@freebsd.org>, FreeBSD Arch <arch@freebsd.org>, Ed Maste <emaste@freebsd.org> Subject: Re: [PATCH] Statclock aliasing by LAPIC Message-ID: <20091202025202.B22732@delplex.bde.org> In-Reply-To: <20091201233938.K1089@besplex.bde.org> References: <3bbf2fe10911271542h2b179874qa0d9a4a7224dcb2f@mail.gmail.com> <200911301305.30572.jhb@freebsd.org> <20091201233938.K1089@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091202025202.B22732>