Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday July 07, @04:29AM   Printer-friendly
from the When-You-Need-the-Wrong-Answers-*FAST*! dept.

Recently published research has exposed a security flaw affecting 12th, 13th, and 14th-generation Intel processors. Similar to Spectre, Meltdown, and Downfall, it could cause the processors to leak sensitive information.

Researchers from the University of California San Diego discovered the attack, dubbed "Indirector." It targets the indirect branch indicator (IBI), a critical component of modern Intel CPUs. As a Spectre V2 attack, it uses Branch Target Injection, which can alter where processors send important information.

Furthermore, the study reveals previously undisclosed information about the workings of the indirect branch predictor, branch target buffer, and Intel security measures like IBPB, IBRS, and STIBP. Reverse engineering has uncovered new vulnerabilities in these processes.

Using a specialized tool, an attacker could insert a multi-target direction path into the IBP, potentially exposing sensitive data. Another method can eject the target user from the IBP and commit a BTB injection attack with a similar result.

More aggressive IBPB implementation could protect against the flaw but may introduce significant performance penalties. The researchers also suggest that Intel tighten its security in other areas in future designs.

Intel told Tom's Hardware that its existing countermeasures, such as IBRS, eIBRS, and BHI, are effective against Indirector, so it will not issue further mitigations. Intel's website hosts detailed explanations of these systems. The researchers plan to reveal more information at the August USENIX Security Symposium.

With the discovery of Indirector, every modern Intel processor is now vulnerable to at least one known exploit. Spectre has impacted Blue Team's processors for over a decade, while Downfall affects consumer CPUs from the 6th through 11th generation. Meanwhile, Meltdown impacts Intel, AMD, and Arm systems. (Emphasis added.)

The researchers tested Indirector on Alder Lake and Raptor Lake processors, potentially adding to the issues plaguing the latter. For weeks, users running CPU-intensive processes like games and productivity software have encountered crashes on high-end 13th and 14th-gen Intel chips, and the company has yet to find a permanent solution. In the meantime, Intel instructed affected users to undervolt their CPUs.

Whether Chipzilla can avoid these or similar issues with upcoming generations like Arrow Lake and Panther Lake remains unclear.


Original Submission

This discussion was created by martyb (76) for logged-in users only. Log in and try again!
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 4, Insightful) by looorg on Sunday July 07, @10:53AM (4 children)

    by looorg (578) on Sunday July 07, @10:53AM (#1363366)

    .. could protect against the flaw but may introduce significant performance penalties.

    Hopefully the same "protection" covers multiples of all the Intel-boogiemen (Spectre, Meltdown ...) otherwise if it takes a massive hit for each one of them then the CPU should be at a crawl these days. How much of a speed or performance increase of the predictive algorithms are they getting if each and every one of these is taking a significant performance penalty? How much is "significant" anyway? 50%? More?

    When are they getting rid of "prediction" to increase CPU performance? After all it seems that is the common culprit of all these attack vectors.

    Seems a lot of these attack the current, and previous, range of CPU trickery, or order of instruction execution. I guess CPU:s are like Operating Systems. The bigger they get, the more crud and crap they contain, the more exploitable things there are.

    Will the next range, whatever it's called, have all these issues to?

    ... Intel instructed affected users to undervolt their CPUs.

    Which would further degrade the overall speed and performance. We know how fast the CPU is supposed to be from the box. But how fast is it actually if you have to undervoltage and run a lot of gatekeeping software to keep it "safe"? How much performance have been lost to "security" or just bugs.

    Using a specialized tool, an attacker could insert a multi-target direction path into the IBP, potentially exposing sensitive data. Another method can eject the target user from the IBP and commit a BTB injection attack with a similar result.

    But can it be done remotely? If it requires physical access to the machine to install, run and get the "sensitive data" result via this "special tool". If they already have that kind of access they can just take the whole machine with them and go.

    • (Score: 3, Insightful) by RamiK on Sunday July 07, @02:27PM (2 children)

      by RamiK (1813) on Sunday July 07, @02:27PM (#1363371)

      I'm honestly surprised Intel doesn't just release their chips with a couple of in-order cores and call it a day.

      --
      compiling...
      • (Score: 1, Interesting) by Anonymous Coward on Sunday July 07, @06:14PM (1 child)

        by Anonymous Coward on Sunday July 07, @06:14PM (#1363380)

        I'm honestly surprised Intel doesn't just release their chips with a couple of in-order cores and call it a day.

        Maybe EPIC [wikipedia.org] was a good idea after all and Intel could bring back the Itanium. In that architecture, all speculative execution is explicitly coded in software. So while you likely still have to worry about this category of problems, in most if not all cases they should be programmer/compiler bugs, not hardware bugs, so the hardware vendors can blame someone else for them (and also they would be much less costly to fix).

        • (Score: 2) by RamiK on Sunday July 07, @07:23PM

          by RamiK (1813) on Sunday July 07, @07:23PM (#1363387)

          The reason only inference is done with VLIW NPUs instead of training is because instruction-level parallelism remains a challenging problem at best*. However, thread-level parallelism is already being done all over the place: Linux had dozens and hundreds of threads on a typical system. Windows has similarly broken apart many of its processes in recent years. So, if Intel simply sticks a few in-order cores and tells Microsoft to pin the kernel in there, they've pretty much solved the problem.

          ARM, I believe, did something similar with specific instructions that turn speculation on and off. Maybe Intel will do that.

          * There were a few words from Mill Computing on their progress a few weeks ago: https://millcomputing.com/topic/yearly-ping-and-see-how-things-are-going-thread/ [millcomputing.com]
          A Japanese research team redeveloped/reinvented a Mill-style Belt architecture a while ago which, putting aside the patents issues [millcomputing.com], effectively validated some of the Mill's approach to some of the Itanium's problems by a third party: https://www.rsg.ci.i.u-tokyo.ac.jp/members/shioya/pdfs/Koizumi-MICRO'23.pdf [u-tokyo.ac.jp]

          Regardless, the fact you just don't see VLIWs for ML training around despite all the VC money is a pretty clear indication that there's still a dividing line around branching logic and extracting instruction-level parallelism from uops is just beyond contemporary designs at least. And mind you, this is an industry that has been writing non-general purpose shaders for over a decade and actually started with VLIW GPUs. So, if it was trivial... But still, I remain hopeful about the Mill.

          --
          compiling...
    • (Score: 2) by ChrisMaple on Monday July 08, @04:25AM

      by ChrisMaple (6964) on Monday July 08, @04:25AM (#1363419)

      Computers doing serious compute-heavy work shouldn't be connected to the internet anyway. That leaves only bad actors inside an organization, and that's a personnel problem, not a technical problem.

  • (Score: 2) by hendrikboom on Monday July 08, @12:04AM

    by hendrikboom (1125) Subscriber Badge on Monday July 08, @12:04AM (#1363407) Homepage Journal

    I keep hearing of problems with Intel processors, but very little about problems with one of their competitors, AMD.
    Are AMD processors more secure or do they just benefit from lack of media interest
    so we rarely hear about them?
    I gather they use different mechanisms for speculative execution.
    I've been told they also have 'something similar to the Intel management engine', but nothing seems to be known about it. How similar it it? Is it likely to be vulnerable in the same way? Is it easy to surrepstitiously rewrite the microcode remotely with the right keys?

(1)