Linux Kernel Getting New Option So SSBD Isn't Over-Protective - Helping Performance

For the Linux kernel's Speculative Store Bypass Disable (SSBD) handling for Spectre Variant 4 protection is support for processes opting into force disabling of speculation via a prctl() interface. Currently when speculation is disabled, that is carried through to new processes started via the execve() system call. But a new bit will allow clearing that state when a new program is started by a process otherwise relying upon PR_SPEC_DISABLE, in what will help the performance in such cases.

Queued for introduction to the mainline Linux kernel is a new PR_SPEC_DISABLE_NOEXEC option for prctl as part of the Speculative Store Bypass Disable options but where the state is cleared on execve() calls. The premise is that programs opting into disabling speculation are doing so, but programs that aren't vulnerable to the speculation-related misfeatures normally aren't checking to see that the PR_SPEC_ENABLE bit is set rather just assuming the status quo. Thus with the current PR_SPEC_DISABLE behavior, programs spawned via execve() may be protected when they really don't need to be and carrying with that the added performance overhead.

Processes using execve() and knowing those programs don't need this speculation protection will be able to set the PR_SPEC_DISABLE_NOEXEC bit for indicating as such and thus ensuring optimal performance for those programs.

Waiman Long of Red Hat who authored the patch now queued in tip.git explains:

With the default SPEC_STORE_BYPASS_SECCOMP/SPEC_STORE_BYPASS_PRCTL mode, the TIF_SSBD bit will be inherited when a new task is fork'ed or cloned. It will also remain when a new program is execve'ed.

Only certain class of applications (like Java) that can run on behalf of multiple users on a single thread will require disabling speculative store bypass for security purposes. Those applications will call prctl(2) at startup time to disable SSB. They won't rely on the fact the SSB might have been disabled. Other applications that don't need SSBD will just move on without checking if SSBD has been turned on or not.

The fact that the TIF_SSBD is inherited across execve(2) boundary will cause performance of applications that don't need SSBD but their predecessors have SSBD on to be unwittingly impacted especially if they write to memory a lot.

Of course, applications desiring the current behavior can continue using that bit or the PR_SPEC_FORCE_DISABLE if wanting to force the SSBD functionality and not allowing it to be potentially undone.