Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.
posted by Fnord666 on Wednesday April 04 2018, @08:46AM   Printer-friendly
from the defect-closed-will-not-fix dept.

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Wednesday April 04 2018, @11:51AM (1 child)

    by Anonymous Coward on Wednesday April 04 2018, @11:51AM (#662434)

    Time to migrate to in-order ARM chips and call it a day. Intel screwed the pooch big time on this one and it is time to make the plunge and lose a bit of performance for guaranteed security. It is what I am doing.

    Sadly PPC G5 chips have the same issue, and while the odds of attacks against them are low, it means that Old Mac G5 systems are just as risky to use online or with a web browser (since even if the javascript engine has mitigations, as soon as they trip an exploit to executable code they can use spectre either way.)

    If you want an easy way to mitigate these issues, all you really need to do is change the ondemand scheduler in linux to under full load vary the cpu clock between steppings, which will throw off timing for the spectre attacks. You will get a stuttery experience if you are running something that truly demands the higher clock rate to perform smoothly, but for everything else it will just act as a spectre mitigation.

  • (Score: 2) by requerdanos on Wednesday April 04 2018, @10:14PM

    by requerdanos (5997) Subscriber Badge on Wednesday April 04 2018, @10:14PM (#662661) Journal

    If you want an easy way to mitigate these issues, all you really need to do is change the ondemand scheduler in linux

    The intel_pstate driver [stackexchange.com] only offers two governors: performance and powersave. Neither does what you might expect, as frequencies vary by load with both of them.

    Disabling intel_pstate and using ACPI brings back the ondemand governor, but with reduced performance. From the link above:

    The intel_pstate driver knows the details of the how the CPU works and it does a better job than the generic ACPI solution. intel_pstate offers only two governors, powersave and performance. Intel claims that the intel_pstate "powersave" is faster than the generic acpi governor with "performance"

    I can confirm that the intel_pstate powersave governor, somewhat counter-intuitively, keeps my Xeon E5v2 chip running about 2.8GHz, its rated max speed. (The performance governor seems to run it at about 3.1 - 3.2 GHz.)

    Point being, I guess, that even if that's a good mitigation technique, it comes with its own toils and troubles.

    (And I would rather have a new governor, say "psycho" or something, modeled on the ondemand governor but with the unpredictability, rather than messing with ondemand itself, anyway.)