From owner-cvs-all@FreeBSD.ORG Sat May 14 18:48:46 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B95316A4CE; Sat, 14 May 2005 18:48:46 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A84E43D73; Sat, 14 May 2005 18:48:45 +0000 (GMT) (envelope-from nate@root.org) Received: from pimout5-ext.prodigy.net (pimout5-ext.prodigy.net [207.115.63.73])j4EImo9Q001869; Sat, 14 May 2005 14:48:50 -0400 X-ORBL: [64.171.184.162] Received: from [10.0.0.115] (adsl-64-171-184-162.dsl.snfc21.pacbell.net [64.171.184.162])j4EImhFh207518; Sat, 14 May 2005 14:48:43 -0400 Message-ID: <42864809.7020700@root.org> Date: Sat, 14 May 2005 11:48:41 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050416) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Percival References: <200505130001.j4D01KcE015393@repoman.freebsd.org> <20050514093203.GA81770@FreeBSD.org> <4285C73B.3040409@freebsd.org> In-Reply-To: <4285C73B.3040409@freebsd.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: Jacques Vidrine cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/amd64/amd64 mp_machdep.csrc/sys/amd64/include cpufunc.h src/sys/i386/i386 mp_machdep.c src/sys/i386/include cpufunc.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 18:48:46 -0000 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. Additional references (not cited): "Remote timing attacks are practical"; D. Boneh and D. Brumley http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html "Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems"; P. Kocher http://citeseer.ist.psu.edu/kocher96timing.html -- Nate