Kernel 6.2 ditched a useful defense against ghostly chip design flaw:
The Spectre vulnerability that has haunted hardware and software makers since 2018 continues to defy efforts to bury it.
On Thursday, Eduardo (sirdarckcat) Vela Nava, from Google's product security response team, disclosed a Spectre-related flaw in version 6.2 of the Linux kernel.
The bug, designated medium severity, was initially reported to cloud service providers – those most likely to be affected – on December 31, 2022, and was patched in Linux on February 27, 2023.
"The kernel failed to protect applications that attempted to protect against Spectre v2, leaving them open to attack from other processes running on the same physical core in another hyperthread," the vulnerability disclosure explains. The consequence of that attack is potential information exposure (e.g., leaked private keys) through this pernicous problem.
The moniker Spectre [PDF] describes a set of vulnerabilities that abuse speculative execution, a processor performance optimization in which potential instructions are executed in advance to save time.
It's timing, however, that animates Spectre. Spectre v2 – the variant implicated in this particular vulnerability – relies on timing side-channels to measure the misprediction rates of indirect branch prediction in order to infer the contents of protected memory. That's far from optimal in a cloud environment with shared hardware.
[...] The bug hunters who identified the issue found that Linux userspace processes to defend against Spectre v2 didn't work on VMs of "at least one major cloud provider."
As the disclosure describes it, under basic IBRS (Indirect Branch Restricted Speculation, the 6.2 kernel had logic that opted out of STIBP (Single Thread Indirect Branch Predictors), a defense against the sharing of branch prediction between logical processors on a core.
"The IBRS bit implicitly protects against cross-thread branch target injection," the bug report explains. "However, with legacy IBRS, the IBRS bit was cleared on returning to userspace, due to performance reasons, which disabled the implicit STIBP and left userspace threads vulnerable to cross-thread branch target injection against which STIBP protects."
(Score: 0) by Anonymous Coward on Sunday April 16, @06:39AM (2 children)
Is it possible bugs are left unpatched at the request of agencies with ongoing projects that make use of them? That old malice / incompetence gray area.
(Score: 4, Insightful) by canopic jug on Sunday April 16, @06:56AM (1 child)
The kernel did not allow anything, the problem lies with the hardware itself. Sure there are some aftermarket mitigations that the kernel can sometimes implement but don't forget for a second that the problem really likes with Intel's hardware.
It's really interesting in a very problematic kind of way that the media is spinning a problem with Intel's hardware's very design as a Linux error.
Money is not free speech. Elections should not be auctions.
(Score: 0) by Anonymous Coward on Monday April 17, @11:32AM
Actually the problem lies with the interactions of a popular method used to speed up CPU execution ( speculative execution) with other stuff (caches)
Other processors are affected too, not just Intel. Some CPUs do more checks so are not vulnerable to as many types of attacks but they are still vulnerable.
https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability [arm.com]
https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)#Impact [wikipedia.org]
See also: https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability) [wikipedia.org]
If you don't mind sticking to slower CPUs then this problem won't affect you.
(Score: 4, Insightful) by driverless on Sunday April 16, @08:35AM (1 child)
Running sensitive code on a machine shared with arbitrary malicious software from third parties is never going to be safe, no matter how many kludges you apply to it. This was recognised with the related issue of subliminal channels back in the 1970s. The solution to the problem is "don't do that, then", not to engage in a neverending tail-chase of the problem.
(Score: 5, Insightful) by turgid on Sunday April 16, @09:06AM
Quite. The Cloud is a solution looking for a problem. Use the right tool for the job. Usually, that isn't the cloud.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].