Linux Developers Continue Discussing "SLS" Mitigation For The Kernel

Disclosed by Arm last summer was the Straight Line Speculation (SLS) vulnerability and they were quick to introduce new safeguards against SLS in the GCC and LLVM compilers. The compiler-based mitigations to straight-line speculation involves adding speculation barrier sequences around the vulnerable instructions to prevent speculatively executing instructions around changes in control flow. While compiler developers were quick to add the options, so far the Linux kernel developers are in disagreement still over its importance and the proposed patches that would flip on this option when compiling the ARM Linux kernel.

While compiler support is out there for hardening against straight-line speculation on ARM, seeing these options utilized by potentially affected software hasn't been so quick. In February there were Google engineers proposing a kernel option for enabling the ARM SLS mitigation. The kernel patch is for basically enabling the "-mharden-sls=" compiler option for inserting speculation barrier (SB) instructions or otherwise DSB+ISB instructions around the instructions vulnerable to SLS.

The patch itself is simple in basically just flipping on the compiler option, but this week it's now up to its sixth round of review and developers seem to still be in disagreement if it's necessary and should be merged. Even fellow Google engineers working on the kernel haven't seen eye to eye on this proposed mitigation patch.

At build-time via the Kconfig option is support for configuring whether to mitigate all mitigations against SLS or not use it as well or optionally to just enable the mitigation for RET and BR instructions or just BLR instructions. There is the potential for some performance impact of this mitigation and will be interesting to benchmark it if/when it's been mainlined.

The sixth round of this patch is up for review and any remaining debate on the kernel mailing list.