From owner-freebsd-arch@FreeBSD.ORG Tue Dec 1 16:32:00 2009 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 55FF8106566B; Tue, 1 Dec 2009 16:32:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id DB2838FC19; Tue, 1 Dec 2009 16:31:59 +0000 (UTC) Received: from c220-239-235-116.carlnfd3.nsw.optusnet.com.au (c220-239-235-116.carlnfd3.nsw.optusnet.com.au [220.239.235.116]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id nB1GVu9Z022984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 03:31:57 +1100 Date: Wed, 2 Dec 2009 03:31:56 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Bruce Evans In-Reply-To: <20091201233938.K1089@besplex.bde.org> Message-ID: <20091202025202.B22732@delplex.bde.org> References: <3bbf2fe10911271542h2b179874qa0d9a4a7224dcb2f@mail.gmail.com> <200911301305.30572.jhb@freebsd.org> <20091201233938.K1089@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , 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: Tue, 01 Dec 2009 16:32:00 -0000 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