Date: Fri, 20 May 2005 17:58:39 -0400 From: David Schultz <das@FreeBSD.ORG> To: Nate Lawson <nate@root.org> Cc: Colin Percival <cperciva@FreeBSD.ORG> 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 Message-ID: <20050520215839.GA73890@VARK.MIT.EDU> In-Reply-To: <42864809.7020700@root.org> References: <200505130001.j4D01KcE015393@repoman.freebsd.org> <20050514093203.GA81770@FreeBSD.org> <4285C73B.3040409@freebsd.org> <42864809.7020700@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050520215839.GA73890>