From owner-cvs-src@FreeBSD.ORG Fri May 20 22:02:52 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9605C16A4CE; Fri, 20 May 2005 22:02:52 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77EB243D6E; Fri, 20 May 2005 22:02:51 +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 j4KLwdPl073960; Fri, 20 May 2005 17:58:39 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j4KLwdwd073959; Fri, 20 May 2005 17:58:39 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 20 May 2005 17:58:39 -0400 From: David Schultz To: Nate Lawson Message-ID: <20050520215839.GA73890@VARK.MIT.EDU> Mail-Followup-To: Nate Lawson , Colin Percival , Jacques Vidrine , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <200505130001.j4D01KcE015393@repoman.freebsd.org> <20050514093203.GA81770@FreeBSD.org> <4285C73B.3040409@freebsd.org> <42864809.7020700@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42864809.7020700@root.org> cc: Jacques Vidrine cc: cvs-src@FreeBSD.ORG cc: src-committers@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG cc: Colin Percival Subject: Re: cvs commit: src/sys/amd64/amd64 mp_machdep.c src/sys/amd64/include cpufunc.h src/sys/i386/i386 mp_machdep.c src/sys/i386/include cpufunc.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 22:02:52 -0000 On Sat, May 14, 2005, Nate Lawson wrote: > Colin Percival wrote: > >I ended up putting hyperthreading_allowed under machdep rather than > >security > >because 4.x doesn't have a security sysctl node, but the name was chosen to > >emphasize that hyperthreading is currently something dangerous which should > >be permitted only under certain circumstances, rather than a feature which > >can be enabled or disabled however you like. > > > >Colin Percival > > That is at best, hyperbole. Crypto implementations which properly > implement blinding or operate in constant time are not vulnerable. > Disabling HTT only decreases the quality of measurement, requiring more > measurements. It does not prevent the attack. As you point out in your > paper (and in the D. Bernstein article you cited), there is no easy > solution and straightforward crypto implementations running on > general-purpose platforms will continue to be vulnerable until proper > blinding or constant time operations are implemented. FWIW, my initial reaction was similar; this problem can only be solved by eliminating key-dependent timing differences in applications. However, in the interest of paranoia, there seems to be some value in modifying the kernel to make side channel attacks more difficult. Many applications can leak sensitive information via timing channels even though they perform no cryptographic operations at all, and it's unreasonable to expect that we will be able to fix all of them. For instance, it has been shown that accurate keystroke timing information can reveal 5 to 6 bits of information about a user's keyboard input, e.g. a password or credit card number.[1] One might imagine that an HTT cache attack against a web browser could make such timing information available, whereas lower- bandwidth side channels would be infeasible. [1] http://www.usenix.org/events/sec01/song.html