SoylentNews is people
SoylentNews
It seems Intel has had some second thoughts about Spectre 2 microcode fixes:
Intel has issued new a new "microcode revision guidance" that confesses it won't address the Meltdown and Spectre design flaws in all of its vulnerable processors – in some cases because it's too tricky to remove the Spectre v2 class of vulnerabilities.
The new guidance (pdf), issued April 2, adds a "stopped" status to Intel's "production status" category in its array of available Meltdown and Spectre security updates. "Stopped" indicates there will be no microcode patch to kill off Meltdown and Spectre.
The guidance explains that a chipset earns "stopped" status because, "after a comprehensive investigation of the microarchitectures and microcode capabilities for these products, Intel has determined to not release microcode updates for these products for one or more reasons."
Those reasons are given as:
- Micro-architectural characteristics that preclude a practical implementation of features mitigating [Spectre] Variant 2 (CVE-2017-5715)
- Limited Commercially Available System Software support
- Based on customer inputs, most of these products are implemented as "closed systems" and therefore are expected to have a lower likelihood of exposure to these vulnerabilities.
Thus, if a chip family falls under one of those categories – such as Intel can't easily fix Spectre v2 in the design, or customers don't think the hardware will be exploited – it gets a "stopped" sticker. To leverage the vulnerabilities, malware needs to be running on a system, so if the computer is totally closed off from the outside world, administrators may feel it's not worth the hassle applying messy microcode, operating system, or application updates.
"Stopped" CPUs that won't therefore get a fix are in the Bloomfield, Bloomfield Xeon, Clarksfield, Gulftown, Harpertown Xeon C0 and E0, Jasper Forest, Penryn/QC, SoFIA 3GR, Wolfdale, Wolfdale Xeon, Yorkfield, and Yorkfield Xeon families. The list includes various Xeons, Core CPUs, Pentiums, Celerons, and Atoms – just about everything Intel makes.
Most [of] the CPUs listed above are oldies that went on sale between 2007 and 2011, so it is likely few remain in normal use.
(Score: 0) by Anonymous Coward on Wednesday April 04 2018, @12:12PM (1 child)
Use the nopti kernel cmdline boot option to forcefully disable the software fixes and get performance back. Of course with the understanding of what the risks are of doing so. Check, analyse, and understand if spectre/meltdown really are such a big deal to your particular use-case and computer or not, weigh up the options, and then patch or don't patch accordingly. But don't just blindly turn the fixes off. (Or on either.)
e.g. A few options to think about:
- You on a single user physical machine just used by yourself? Perhaps no big deal then leaving the vulnerabilities unpatched, you have other security concerns if you frequently run less-then-trustworthy code, or code which is likely to try to target these exploits.
- You need to run such potentially exploitable code? Run it in a VM which has the software fixes, and don't worry so much about the hypervisor. Or run it on it's own physical hardware if you have such resources.
- You running a mix of more trusted and less trusted services, or services which have different attack surfaces, on the same machine? Seperate and virtualise them, then treat them for this flaw individually.
- You already use virtualisation and mix public- and non-public-facing systems on the same hardware, and worried about an independent bug allowing an attacker first compromising the public VM, then using this exploit to jump across VMs from the public to non-public? Fine, patch the hypervisor, patch the less-trusted VM, but leave the trusted VM unpatched so at least that one doesn't get a double-whammy performance hit.
- Or heck, why not patch the hypervisor only, and leave all VMs unpatched? If a public VM is compromised by different means, and you've segregated services enough, why does it matter as much if the exploit can be used within the VM, as long as the hypervisor still prevents it reaching out to other more trusted VMs?
Other than for cloud services and organisations which consolidate what should be independent systems with their own trust boundaries onto the same physical hardware, I think this issue is way overblown for the average single-user computing device. These hardware bugs basically break down trust boundaries between systems or applications where we expect them to be enforced. So if we approach the issue from this trust viewpoint rather than the typical "we must fix all bugs and apply all patches at any cost!", then we can take a more sensible approach to how they are handled, or if they even need to be handled in individual scenarios. Sure, cloud vendors etc make up a very large chunk of affected use cases these days, so the effort being put into mitigation is understandable. But it doesn't mean those fixes are necessarily appropriate in absolutely all cases. Security comes in layers, and I feel the layer provided by this fix is overkill in many cases when there are other layers in place.
At least linux gives us users the option whether we want the fixes enabled or not, the same cannot be as easily said for the vendors of the more closed software systems.
Also, please someone correct me if I'm wrong and am spouting nonsense in how to approach this vulnerability, or in how I appear to understand how it manifests itself and the impacts of it.
(Score: 2) by Subsentient on Wednesday April 04 2018, @01:20PM
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti