Date: Sat, 14 May 2005 11:48:41 -0700 From: Nate Lawson <nate@root.org> To: Colin Percival <cperciva@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 Message-ID: <42864809.7020700@root.org> In-Reply-To: <4285C73B.3040409@freebsd.org> References: <200505130001.j4D01KcE015393@repoman.freebsd.org> <20050514093203.GA81770@FreeBSD.org> <4285C73B.3040409@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42864809.7020700>