Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security Intel

Hyperthreading Considered Harmful 392

Posted by CowboyNeal from the not-just-for-performance dept.
cperciva writes "Hyper-Threading, as currently implemented on Intel Pentium Extreme Edition, Pentium 4, Mobile Pentium 4, and Xeon processors, suffers from a serious security flaw. This flaw permits local information disclosure, including allowing an unprivileged user to steal an RSA private key being used on the same machine. Administrators of multi-user systems are strongly advised to take action to disable Hyper-Threading immediately. I will be presenting this attack at BSDCan 2005 at 10:00 AM EDT on May 13th, and at the conclusion of my talk I will also releasing a paper describing the attack and possible mitigation strategies."
This discussion has been archived. No new comments can be posted.

Hyperthreading Considered Harmful More

Hyperthreading Considered Harmful

Comments Filter:

  • Sysadmins have been advised... (Score:4, Funny)

    by Anonymous Coward on Friday May 13, 2005 @08:08AM (#12518287)
    to give their hyper-threading processors some Ritalin.
    • the guy starts of with an Q&A even before he explains how it can be done, or what caused the flaw.

      question 4 in his list:

      Where do you work?

      I'm unemployed. For the past three months, I've spent almost all of my time working on this security flaw -- investigating how serious it was, contacting all of the affected vendors, explaining how this should be fixed, et cetera. I simply haven't had time to go out and get a job -- and I decided that making sure that this issue was properly reported and fixed

      • So he has gathered a few advisories (without details) and promises to release a whopping 12 page report after this ueber important conference?

        I am presenting details of how to exploit this security flaw at BSDCan 2005 in Ottawa on May 13th, 2005. Following my talk, I will be releasing a 12-page paper on this website discussing this flaw and related problems, both realized and theoretical.

        granted there is nothing wrong with this guys ability in marketing. As as techie this creates two reactions in me:

        1. Ge

        • Re:No details given... (Score:5, Insightful)

          by Ed Avis ( 5917 ) <ed@membled.com> on Friday May 13, 2005 @08:56AM (#12518608) Homepage
          I think he is giving the world some warning that the security hole exists and that after the conference exploits for it may appear in the wild (if they don't exist already). Vulnerabilities are sometimes announced this way: for example the OpenSSH team issued a mysterious warning saying that everyone running sshd should turn on privilege separation. A little while later they disclosed an exploit in the current sshd and made a new release with a fix. It happened that if you had privsep turned on you weren't affected by the exploit. The warning gave most admins a chance to secure their systems, but didn't give any details of the exploit.

          Now, you might not think this guy is credible and so wait for him to 'show you the code' before applying the suggested fix. That's up to you.

          • Details now given. (Score:4, Informative)

            by BrakesForElves ( 806095 ) * on Friday May 13, 2005 @03:10PM (#12522797) Homepage
            Well, I just read the paper [daemonology.net], and I applaud Colin on several levels. First off, the theory of the attack is rock-solid and well-written. Secondly, he describes very implementable OS work-arounds, crypto library fixes, and finally chip design corrections which will totally eliminate the security hole.

            This is one of the best thought out, best written papers of its kind that I have read in my over thirty years of work in the engineering field.

      • Re:It is just an 'give me a job' attention grab (Score:5, Insightful)

        by Intrigued ( 757997 ) on Friday May 13, 2005 @08:44AM (#12518522)
        I don't see that.

        If he can produce even a moderately effective proof-of-concept exploit (which apparently he has), someone with a little malicious creativity will find out a way to abuse it.

        Also as a security professional, any gap, niche or irregularity in core security processes needs to be taken seriously even if nothing ever pans out in a real exploit.

        As far as the attention grab, I don't begrudge the guy at all. If the exploit is bogus, he will have advertised to the world "I'm an idiot - don't hire me!". If it is valid, he has shown his worth and deserves some support.

      • On the other hand (Score:4, Informative)

        by MountainMan101 ( 714389 ) on Friday May 13, 2005 @08:59AM (#12518649)
        I'd be willing to bet he's right. He is currently awaiting a doctorate from the University of Oxford, which is commonly held as the finest academic institution in the world.

        (I'm not biased by having spent the past 7 years there)

  • This ought to be interesting (Score:5, Interesting)

    by displague ( 4438 ) <slashdot@@@displague...com> on Friday May 13, 2005 @08:09AM (#12518300) Homepage Journal
    Doesn't Linux handle HT the same way it handles SMP? So even if there was a hole in HT, hardware-wise, software wise you would be just as protected as you would be on an SMP system?
    • We will have to wait to see if this security flaw affects the linux kernel. BSD and BSD related kernels are affected for sure. See below taken from the link.

      FreeBSD: This issue affects FreeBSD/i386 and FreeBSD/amd64, and is addressed in advisory FreeBSD-SA-05:09.htt.

      NetBSD: The NetBSD Security-Officer Team believes that workarounds will be suitable for the majority of our users. Since this issue is a complex one, the 'right' solution will require a larger discussion which is only possible once this issu

    • Re:This ought to be interesting (Score:4, Interesting)

      by cahiha ( 873942 ) on Friday May 13, 2005 @08:21AM (#12518390)
      Well, I didn't see an explanation on the site... here is my guess what happened.

      With HT, registers for multiple threads have to reside within the same CPU, whereas with SMP, they are physically in two different chips. Perhaps the registers used by HT are not properly protected against reading by other threads. The fact that SMP code was probably reused may be the cause of the problem: the code developed for SMP didn't have to deal with this situation before.

      Guessing even a bit more, this may be hard to fix in software. If the hardware simply doesn't protect registers properly, then the kernel may have to clobber them to protect the information, but that may impose far too much overhead for HT.

      However, a workaround might be to permit HT only for multiple threads within the same process. That would still give some speedups to compute-intensive processes that are written to take advantage of threading.
      • Limiting hyperthreading to single processes is a good idea anyway. Since the multiple threading units share the same cache, you'll get better cache coherency by doing this.
        • It might seem like a good thing, but in reality hyperthreading is marketed primarily towards average desktop users. Their apps are by and large single threaded.
        • Here is another possibility:

          Quad-threading.

          This way, the spy/trojan threads would not be able to presume anything about what else is being executed along with them unless they happened to be the only other running processes.

          Of course, quad-threading on a P4 would be futile given that it has only a three-ways instruction decoder and integer execution units. If Intel replaced the AGUs by one extra complex ALU and two additional simple ALUs, quad-threading would become practical... though the six-ways instr

      • Re:This ought to be interesting (Score:5, Informative)

        by Drakonian ( 518722 ) on Friday May 13, 2005 @11:21AM (#12520064) Homepage
        I just watched his talk, and you are on the right track. Your workaround is one he suggested too. It's actually a timing based attack based on watching the cache misses in a spy thread to try and reverse the RSA public key. The interesting thing is this isn't Hyper-Threading only - it's possible on normal procs too that don't flush the cache between context switches. It's just that with HT context switches can be far more common.
      • Damn, Sam!

        It sure sounds like this guy is on the up-and-up. When the full details are disclosed, I may (just maybe) forced to buy a new Intel system with HT -- imagine the possibilities!

        Got some problem with pesky DRM? No problem! Run that nefarious application on the Intel HT box, and walk away with the keys. Sweet!

        (Just need to make sure that that MSFT "Palladium" crap is turned off in the BIOS first, right?)

    • Re:This ought to be interesting (Score:5, Interesting)

      by uss_valiant ( 760602 ) on Friday May 13, 2005 @08:22AM (#12518399) Homepage
      Doesn't Linux handle HT the same way it handles SMP? So even if there was a hole in HT, hardware-wise, software wise you would be just as protected as you would be on an SMP system?
      If you follow the article link you see that it only mentions *BSD and SCO unix variants. Not a word about linux or windows or any other x86 based OS.
      I guess we will have to wait for his final paper which should be available in +12 hours or something like that.
      Seems like he spent considerable time on this issue and he is unemployed. If you read his website, you probably come also to the conclusion that he sees this as an opportunity to get paid for his volunteer work. This /. announcement for his paper that will be available in a few hours can be seen as a great advertisement for his own work (no offence).

      He could also have contacted AMD to get a little funding as they didn't jump on the HT train :)

    • Re:This ought to be interesting (Score:4, Informative)

      by Chris Snook ( 872473 ) on Friday May 13, 2005 @08:34AM (#12518461)
      Unlike SMP, with HT you're interleaving two threads on the same physical execution unit. That means that there is data from another thread in registers at the same time that you're executing, without having enough instructions execute during a context switch to flush the pipeline. It also means that the other process's page table is in the MMU while you're executing. Even if their proof-of-concept attack doesn't work on some other operating systems, everyone needs to look over their code to make sure this isn't just an accidental effect that could change with increasing pipeline depths, different context switch logic, etc.

  • Whoosh!!! (Score:4, Funny)

    by EmagGeek ( 574360 ) on Friday May 13, 2005 @08:10AM (#12518301) Journal
    Shit, did anyone see that blur???

    Yeah, I think that was Intel's server market going right out the window at Mach 10...

    • Re:Whoosh!!! (Score:4, Insightful)

      by paulhar ( 652995 ) on Friday May 13, 2005 @08:12AM (#12518318)
      Somehow I doubt it. If every time a securty issue was found with a product people binned it then we wouldn't be running Linux, Windows, Firefox, IE, WiFI, etc...

    • Actually, I think it was the article flying overhead.
    • I doubt it:

      "This flaw permits local information disclosure, including allowing an unprivileged user to steal an RSA private key being used on the same machine. Administrators of multi-user systems are strongly advised to take action to disable Hyper-Threading immediately."

      1. Most servers aren't multiuser (in the sense he's apparently talking about).

      2. The workaround (of disabling HT) is trivial and won't have a significant impact for the majority of environment (proportionally very few servers are C

  • Quick fix (Score:5, Funny)

    by Junior J. Junior III ( 192702 ) on Friday May 13, 2005 @08:11AM (#12518312) Homepage
    I am counteracting the harmful effects of hyperthreading by eating a high-fiber diet. So far, I haven't had any problems.

  • Think! (Score:4, Insightful)

    by dybdahl ( 80720 ) <infoNO@SPAMdybdahl.dk> on Friday May 13, 2005 @08:13AM (#12518324) Homepage Journal
    Not all multi-user systems are designed to be secure against the best hackers around, and there is often bad cost/benefit at following all security recommendations as soon as you hear about them.

    Give us some more facts, so that we can think for ourselves.
    • More importantly, there are few multiuser systems around where this would matter much anymore. An exploit of this requires being able to execute arbitrary code on the machine handling the data. Almost anything that handles sensitive data is firewalled and allows only admin logins and specific services.
    • I wouldn't be as worried about the best hackers in the world hitting my box as the best hackers in the world writing an app that every script kiddie in the world could use to attack my box.
    • The point is that most servers system don't allow you to execute system calls which you could exploit.

      You need at least root/administrator privileges to get stuff from the OS memory.

      So before you can exploit the system you must have access to the system it self.

      It is an "local" kind of "root exploit" if you can read from the system memory of other processes if the claim is true.
  • Too bad there aren't any details, only an announcement for... tomorrow. I'd like to know how inherent this issue is in the CPU and to which extent the OS can be made to protect against it. Also, assuming he contacted Intel about it.. are they working on it?

    I do have to say it's commendable that he spent 3 months on this for free. Now that's commitment :-)

    • Re:Not many details (Score:3, Interesting)

      by cnettel ( 836611 )
      Speculation would say that it's quite hard to fix in the OS. If this is some kind of general flaw allowing access to all memory the another thread is allowed to access, one would basically have to make sure that the other virtual CPU is idle before entering ring 0 at any system call. That, in turn, could maybe be accomplished by sending an interrupt somehow to the other CPU, but a system call is supposed to be cheap.

      What Intel might hope for is that this is fixable in microcode. If not, well, then there's

      • one would basically have to make sure that the other virtual CPU is idle before entering ring 0 at any system call

        Probably not. For example, under UNIX, the bug changes nothing for two threads within the same program, or for two threads under the same uids. On systems with messy and unnecessarily complex privilege systems (like Windows), all bets are off, however.

        What Intel might hope for is that this is fixable in microcode. If not, well, then there's real trouble.

        If people care about HT at all...

  • Where's the details? (Score:4, Insightful)

    by tulimulta ( 769091 ) on Friday May 13, 2005 @08:14AM (#12518334)
    Not much to read yet. Seems more like a publicity stunt by the author. This could have been posted *after* the details have been published.

    • Re:Where's the details? (Score:5, Funny)

      by Anthony ( 4077 ) * on Friday May 13, 2005 @08:17AM (#12518355) Homepage Journal
      Maybe there are still unsold tickets for BSDCan05.
    • Apparently, he's also known about it for 6-7 months, which also make it smell of BS. 'Discoveries' worked on in secret for that amount of time almost always turn out to be a load of shit.

      However, we will see.
      • I just saw the talk. Have you considered that he TOLD Intel about it months ago but they wouldn't listen/didn't care? It's not easy to get the ear of a big company when you have discovered a major flaw in their product.

  • How to exploit (Score:4, Interesting)

    by jabagi ( 83535 ) <jabagi...kok@@@sf...sbs...com.tr> on Friday May 13, 2005 @08:14AM (#12518339)
    I'm curious to see how an exploit can be made out of this. Is it possible to assign one of the virtual CPUs to a "sniffer" for a prolonged period?

    • Re:How to exploit (Score:5, Informative)

      by mikael ( 484 ) on Friday May 13, 2005 @09:01AM (#12518670)
      The Ars Technica page on hyperthreading with the Xeon [arstechnica.com] might provide some clues. It lists which parts of the CPU are replicated, partitioned and shared.

      One final bit of information that should be included in a discussion of partitioned resources is the fact that when the Xeon is executing only one thread, all of its partitioned resources can be combined so that the single thread can use them for maximum performance. When the Xeon is operating in single-threaded mode, the dynamically partitioned queues stop enforcing any limits on the number of entries that can belong to one thread, and the statically partitioned queues stop enforcing their boundaries as well.

      ...

      The same can be said for the register file, another crucial shared resource. The Xeon's 128 microarchitectural general purpose registers (GPRs) and 128 microarchitectural floating-point registers (FPRs) have no idea that the data they're holding belongs to more than one thread--it's all just data to them, and they, like the execution units, remain unchanged from previous iterations of the Xeon core.

      For a simultaneously multithreaded processor, the cache coherency problems associated with SMP all but disappear. Both logical processors on an SMT system share the same caches as well as the data in those caches. So if a thread from logical processor 0 wants to read some data that's cached by logical processor 1, it can grab that data directly from the cache without having to snoop another cache located some distance away in order to ensure that it has the most current copy.

      ...

      You might think since the Xeon's two logical processors share a single cache, this means that the cache size is effectively halved for each logical processor. If you thought this, though, you'd be wrong: it's both much better and much worse. Let me explain.

      Each of the Xeon's caches--the trace cache, L1, L2, and L3--is SMT-unaware, and each treats all loads and stores the same regardless of which logical processor issued the request. So none of the caches know the difference between one logical processor and another, or between code from one thread or another.

  • more info at KernelTrap (Score:5, Informative)

    by Anonymous Coward on Friday May 13, 2005 @08:15AM (#12518340)
    I read about this last night here at KernelTrap [kerneltrap.org]. They offer more info, evidently having talked to Colin...
    • From the article:

      "The flaw affects all operating systems, and for a secure multi-user environment essentially requires that Hyper-Threading be disabled." /speculation mode on
      Seems that this is pretty big. Since I cannot see the direct link between multi-user and hyperthreading, I must assume that processes may be able to read data from other processes. Let's hope they cannot change the data as well. I think it's pretty weird that he mentions RSA specifically, maybe thats a hint which part of the processor

  • This is SERIOUS!!! (Score:4, Funny)

    by AltGrendel ( 175092 ) <(su.0tixe) (ta) (todhsals-ga)> on Friday May 13, 2005 @08:17AM (#12518353) Homepage
    SCO: This affects OpenServer 5.0.7 if an update pack is applied and SMP is installed; it also affects UnixWare 7.1.4 and 7.1.3 with hyperthreading enabled, but hyperthreading is disabled in UnixWare by default. This is covered by advisory SCOSA-2005.24.

    Ooooo, I'm SCARED!

  • hmm.. (Score:2, Funny)

    by ebilhoax ( 609649 )
    I will be presenting this attack at BSDCan 2005 at 10:00 AM EDT on May [Friday] 13th ...

    Jason? Is that you? (or your evil geeky twin brother?)

  • Simple Solution (Score:4, Insightful)

    by JerkyBoy ( 455854 ) on Friday May 13, 2005 @08:18AM (#12518364) Homepage Journal
    Recompile your kernel with hyper-threading disabled. Simple question: Why do I have to wait until this guy does his conference presentation to find out what the exploit is, how it is implemented? I have to admit that this is one time when RTFA didn't work. Anyone have any more information?
  • is it a problem with the kernels use of it , that artical is rather vauge on the details. I have a xeon server running linux and will consider disabling the use of hyper threading for now ,but i cant justify doing that on the long term till more info is at hand.
    if anyone has any more info on this i would be glad to hear it .

  • May I be first to say... (Score:3, Funny)

    by game kid ( 805301 ) on Friday May 13, 2005 @08:20AM (#12518376) Homepage
    ...I'm glad I'm stuck with a 1-gig Pentium III.

    • [humor]
      What is this x86 hyperthreading that you speak of fearing? My venerable (read:ancient) 64-bit Sparc II scoffs at your toy x86. Ofcourse, the aforementioned Sparc is only 1/2 the speed of your P3, but it stills scoffs.
      [/humor]

      Seriously, the SPARC architecture is an open specification that, unfortunately, does not get enough respect. It has been 64-bit since almost forever, something that is only now becoming common in the x86 world. I noticed that the flaws were noted on SCO-ware running on x86.
  • On MTS (IBM mainframe OS used at universities in the 70's/80's and probably into the 90's) there was a bug where when process switching, the FP registers of the last process to run were stored in a world-readable page of memory. The RPI ACM used this to create an inter-process communication program -- actually a 'chat' program (MTS had no inter-process communication other than files at the time).

  • Extreme Edition... (Score:5, Funny)

    by Sialagogue ( 246874 ) <sialagogue@gmail . c om> on Friday May 13, 2005 @08:22AM (#12518393)

    With Moore's Law still holding up, isn't it a little early to be using up names like "Extreme Edition?" So, I'd like to propose my own corollary to Moore's Law:

    "The microprocessor industry will run out of hyperbole long before they run out of transistors."

  • Google Adbar (Score:3, Funny)

    by bLanark ( 123342 ) * on Friday May 13, 2005 @08:29AM (#12518432)
    Did anyone else notice the Intel advert for "Hyper Threading Linux" at the top of the google ads on the article page?

    I wonder how much revenue he'll get from this announcement?

    And I note that if you are a SCO user, you always had disabled hyper threading anyway. Not sure what to make of that.

    • Re:Google Adbar (Score:3, Interesting)

      by cperciva ( 102828 )
      Did anyone else notice the Intel advert for "Hyper Threading Linux" at the top of the google ads on the article page?

      I put adsense onto most pages on daemonology.net, just because I can't see any reason not to (given that the ads are reasonably inobtrusive).

      This particular time, however, I had a very specific reason for putting them on: I wasn't sure if my server would be able to handle the load, and this way if there is too much traffic then I might be able to afford to get another server.

      I wonder how

  • Oh dear. (Score:5, Funny)

    by Morky ( 577776 ) on Friday May 13, 2005 @08:29AM (#12518434)
    I guess I need to shut off hyperthreading on our app server before the users who can't sort an Excel spreadsheet have a chance to expliot the vulnerability.

  • Uhoh.. (Score:2)

    by ceeam ( 39911 )
    If true that should eclipse for good the DivBug of lore. Can't wait for exploits to appear. But then - brainwashed people buying PIV Intels will get whatever they deserve. [grin]

  • Probably a Timing-Based Attack (Score:5, Interesting)

    by Sunlighter ( 177996 ) on Friday May 13, 2005 @08:32AM (#12518449)

    My guess is that this is a timing attack. While thread 1 generates an RSA key, thread 2 times itself performing various instructions. If thread 1 is using the FPU to do a multiply, the FPU won't be available for thread 2 right away, so there will be a measurable delay. Thread 2 can then determine when thread 1 is running multiplies.

    If my hunch is correct, an OS could fix this by allowing a process to enter a "secure mode" which would force the other thread on the same CPU to be idle when that process was scheduled.

    • This is most likely the case, that it is a timing attack. In an OOO design one can gain a lot of information about which instructions schedule in what order based on the availability of different execution units. An early-out divider is especially vulnerable to leak data about input arguments in timing effects. I've forgotten most of the math I once knew about RSA. If the modulus computation involves the use of the hardware divider (not just the bit shifter), you could leak a lot of information about ke

    • ... an OS could fix this by allowing a process to enter a "secure mode" which would force the other thread on the same CPU to be idle when that process was scheduled.

      Wouldn't that "secure mode" then become some sort of DoS attack? What if an arbitrary user process request repeatedly this mode, just as to slow the rest of the system to a crawl? I know there is now perfect solutions though...

    • My personal guess is that it's a timing attack based on CPU performance counters--both threads can read the performance-counting data for the CPU, so they'll have access to a ton of details data. This includes things like branch prediction, which may be enough to *slowly* reconstruct all of the bits in an RSA key that's used over and over.

      • Re:Probably a Timing-Based Attack (Score:4, Interesting)

        by MoogMan ( 442253 ) on Friday May 13, 2005 @09:31AM (#12518906)
        It is more likely that there is some inherant cache leakage from Logical CPU 0 to Logical CPU 1. Therefore, a process running on CPU 1 could continuously snoop data that CPU 0 is read/writing as its doing its calculations. e.g. In-between an operation at a FPU, being stored in the cache ready to be processed in a different unit.

    • Re:Probably a Timing-Based Attack (Score:5, Informative)

      by AtrN ( 87501 ) on Friday May 13, 2005 @09:32AM (#12518917) Homepage
      This got mentioned in comp.arch and Dan Bernstein pointed out [google.com] others have mentioned similar things previously. The abstract mentioned reads,

      Other People's Cache - HyperAttacks with HyperThreading - Dag Arne Osvik, Norway

      We have investigated the use of memory caches of modern processors as side-channels for timing attacks against software implementations of cryptographic algorithms. In particular, we have successfully performed a new kind of attack where the attacker has no privileges other than being able to run on the same processor as the victim. That is, the attacker has no access to plaintext or ciphertext, and is not allowed by the operating system to communicate with the victim. In this scenario we have recovered 45 out of 128 key bits from AES encryption of English text in just one minute on an Intel processor with HyperThreading. Moreover, with regular known plaintext attacks we have achieved full key recovery.

    • Absolutely... (Score:3, Informative)

      by Kjella ( 173770 )
      ...RSA is vunerable to timing attacks (why we have blinding in software). It's a wonder noone has thought about this earlier though, I remember reading about the military considering virtual machines (i.e. one physical machine could be on both classified/unclassified systems). One of the reasons they didn't was the ability to tap/signal through spinlocks and other timing data. I always thought this was a "well-known but too unlikely to be interesting" weakness, but I guess not. Maybe I should have published

  • In other news.. (Score:5, Funny)

    by peterprior ( 319967 ) on Friday May 13, 2005 @08:36AM (#12518468)
    ...it appears Windows XP Starter Edition may be the most secure option after all... [slashdot.org]

  • stupid paranoid people (Score:2, Interesting)

    by Anonymous Coward
    Some of these "security risks" that people propose are just ridiculous. I mean, I know there are a tiny amount of people who actually follow these risks religiously, and do everything they can to fix them, but they are basically paranoid freaks. Unless your the DOD or have some super top scret evidence, then this means SHIT to you. Lets face it, a trojan, worm or whatever isn't going to use this obscure method of capturing and RSA key that may or may not work. It would take the work of, well, one of those p
  • Hyperthreading is teh suck because I found a flaw.

    I'm not going to tell you how it works until I get a chance to stand up in front of a buch of people and sound smart. In the meantime you can disable HT.

    I can write.

    The flaw affects BSD's and OpenServer for sure.

    I'm unemployed, so give me money to find more flaws.

    Intel rocks!

    Yup...that's pretty much it. Or did I miss something?

  • Same Guy? (Score:5, Interesting)

    by Bananatree3 ( 872975 ) on Friday May 13, 2005 @08:41AM (#12518502)
    This is the same guy who calculated the 1 Quadrillionth hexadigit of Pi (no, not digit. It is in base 16). His project was called PiHex [cecm.sfu.ca]. According to his currently short but illustrious trackrecord [daemonology.net], along with this current announcement [bsdcan.org], he is destined for being a big-name IT security guru.

  • hohum (Score:2, Funny)

    by BigBadBus ( 653823 )
    Don't you think you're carrying this Friday 13th theme a bit too far?

  • Too Scary ! Not ! (Score:2, Insightful)

    by drhodus ( 883743 )
    I think the FreeBSD team is being overly cautious about this issue. They now have disabled HTT by default on all of there release trees stating the reason is because information leakage is possible. This is not ture when anyone can just change the crypto method they are using to something like an RSA method using a FFT(Fast Fourier Transform). There are other methods possible too such as just forcing the HT sibling to go idle for a period of time which would allow the crypto program to run without leaking
  • Anyone working on MultiCore CPU's on a single chip yet?

    Is there a way to access registers on one core directly from another without a supervisor bit requirements?

    Vector based systems I have been familair with use a sharded memory context exception handler for that sort of thing.

    I think multicore CPU instruction sets are going to be interesting to look at as soon as I get my hands on one.

    One more 4U chassis to add to the rack of equipment in my living room. :-)

    -hack
  • Microsoft has issued a patch in response to this "significant" security threat
    You can download RIDDILIN.EXE to address the hyper-thread exploit from their update site...
    Bill Gates assures me in a very personal email, installing this patch will fix the flaw, send me $5 for every other person who installs it... and Intel's stock will go up too. It's win-win...
    Everyone should do it...

  • Timeline - WTH? (Score:2, Interesting)

    by kenh ( 9056 )
    The timeline for this "project" is just amazing:

    Disclosure timeline
    • Late October, 2004: Initial discovery.
    • December 2004: Proof-of-concept exploit written and tested.
    • December 31, 2004: FreeBSD Security Officer Team notified of upcoming security issue.
    • February 2005: First draft of paper completed.
    • February 27, 2005 - March 18, 2005: Other security teams contacted.
    • May 13, 2005 @ 00:00 UTC: Official public disclosure that a security flaw exists in Hyper-Threading.
    • May 13, 2005 @ 15:00 UTC: Full details t

  • hooray ! (Score:2, Offtopic)

    by maharg ( 182366 )
    I have 2 Dell 6650s, loaded with 4 HT Xeons and 32Gb RAM each. However, I had to disable HT on them as the license for the application I'm running allows 8 cpus only; when it detected "16" cpus across the 2 servers, it refused to start. So this news actually makes me feel better about the fact that `top` only shows 4 cpus on each box :o)

  • Security is a real-time embedded application (Score:5, Interesting)

    by gvc ( 167165 ) on Friday May 13, 2005 @09:35AM (#12518939)
    Some of the most effective hacks/espionage come from exploiting "secondary channels" for information.

    For example, I know of one hack from the good old days that involved placing a password across a page boundary. The OS compared the password to a plain text version character-by-character, so faulted if the characters up to the page boundary were all correct. Observing the disk access light (or the time to reject the password) provided character-by-character cracking.

    Of course, password checking is now more sophisticated, but so is cryptanalysis. I think people that use encryption for real are well aware that there's an exposure in doing so on any time-shared system, or any system that can be observed in any way by a potential cryptanalyst.

    I would guess, based on the sparse information presented here, that this is the nature of the attack. If - and that's a big if - you can cause an adversary to be scheduled in just the right way, you may be able to capture part or all of a private key by observing timing artifacts of the hyperthreading implementation.

    This may be good security research, but unless I were protecting state secrets, I'd wait and evaluate the risk relative to other security risks that we find acceptable. I would also guess that the exposure is minimal compared to other high-tech and low-tech potential information leaks.

  • Hyperthreading performance with numerical models (Score:3, Informative)

    by Orp ( 6583 ) on Friday May 13, 2005 @10:01AM (#12519246) Homepage
    This is only tangentially related to the security issue, but I found that disabling hyperthreading on a cluster of dual Xeons running Linux greatly improved performance with a distributed memory (MPI) numerical model. Short summary: even if you only run your model on physical CPUs, hyperthreading will apparently bounce jobs around in a somewhat random way. Not sure if it's a hardware issue or a software (Linux) issue.

    Here is a link which goes into detail [research.orf.cx]

  • Paper (Score:5, Informative)

    by cperciva ( 102828 ) on Friday May 13, 2005 @11:32AM (#12520190) Homepage
    My paper is available here [daemonology.net].

    Have fun reading, I'm going back to the conference.

Slashdot Top Deals

What is research but a blind date with knowledge? -- Will Harvey

Close