From owner-freebsd-security@FreeBSD.ORG Fri May 13 16:11:01 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A315816A4CE for ; Fri, 13 May 2005 16:11:01 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 528B143D7D for ; Fri, 13 May 2005 16:11:01 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j4DG7EwE032923 for ; Fri, 13 May 2005 12:07:14 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j4DG7E9W032922 for freebsd-security@FreeBSD.ORG; Fri, 13 May 2005 12:07:14 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 13 May 2005 12:07:14 -0400 From: David Schultz To: freebsd-security@FreeBSD.ORG Message-ID: <20050513160714.GB32677@VARK.MIT.EDU> Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <200505131525.j4DFP1h7029320@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505131525.j4DFP1h7029320@freefall.freebsd.org> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 16:11:01 -0000 On Fri, May 13, 2005, FreeBSD Security Advisories wrote: > II. Problem Description > > When running on processors supporting Hyper-Threading Technology, it is > possible for a malicious thread to monitor the execution of another > thread. > > NOTE: Similar problems may exist in other simultaneous multithreading > implementations, or even some systems in the absence of simultaneous > multithreading. However, current research has only demonstrated this > flaw in Hyper-Threading Technology, where shared memory caches are used. But isn't this a well-known and fundamental problem with SMT? Someone at Sun pointed out a similar attack to me in 2003; it turns out that it's possible for a thread to monitor which of the processor's functional units another thread is using. For instance, you can sample the number of shifts vs. adds vs. multiplies and use this information to mount a differential timing attack. Also, recent work [1] shows that programs with key-dependent cache behavior can be attacked even without SMT. So this sounds like trying to solve in the OS a problem that can only be solved in the application. Is there something more subtle that's going on? P.S. I'm getting on a plane in a few hours, and I may be unable to respond for a few days. [1] http://cr.yp.to/antiforgery/cachetiming-20050414.pdf