Call Depth Tracking Aligning For Linux 6.2 To Lessen Mitigation Performance Hit For Intel Skylake

While the Linux 6.1 merge window just passed and the "Call Depth Tracking" patches have been in development the past few months, it looks like that for the Linux 6.2 kernel is where that alternative mitigation technique will be introduced for helping offset some of the significant performance regressions incurred for Intel Skylake era processors as a result of recent CPU security vulnerability mitigations.

Peter Zijlstra of Intel has been working on the "Call Depth Tracking" mitigation approach for Intel Skylake era hardware that now otherwise needs the Indirect Branch Restricted Speculation (IBRS) mitigation enabled as a result of the Retbleed vulnerability.

Call Depth Tracking in place of the IBRS for affected Skylake era Intel processors has shown to have significantly less performance cost. See this earlier article for more details on this alternative Retbleed mitigation.

Over the past several months the patch series has been inching closer to mainline while now having missed the Linux 6.1 merge window, unless it's sent in as a "fix" given its security nature, it looks more than likely this will end up in the Linux 6.2 kernel.

Following this weekend's merge window closure and Linux 6.1-rc1 release, the x86/core TIP branch was rebased against 6.1-rc1 and atop that the Call Depth Tracking patch series. So the Call Depth Tracking work is now up for testing in TIP's x86/core. Given it's in x86/core rather than x86/urgent is further indication it will be held off until the next kernel cycle rather than trying to wiggle its way in as a "fix" for 6.1.

Thomas Gleixner sums up this new mitigation work in this patch:

The fully secure mitigation for RSB underflow on Intel SKL CPUs is IBRS, which inflicts up to 30% penalty for pathological syscall heavy work loads.

Software based call depth tracking and RSB refill is not perfect, but reduces the attack surface massively. The penalty for the pathological case is about 8% which is still annoying but definitely more palatable than IBRS.

Add a retbleed=stuff command line option to enable the call depth tracking and software refill of the RSB.

This gives admins a choice. IBeeRS are safe and cause headaches, call depth tracking is considered to be s(t)ufficiently safe.

The patch adding X86_FEATURE_CALL_DEPTH also goes on to criticize the expense of the existing Skylake IBRS:

Intel SKL CPUs fall back to other predictors when the RSB underflows. The only microcode mitigation is IBRS which is insanely expensive. It comes with performance drops of up to 30% depending on the workload.

A way less expensive, but nevertheless horrible mitigation is to track the call depth in software and overeagerly fill the RSB when returns underflow the software counter.

Provide a configuration symbol and a CPU misfeature bit.

Yes, enabling this Call Depth Tracking is done via the retbleed=stuff option on a patched kernel. The mitigation enabled state via sysfs on affected CPUs will also be indicated as ""Mitigation: Stuffing" for Retbleed. Besides retbleed=stuff, the patched Linux kernel also must be built with CALL_DEPTH_TRACKING enabled.

While unfortunately missing out on the Linux 6.1 merge window, the Call Depth Tracking work is in TIP's x86/core freshly re-based and hopefully will be found in the Linux 6.2 cycle early next year for helping to offset the significant performance cost induced by IBRS since the Retbleed disclosure for Intel Skylake users.