![]() | |||||||||||||
Messages in this thread |
On Fri, May 13, 2005 at 02:26:20PM -0700, Andy Isaacson wrote: > On Fri, May 13, 2005 at 09:05:49PM +0200, Andi Kleen wrote: > > On Fri, May 13, 2005 at 02:38:03PM -0400, Richard F. Rebel wrote: > > > Why? It's certainly reasonable to disable it for the time being and > > > even prudent to do so. > > > > No, i strongly disagree on that. The reasonable thing to do is > > to fix the crypto code which has this vulnerability, not break > > a useful performance enhancement for everybody else. > > Pardon me for saying so, but that's bullshit. You're asking the crypto > guys to give up a 5x performance gain (that's my wild guess) by giving > up all their data-dependent algorithms and contorting their code wildly, > to avoid a microarchitectural problem with Intel's HT implementation. And what you're doing is to ask all the non crypto guys to give up an useful optimization just to fix a problem in the crypto guy's code. The cache line information leak is just a information leak bug in the crypto code, not a general problem. There is much more non crypto code than crypto code around - you are proposing to screw the majority of codes to solve a relatively obscure problem of only a few functions, which seems like the totally wrong approach to me. BTW the crypto guys are always free to check for hyperthreading themselves and use different functions. However there is a catch there - the modern dual core processors which actually have separated L1 and L2 caches set these too to stay compatible with old code and license managers. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-05-15 11:49 [from the cache] ©2003-2008 | |||||||||||||