Retbleed: Call Depth Tracking Mitigation Eyed To Avoid IBRS "Performance Horror Show"

Due to the new "Retbleed" security mitigation further hurting CPU performance for affected processors, Intel engineers have revisited work on call depth tracking mitigation as an alternative to the Indirect Branch Restricted Speculation (IBRS) mitigation to help in lowering the overhead costs.

Thomas Gleixner of Linutronix, which Intel acquired earlier this year, and longtime Intel engineer Peter Zijlstra have been working on "retbleed=stuff" as a new mitigation approach for Retbleed with call depth tracking.

This new mitigation approach aims to have lower overhead than IBRS usage. Gleixner summarized the situation this weekend on the kernel mailing list:

Back in the good old spectre v2 days (2018) we decided to not use IBRS. In hindsight this might have been the wrong decision because it did not force people to come up with alternative approaches.

It was already discussed back then to try software based call depth accounting and RSB stuffing on underflow for Intel SKL[-X] systems to avoid the insane overhead of IBRS.

This has been tried in 2018 and was rejected due to the massive overhead and other shortcomings of the approach to put the accounting into each function prologue:

1) Text size increase which is inflicted on everyone. While CPUs are good in ignoring NOPs they still pollute the I-cache.

2) That results in tail call over-accounting which can be exploited.

Disabling tail calls is not an option either and adding a 10 byte padding in front of every direct call is even worse in terms of text size and I-cache impact. We also could patch calls past the accounting in the function prologue but that becomes a nightmare vs. ENDBR.

As IBRS is a performance horror show, Peter Zijstra and me revisited the call depth tracking approach and implemented it in a way which is hopefully more palatable and avoids the downsides of the original attempt.

We both unsurprisingly hate the result with a passion...
...
Call depth tracking is designed to break this speculation path by stuffing speculation trap calls into the RSB which are never getting a corresponding return executed. This stalls the prediction path until it gets resteered,

The assumption is that stuffing at the 12th return is sufficient to break the speculation before it hits the underflow and the fallback to the other predictors. Testing confirms that it works. Johannes, one of the retbleed researchers. tried to attack this approach and confirmed that it brings the signal to noise ratio down to the crystal ball level.

There is obviously no scientific proof that this will withstand future research progress, but all we can do right now is to speculate about that.

Their benchmarks have shown this call depth tracking mitigation to be lower overhead than taking the current IBRS route. Gleixner commented, "So the benefit varies depending on hardware and workload scenarios. At least it does not get worse than IBeeRS."

At the moment this new mitigation strategy is a set of 38 patches now out for review on the mailing list. In current form with these patches the call depth tracking approach is activated using the "retbleed=stuff" kernel option. The 38 patches amount to nearly two thousand lines of new kernel code in dealing with this security nightmare.