Patches For The Better Spectre STIBP Approach Revised - Version 7 Under Review

[phoronix]

Phoronix: Patches For The Better Spectre STIBP Approach Revised - Version 7 Under Review

Version 7 of the task property based options to enable Spectre V2 userspace-userspace protection patches, a.k.a. the work offering improved / less regressing approach for STIBP, is now available for testing and code review...

http://www.phoronix.com/scan.php?pag...ved-V7-Patches

[schmidtbag]

With the new V7 patches there is protection for SECCOMP tasks, bug fixes, updated the boot options to align with the other speculation mitigations, disabling the SMT code paths when irrelevant for the current system configuration, and other code changes.

I'm not totally sure what exactly this implies, but I had a somewhat similar idea that I think would work well:
Disable SMT code paths for any core(s) that have a single-threaded application running on them. To my understanding, the real vulnerability here is how SMT threads can read the L1 cache and therefore predict what the other thread is doing. But if that SMT'd thread is completely off-limits whenever a single-threaded application is using the core, you should be able to retain the performance of multi-threaded applications, which can claim both threads of a single core without being vulnerable (I think, anyway).

[s_j_newbury]

I'm not totally sure what exactly this implies, but I had a somewhat similar idea that I think would work well:
Disable SMT code paths for any core(s) that have a single-threaded application running on them. To my understanding, the real vulnerability here is how SMT threads can read the L1 cache and therefore predict what the other thread is doing. But if that SMT'd thread is completely off-limits whenever a single-threaded application is using the core, you should be able to retain the performance of multi-threaded applications, which can claim both threads of a single core without being vulnerable (I think, anyway).

That requires the OS to hide every other logical CPU from the task scheduler for processes and only allow threads from a process already scheduled to run on that core to be queued, and then make sure they only get executed at the same time with appropriate barriers. The problem is threads from a CPU perspective are not the same thing as threads from an OS perspective, or even from an application perspective. Application->OS->SMT thread mapping isn't 1:1, without even considering the common case of different OS processes running on each SMT thread.

[-MacNuke-]

I see that they set STIBP also on AMD CPUs. Are they even affected since it is a Spectre 2 thing?

[rukur]

I see that they set STIBP also on AMD CPUs. Are they even affected since it is a Spectre 2 thing?

AMD seem required to be glued together with Intel because evil corp's overlords.