More Spectre fall out
Recent development kernels include support for a processor feature known as STIBP (single threaded indirect branch predictors). This is part of the x86 mitigation for Spectre-v2. As a refresher, Spectre-v2 affects a part of modern microprocessors known as the indirect branch predictor. This is hardware that attempts to guess the target address of branches (jumps), such as through function pointers (C) or virtual methods (C++).
Many x86 processors implement what’s known as SMT (Symmetric Multi-Threading) in which they create the illusion of having more cores by duplicating some processor resources into pairs of “logical” threads. In Intel and AMD designs, there are two threads per physical core. Together, they have the same performance as one core, but logically are seen by the OS as two separate ones, and careful scheduling of work onto these can increase throughput by up to 30 per cent if each hardware thread is not contending for the same underlying CPU resources (for example, if one thread is performing a division or vector operation while the other is preparing to load data from a memory location).
SMT threads share processor branch predictor hardware, which means that malicious code running on one thread can “train” the predictor shared with the other thread into miss-speculating into Spectre-v2 gadget exploit code. If the peer thread is running application code of interest to an attacker (such as SSL encryption), it is – in theory – possible for attacker code to leak those encryption secrets by becoming co-resident on the same physical core as its victim. To avoid this, vendors added an STIBP mechanism to their processors by patching what’s known as microcode, which is loaded into the CPU at boot time.
The kernel can call STIBP to turn off the indirect predictor on the peer thread when needed, just in case it is running malicious code. Yet this interface is slow, and (performance) expensive, leading Linus to rant that “nowhere in the discussion did I see any mention of just how bad the performance impact of this was”.
A lengthy debate followed in which it was decided that the default would be not to enable STIBP, but that instead it would be opt-in using a per-application API. This will necessitate some fast turnaround of patches implementing the new mechanism prior to the end of the 4.20 development cycle. Watch this space.