From owner-freebsd-arch@FreeBSD.ORG Sun May 22 03:25:53 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 9B03E16A41C for ; Sun, 22 May 2005 03:25:53 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd2mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51D8743D53 for ; Sun, 22 May 2005 03:25:53 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd4mr5so.prod.shaw.ca (pd4mr5so-qfe3.prod.shaw.ca [10.0.141.50])2004))freebsd-arch@freebsd.org; Sat, 21 May 2005 21:25:52 -0600 (MDT) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd4mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGV00HJEG74HOG0@pd4mr5so.prod.shaw.ca> for freebsd-arch@freebsd.org; Sat, 21 May 2005 21:25:52 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IGV00L0OG730H@l-daemon> for freebsd-arch@freebsd.org; Sat, 21 May 2005 21:25:52 -0600 (MDT) Date: Sat, 21 May 2005 20:25:44 -0700 From: Colin Percival In-reply-to: <1116729865.1917.92.camel@palm> To: Stephan Uphoff Message-id: <428FFBB8.5010201@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.91.0.0 References: <428FC00B.3080909@freebsd.org> <1116729865.1917.92.camel@palm> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) 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 03:25:53 -0000 Stephan Uphoff wrote: > Would it be enough to disable access to RDTSC for user processes? On single-core systems (single socket, not dual-core), yes. Otherwise, no. > I believe the attack needs a very exact time source. It needs ~100 cycle resolution. If you have two processors, you can get good enough precision for the attack by constructing a "virtual TSC" by using a second thread which repeatedly increments a location in memory. > Beside benchmarking - is there any other real use for RDTSC ? Some (broken) software uses the TSC in combination with external events in order to obtain entropy for cryptographic key generation. As a result, disabling RDTSC could lead to non-obvious but very problematic breakage. > 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. If nobody wants to do this, then we could always just keep on telling our users "sorry, hyperthreading is broken on multi-user systems". I don't mind, personally -- I only have one system with a hyperthreaded cpu, and I have hyperthreading turned off for performance reasons. :-) Colin Percival