lkml.org 
[lkml]   [2005]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Hyper-Threading Vulnerability
    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.

    There are three places to cut off the side channel, none of which is
    obviously the right one.
    1. The HT implementation could do the cache tricks Colin suggested in
    his paper. Fairly large performance hit to address a fairly small
    problem.
    2. The OS could do the scheduler tricks to avoid scheduling unfriendly
    threads on the same core. You're leaving a lot of the benefit of HT
    on the floor by doing so.
    3. Every security-sensitive app can be rigorously audited and re-written
    to avoid *ever* referencing memory with the address determined by
    private data.

    (3) is a complete non-starter. It's just not feasible to rewrite all
    that code. Furthermore, there's no way to know what code needs to be
    rewritten! (Until someone publishes an advisory, that is...)

    Hmm, I can't think of any reason that this technique wouldn't work to
    extract information from kernel secrets, as well...

    If SHA has plaintext-dependent memory references, Colin's technique
    would enable an adversary to extract the contents of the /dev/random
    pools. I don't *think* SHA does, based on a quick reading of
    lib/sha1.c, but someone with an actual clue should probably take a look.

    Andi, are you prepared to *require* that no code ever make a memory
    reference as a function of a secret? Because that's what you're
    suggesting the crypto people should do.

    -andy
    -
    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-13 23:39    [W:3.930 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site