[lkml]   [2008]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] Performance Counters for Linux, v4
    On Tue, 16 Dec 2008 14:03:02 +0100
    Ingo Molnar <> wrote:

    > > > - plus you have to forbid SMT CPUs as well. On HT a task could
    > > > co-schedule with your setuid task and observe its timing
    > > > characteristics via its _own_ behavior. (which is impacted by
    > > > whatever is running on another SMT/HT thread.)
    > >
    > > Yes, SMT is evil.
    > HT got added back to Nehalem, so SMT is coming to you in every future
    > x86 CPU. It brings a serious performance win, so nobody will turn off
    > SMT threading in practice. If SMT worries you, it needs explicit
    > partitioning of security-relevant processing to different physical
    > CPUs, via cgroups/cpusets/etc.

    and/or you use properly implemented crypto code (see Bruce Schneider's
    books). The timing "problem" isn't really SMT specific. If you have
    improperly implemented crypto (eg crypto code where the code paths and
    not just the data payload are key dependent) then on any system with
    more than one (logical) processor there is interference that an
    attacker can use.

    The only possible answer is to use proper implementation; turning off HT
    may make you feel good but you go from shoddy crypto for which there is
    some internet papers on how to crack it, to shoddy crypto for which the
    same papers apply ;)

    Arjan van de Ven Intel Open Source Technology Centre
    For development, discussion and tips for power savings,

     \ /
      Last update: 2008-12-16 14:17    [W:0.021 / U:15.668 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site