From owner-freebsd-arch@FreeBSD.ORG Sun May 22 06:46:10 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 F004716A41C; Sun, 22 May 2005 06:46:10 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7814143D4C; Sun, 22 May 2005 06:46:10 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4M6k9kG011449; Sun, 22 May 2005 16:46:09 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j4M6k5qB010126; Sun, 22 May 2005 16:46:07 +1000 Date: Sun, 22 May 2005 16:46:07 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Colin Percival In-Reply-To: <428FFBB8.5010201@freebsd.org> Message-ID: <20050522163024.Q1381@epsplex.bde.org> References: <428FC00B.3080909@freebsd.org> <1116729865.1917.92.camel@palm> <428FFBB8.5010201@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-arch@freebsd.org" , Stephan Uphoff Subject: Re: Scheduler fixes for hyperthreading 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: Sun, 22 May 2005 06:46:11 -0000 On Sat, 21 May 2005, Colin Percival wrote: > Stephan Uphoff wrote: >> Would it be enough to disable access to RDTSC for user processes? Doing so would be a kernel bug. > 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. clock_gettime() with takes about 600 cycles if kern.timecounter.hardware=TSC. It should take fewer cycles, but syscalls are inefficient in FreeBSD. Does a factor of 6 make much difference to the attack? >> 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. Profiling (a form of benchmarking) should optionally be high resolution and high resolution profiling would use the TSC if it is available. Bruce