Spectre bug is back, this time to haunt JIT engines

The Spectre microarchitecture vulnerability has returned yet again, this time to vex just-in-time (JIT) engines that generate machine code for browsers, runtimes, and kernels. The vulnerability is found in many CPUs that use speculative execution, the process of executing code before it is called to boost performance. …

[keb]

How about removing the problem?

I wonder what percent of performance would be lost if speculative execution were disabled entirely.

And why aren't these fancy multi-core multi-thread cpus tasked to wipe orphaned branches?

[BoHu]

Re: How about removing the problem?

Yeah, you'd think someone would have thought of this, or, more specifically, have extended cache coherency mechanisms to also include the BTBs (each core commonly has its own, within its BPU, not accessible from other cores). So there's the hardware issue that along with I+D cache coherency across cores, there should also be BTB coherency. On top of that though, there's the software issue that properly running SMCs requires an I-cache flush (which we do, and auto-propagates to other cores via hardware coherency -- I hope), but the boffins here note we should also do a BTB flush to prevent the stale BTR exploit that they discuss, and this may not be auto-propagated to other cores ATM. From the "Branch Target Reuse paper" TFA link:

"Another option is to invalidate branch predictor state when JIT code is removed [...]. We believe this to be the most robust mitigation for BTR attacks. [It requires] ensuring that the predictor state is flushed on all of [the cores]"

They cite Intel's IBPB command as doing at least some of that in their ref. [25].

[Groo The Wanderer - A Canuck]

Personally I don't care how large the impact of protecting a host from such attacks is, not with the typical performance of a modern compute node, which has far exceeded anyone's actual needs, even for gaming or real time simulations, except for the heaviest of scientific or engineering compute loads.

[Nate Amsden]

Kind of odd.. I'm the opposite, viewing these kinds of attacks are way overblown. Unless you are targeted by a state actor, and even then, you really don't have to worry about them. I turn the protection off on all my systems, always have. There are way easier ways to get into systems, especially linux ones given all of the other vulnerabilities that have been coming out.

But on the overhead, I recall vividly in one use case, an older Thinkpad T450s laptop that I got about 5-6 years ago, installed Mint 20 on it, and it felt so incredibly slow, almost to the point where I was feeling it was unusable(if I had to use it for a day I would be very annoyed). It has a i7-5600U(2 cores, 4 threads 2.6-3.2Ghz) which launched in 2015. Then I realized I didn't yet disable those protections(kernel option spectre_v2=off), once I did that it was night and day better performance. I wasn't doing anything intensive, just clicking around, doing stuff in the browser, OS updates etc. Until I turned that protection off, the laptop was really unusable to me. Laptop already had an SSD, and at least 8G of memory (it has 12G now, unsure if it came with 12G or if I upgraded it)

I have since replaced both batteries in the laptop, and I use it for short travel (1-3 days), I don't travel often. My main laptop (Lenovo P15 with Xeon CPU and 128G of ram) stays on my desk unless I'm going on a long trip(2 such trips in past 3.5 years). It runs perfectly fine now, super fast to do anything I'd want it to do and the batteries last for a long time too.

When it was slow, I don't recall CPU usage being pegged or anything, it was more like the latency involved to do things was really high, even basic things like OS updates took forever(felt like 3-5x longer to do updates, I did not benchmark or closely measure). Wasn't really registering on monitoring tools.

Given the age of the CPU perhaps it has a much higher impact on performance than something in the past 5-6 years since there was quite a bit of mitigations applied in newer cores directly in the years since.