From owner-freebsd-arch@FreeBSD.ORG Sun May 22 02:44:27 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 E51B216A41C for ; Sun, 22 May 2005 02:44:27 +0000 (GMT) (envelope-from ups@tree.com) Received: from smtp.speedfactory.net (talon.speedfactory.net [66.23.216.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 814F843D53 for ; Sun, 22 May 2005 02:44:27 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 9498 invoked from network); 21 May 2005 22:44:47 +0000 Received: from 66-23-216-49.clients.speedfactory.net (HELO palm.tree.com) (66.23.216.49) by smtp.speedfactory.net with AES256-SHA encrypted SMTP; 21 May 2005 22:44:47 +0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j4M2iPpP001992; Sat, 21 May 2005 22:44:26 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Colin Percival In-Reply-To: <428FC00B.3080909@freebsd.org> References: <428FC00B.3080909@freebsd.org> Content-Type: text/plain Message-Id: <1116729865.1917.92.camel@palm> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 21 May 2005 22:44:25 -0400 Content-Transfer-Encoding: 7bit cc: "freebsd-arch@freebsd.org" 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 02:44:28 -0000 On Sat, 2005-05-21 at 19:11, Colin Percival wrote: > As you are probably all aware by now, HyperThreading has been > disabled on the stable and security branches due to a problem > with information leakage between threads which are scheduled > simultaneously on the two processor cores. Clearly, some people > (and at least one large company) are unhappy about us having > hyperthreading disbaled, so the security team would like to see > hyperthreading re-enabled by default as soon as we believe that > this can be done safely. > > The following must be done before hyperthreading is re-enabled: > > 1. The scheduler must be taught to not run threads on the same > processor core unless they p_candebug() each other. For reasons > of performance and locking, this is probably best accomplished by > only allowing threads to share a processor core if they belong > to the same process. > 2. When a thread is in the kernel, there must be a mechanism for > it to IPI its siblings and put them to sleep, and then wake them > up later. This would be used any time when a thread in the kernel > is about to handle sensitive data in a non-oblivious manner; IPsec > is a good example of where this would be necessary. > > Does anyone want to step forward to work on this? > > Colin Percival While I have been to your talk I have not read your paper yet and the following may be totally uninformed (Please be gentle :-) : Would it be enough to disable access to RDTSC for user processes? I believe the attack needs a very exact time source. Beside benchmarking - is there any other real use for RDTSC ? Is there any use of RDTSC that system requiring the security cannot live without? (We could even try to emulate the instruction if we really need to) I have to think more about possible scheduler changes. Currently we don't even know if a thread running on another virtual CPU is in the kernel or not. Throwing preemption, interrupt and kernel threads, pinned threads,priority inheritance and the IPIs in the mix make correct and efficient hyperthreading safe scheduling difficult. This also looks like a lot of work and I am wondering if it would not be better spend on other scheduler improvements. Stephan