Wednesday, July 3rd 2024
"Indirector" is Intel's Latest Branch Predictor Vulnerability, But Patch is Already Out
Researchers from the University of California, San Diego, have unveiled a significant security vulnerability affecting Intel Raptor Lake and Alder Lake processors. The newly discovered flaw, dubbed "Indirector," exposes weaknesses in the Indirect Branch Predictor (IBP) and Branch Target Buffer (BTB), potentially allowing attackers to execute precise Branch Target Injection (BTI) attacks. The published study provides a detailed look into the intricate structures of the IBP and BTB within recent Intel processors, showcasing Spectre-style attach. For the first time, researchers have mapped out the size, structure, and precise functions governing index and tag hashing in these critical components. Particularly concerning is the discovery of previously unknown gaps in Intel's hardware defenses, including IBPB, IBRS, and STIBP. These findings suggest that even the latest security measures may be insufficient to protect against sophisticated attacks.
The research team developed a tool called "iBranch Locator," which can efficiently identify and manipulate specific branches within the IBP. This tool enables highly precise BTI attacks, potentially compromising security across various scenarios, including cross-process and cross-privilege environments. One of the most alarming implications of this vulnerability is its ability to bypass Address Space Layout Randomization (ASLR), a crucial security feature in modern operating systems. By exploiting the IBP and BTB, attackers could potentially break ASLR protections, exposing systems to a wide range of security threats. Experts recommend several mitigation strategies, including more aggressive use of Intel's IBPB (Indirect Branch Prediction Barrier) feature. However, the performance impact of this solution—up to 50% in some cases—makes it impractical for frequent domain transitions, such as those in browsers and sandboxes. In a statement for Tom's Hardware, Intel noted the following: "Intel reviewed the report submitted by academic researchers and determined previous mitigation guidance provided for issues such as IBRS, eIBRS and BHI are effective against this new research and no new mitigations or guidance is required."
The company was notified in February and had room to fix it. Intel also notified its system vendors, so the security layers protecting against this are in place. Here is the BHI mitigation, and here is the IBRS/eIBRS mitigation.
Source:
Indirector
The research team developed a tool called "iBranch Locator," which can efficiently identify and manipulate specific branches within the IBP. This tool enables highly precise BTI attacks, potentially compromising security across various scenarios, including cross-process and cross-privilege environments. One of the most alarming implications of this vulnerability is its ability to bypass Address Space Layout Randomization (ASLR), a crucial security feature in modern operating systems. By exploiting the IBP and BTB, attackers could potentially break ASLR protections, exposing systems to a wide range of security threats. Experts recommend several mitigation strategies, including more aggressive use of Intel's IBPB (Indirect Branch Prediction Barrier) feature. However, the performance impact of this solution—up to 50% in some cases—makes it impractical for frequent domain transitions, such as those in browsers and sandboxes. In a statement for Tom's Hardware, Intel noted the following: "Intel reviewed the report submitted by academic researchers and determined previous mitigation guidance provided for issues such as IBRS, eIBRS and BHI are effective against this new research and no new mitigations or guidance is required."
14 Comments on "Indirector" is Intel's Latest Branch Predictor Vulnerability, But Patch is Already Out
So getting rid of it looks like a promising way to address this and increase ST performance too.
In programs that make very frequent calls to the operating system this should make a big difference.
It's all branch predictor mayhem.
Curious how much the patch nerfs the CPUs. Wont update the bios but of course windows update might force the microcode.
Reread the first post, looks like existing software mitigations already exist for it.
But there is Amdahl's Law to take into account: there are often parts that are limited by the single-threaded performance.
I know a large commercial and very expensive application that uses an in-memory database but most of the many theads accessing that database need to lock it. The end result is that it is very dependent on the single-threaded performance.
On the desktop the situation is different, when cpu's with hyperthreading came out there were applications (mostly games) where it was advised to turn off hyperthreading.
We will see how it works out in practice when Lunar Lake comes out..
Hyperthreading is almost always worth it and it's very easy to explain why: imagine a laundry service only starting a new washing cycle once the previous load comes out of the dryers. A core has many different parts to it, some of them can even be redundant (i.e. to handle higher bit counts or whatever) and it doesn't make sense to have them all doing nothing when the first operation is almost out the door.
Where HTT is at its best is if all available cores on the system are heavily loaded, but they have gaps for i/o wait. Assigning two threads per core allows a second thread to do processing whilst the first thread is waiting. This is why HTT shines in a few workloads such as software encoding but doesnt do much for general desktop use.
Your example with the washing machine is that, the machine whilst in use is busy and cannot be used by anyone else, on a windows desktop with 2000 threads, these threads will typically only be active for very short periods of time. The contention on a low utilised CPU means it can handle multiple threads fine.
One advantage of having two classes of CPU cores in a CPU is one set of cores can have all the background stuff sent to it, which reduces thread contention for the foreground interactive app. So e.g. if you have say 2000 threads on a system, what happens if 1992 of those threads are all on the e-cores and a 8 threaded game has 8 p-cores all to itself, thats vastly superior to any legacy HTT one class CPU system.
Whether HTT is worth with it all of this going on I suppose is down to opinion, do I think an extra 10% performance for an extra 50% of power is worth it? Usually no. But for some people, they want extra performance no matter the cost, they dont care if it makes the CPU throttle due to excessive temps or requires an extra 100w of power. Every % of throughput matters. Of course HTT has extra costs now with all the security problems as well. All the security mitigations I have seen for HTT is effectively disabling HTT to mitigate it.
I think when we talk between us its down to opinions, but I think when a CPU manufacturer decides the direction needs to change, its more than an opinion, they make the chips, they know the cost in terms of silicon space, the trade offs, the gains from removing HTT and so forth, so if intel are removing HTT, then its likely a net gain from it.
I think the only workloads I have seen HTT benefit is in the server space, or on desktop CPU based encoding. Otherwise its just benchmarks. I think it can help on highly threaded games, if your physical core count is below 8, but above that the benefit seems within margin of error. HTT can actually reduce performance as well, a 2 threaded game will run better if its using 2 physical cores compared to 2 logical cores on the same physical core.