lolloj - Fotolia

Tip

Weighing the cost of mitigating Spectre variant 2

Fixes for the Spectre variant 2 vulnerability affect system performance, so some in the tech sector wonder whether they're worth it. Expert Michael Cobb examines that question.

Michael Cobb
By
Published: 21 Feb 2019

Functionality versus security, ease of use versus security and performance versus security: These are the challenges that every vendor faces when it comes to getting a software or hardware product to market and supporting its user base.

Semiconductor chipmaker Intel has been grappling with these issues ever since the Spectre and Meltdown vulnerabilities were discovered and made public at the beginning of 2018. These vulnerabilities arise from micro-architectural design techniques used to increase the speed of modern microprocessors.

However, these techniques can also be abused to enable attackers to bypass system protections on nearly every modern PC, server and smartphone. And in the case of Spectre, the attack can enable malicious programs to induce a hypervisor to transmit data to a guest system running on top of it.

Mitigating Spectre variant 2

Producing a viable patch, particularly against the Spectre variant 2 vulnerability, is proving to be difficult, as branch prediction and speculative execution, which accelerate the rate at which a CPU can execute instructions, are fundamental features used to improve CPU performance.

Intel had to pull its first firmware update aimed at reducing the risk of a successful Spectre-based attack, as it caused unpredictable system behavior and unexpected system reboots. Recently, another Spectre variant 2 mitigation put in place by Intel caused some significant performance slowdowns, particularly on the latest version of the Linux kernel -- 4.20 -- according to research by Phoronix.

The performance hit is due to the system turning on Single Thread Indirect Branch Predictors (STIBP) by default. This is one of the speculative execution side-channel mitigations reviewed by Intel; the others include Indirect Branch Restricted Speculation and Indirect Branch Predictor Barrier.

STIBP is an indirect branch control mechanism that restricts the sharing of branch prediction between logical processors on a core so one logical processor can't control the predicted targets of indirect branches using another logical processor of the same core. While this mitigates cross-hyperthread Spectre variant 2, this restriction also affects the CPU's overall performance, particularly when performing tasks that are I/O-intensive. So, when it comes to the issue of performance versus security, what is the right call for enterprises?

Performance versus security

Although researchers have discovered over a hundred samples of malware that exploit Spectre and Meltdown, there's still not a single viable exploit that's been found in the wild. However, for many enterprises, any vulnerability has to be taken seriously. Deactivating hyperthreading altogether mitigates many speculative execution-related vulnerabilities and the performance impact is much more consistent -- for some tasks, there may even be a boost in performance.

Linus Torvalds, the creator of the Linux kernel, suggests turning off STIBP protection in favor of better performance, and the Linux 4.20-RC5 release now makes STIBP optional rather than it being enabled for all processes. This means that if an application needs side-channel mitigation and doesn't suffer any loss of performance, it can enable STIBP and those tasks that don't need STIBP protection will not be slowed down unnecessarily.

Deciding where and when to implement this Spectre variant 2 mitigation is not straightforward and requires detailed examination by network administrators and security teams. Together, they must determine the correct balance between performance and security for processes that run on different machines.

Dig Deeper on Application and platform security