From owner-freebsd-arch@FreeBSD.ORG Sun May 22 05:02:12 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 600AB16A41C; Sun, 22 May 2005 05:02:12 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9A5343D49; Sun, 22 May 2005 05:02:10 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from ppp2C32.dyn.pacific.net.au (ppp2C32.dyn.pacific.net.au [61.8.44.50])j4M5260m016178; Sun, 22 May 2005 15:02:07 +1000 From: Sam Lawrance To: Colin Percival In-Reply-To: <42900C01.10904@freebsd.org> References: <428FC00B.3080909@freebsd.org> <428FD710.4060200@freebsd.org> <9e8314b53980a379445cc8c07086901d@xcllnt.net> <428FE788.8020408@freebsd.org><42900C01.10904@freebsd.org> Content-Type: text/plain Date: Sun, 22 May 2005 15:02:50 +1000 Message-Id: <1116738170.867.28.camel@dirk.no.domain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org cc: Marcel Moolenaar Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 05:02:12 -0000 On Sat, 2005-05-21 at 21:35 -0700, Colin Percival wrote: > Marcel Moolenaar wrote: > > There are a lot of variables that need to be taken into account and > > those variables do not necessarily map perfectly from a P4 to an I2. > > Sharing of the L1 cache is not a sufficient condition to create a > > side-channel for timing attacks. A reliable time source with enough > > precision is also necessary (as you and Stephan have pointed out). > > The precision of the time source depends on latencies of the various > > cache levels and the micro-architectural behavior of the processor. > > Point taken. I maintain, however, that it is much better to make > "information can leak between these processors" a machine-independent > concept which is handled appropriately by the scheduler (with the > necessary machine-dependent code to specify *which* sets of processors, > if any, have such leakage). I'm just curious here... would the mac_seeotheruids policy help in obscuring the value of any information collected by a spy process?