Thought you'd addressed those data-leaking Spectre holes on Linux? Guess again. The patches aren't perfect
- Reference: 1591731570
- News link: https://www.theregister.co.uk/2020/06/09/linux_kernel_bugs_spectre/
- Source link:
In three posts marked urgent to the Linux kernel mailing list on Tuesday, Anthony Steinhauser [1]points [2]out [3]problems with countermeasures put in place to block Spectre vulnerabilities in modern Intel and AMD x86 microprocessors that perform speculative execution.
The [4]Spectre family of flaws involve making a target system speculate – perform an operation it may not need – in order to expose confidential data so an attacker can obtain it through an unprotected side channel. It is typically exploited by malware already running on a computer, or a rogue user already logged in.
There's an optimization to Speculative Store Bypass Disable (SSBD), a defense against the Speculative Store Bypass vulnerability ( [5]CVE-2018-3639 ), that was put in place to avoid an expensive model-specific register (MSR) write operation. But the optimization turns out to be a liability because an eavesdropper could use it to disable SSBD.
Meltdown The Sequel strikes Intel chips – and full mitigation against data-meddling LVI flaw will slash performance [6]READ MORE
Steinhauser says there's a logic flaw that sets the wrong value for enforcing SSBD.
"It is exploitable if the attacker creates a process which enforces SSBD and has the contrary value of STIBP (Single Threaded Indirect Branch Predictors) than the victim process … and schedules it on the same core as the victim process," he explained.
"If the victim runs after the attacker the victim becomes vulnerable to [7]Spectre V4 ."
Linux will also force-disable a Spectre mitigation called Indirect Branch Prediction Barrier (IBPB) – a defense against Branch Target Buffer attacks from Spectre V2 – in certain situations, specifically when STIBP is not available or when Indirect Branch Restricted Speculation (IBRS) is available.
This could make AMD-powered computers running Linux vulnerable since the manufacturer [8]advises [PDF] using IBPB rather than IBRS or STIBP to defend against Spectre V2.
Finally, Steinhauser points out that settings for disabling indirect branch speculation don't work.
"Currently, it is possible to enable indirect branch speculation even after it was force-disabled using the PR_SPEC_FORCE_DISABLE option," he wrote. Moreover, the PR_GET_SPECULATION_CTRL command gives afterwards an incorrect result (force-disabled when it is in fact enabled)."
The corrected code is now working its way into the Linux code-base, and should be available shortly. ®
Sponsored: [9]The Forrester New Wave™: Public Cloud Enterprise Container Platforms, Q3 2019
[1] https://lkml.org/lkml/2020/6/9/184
[2] https://lkml.org/lkml/2020/6/9/183
[3] https://lkml.org/lkml/2020/6/9/181
[4] https://www.theregister.com/2018/01/05/spectre_flaws_explained/
[5] https://nvd.nist.gov/vuln/detail/CVE-2018-3639
[6] https://www.theregister.com/2020/03/10/lvi_intel_cpu_attack/
[7] https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00115.html
[8] https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
[9] https://go.theregister.com/tl/1956/-8475/the-forrester-new-wave-public-cloud-enterprise-container-platforms-q3-2019?td=wptl1956
Remove high accuracy timers?
Is it possible to just remove nanosecond-accuracy timing sources from Linux?
When they found (much to everyone's surprise and alarm) that both Firefox and Chrome had fast enough Javascript (JIT compiler compiling the Javascript into native code) to allow these timing effects INSIDE THE BROWSER, Firefox and Chrome simply removed access to nanosecond-accurate timers; they Javascript high-accuracy timer calls are now simply rounded off so they have like 1ms (1/000th of a second) accuracy. Could the same be applied to the Linux user-space itself? Maybe 1/10,000th of a second accuracy (since things like ping show 0.1ms timings)... there's a lot of wiggle room between that and the nanosecond (billionths of a second!) accuracy timers that exist now.
Is there a technical problem with this, like instruction counter or something that's hard to trap? Otherwise, this'd let most mitigations be left off with no ill side effects.
Re: Remove high accuracy timers?
The short answer is no.
Browser makers are able to do that because that level of precision was never part of the design spec and exposes more problems than having it available solves. An actual, functional OS (rather than a JavaScript sandbox) is designed to allow access to that level of accuracy and there's no telling how many crucial bits of code out there rely on it -- everything from sensor monitoring to file access logging to cryptography and beyond may rely on timers that precise, and rounding off could break entire industries.
Nor can you simply enforce any sort of useful gatekeeping around it. You can't say that "only trusted code" gets access to the timers, because malware doesn't respect your rules as-is and there's no effective way to sign all the possible valid apps at this late stage. If it had been baked in from day one, maybe -- but even then it would probably be more hassle than its worth, as high-accuracy timers are not themselves the problem, they're just a means of exploiting it.
OY! 'Nuff o' this shite!
Hypersupermultiubergigathreading this and teraultrahypersmeggingthreading that -- fek it all fer a lark. Bin 'em all an' go back to a trusty Acorn.