Hacker News new | past | comments | ask | show | jobs | submit login
Intel won’t release Spectre patches for some older chips after all (liliputing.com)
143 points by awiesenhofer on April 3, 2018 | hide | past | favorite | 41 comments



The support list [1] is weird. Gulftown (Core i7) and Westmere-EP (Xeon) are essentially the same chips yet only the latter is patched. The distinction between Gulftown and Westmere-EP actually was barely ever made until now. And Intel's confusing product line has lasted until today - the Xeon W3690 is apparently Gulftown (the only Xeon) and is not patched [2], yet the Xeon W3670 and W3680 are Westmere-EP and will receive their microcode updates [3].

According to this document, make sure to read your CPU's model numbers carefully. It doesn't reflect well on Intel that the line does not appear to be drawn based on technical capability, but apparently on contractual obligations.

Many CPUs in the unsupported list still make very serviceable hardware in 2018. It's a shame a security issue will only add to their obsoletion, or make people using this hardware more vulnerable. Spectre variant 2 is difficult to exploit in practice, but that sounds like some famous last words.

[1]: https://newsroom.intel.com/wp-content/uploads/sites/11/2018/...

[2]: On page 8

[3]: On page 16


If Intel doesn't come through consistently across the board, regardless of "contractual obligations", people are going to be looking at Apple's rumored transition away from Intel all the more favorably.

And yes, by saying this, in part I'm hoping to put it into people's minds. And, if there's enough of that, into pressure on Intel.

P.S. My concern extends to what may happen to coverage if/when succeeding rounds of fixes are needed. In general, we don't appear to be done with this class of problem in extant products.

Not that Apple's "the solution". But lack of support will prompt people to consider alternatives.


Apple designed ARM silicon does not preclude being vulnerable to Spectre (or other hardware level bugs).

Both Intel and Apple have large talent pools of excellent silicon and lithography engineers but that hardly makes them immune to bugs, and some bugs will end up being vulnerabilities.


The parent's point is not that Apple's chips won't have bugs, but that Apple's chips will have bugfixes.


I don't know to what extent I trust Apple's follow-through. But, purchasers will have more choices.

And, Apple's silicon development appears to be top-notch. In addition, the company professes and demonstrates some ongoing concern about security.

So, depending on Apple's ongoing hardware developments, Intel may face technical pressures on the security front with respect to processors and SoC.

And Intel needs to match its technical developments with demonstrated concern for its users' security and not allowing its products to compromise same.

Anyway... I hope the pressure stays on Intel. Going through the current process -- not just with Intel, but with system vendors -- wondering whether my several year old but still quite functional systems will be updated, and when.

And right before that, the struggle to know what to do about the ME vulnerabilities.

Some people have to be getting kind of tired of this. And now to carry continued tension, waiting for the next shoe to drop.

In the phone world, Apple users don't seem to worry as much as Android users with respect to vulnerabilities. Because Apple usually patches them fairly quickly, and Apple also has used its muscle to bypass carriers' horrendously bad update support as witnessed in the Android world.

Computer users aren't going to want to worry whether they're going to get a full life out of their computer, or have to stop using it for X months until a problem gets patched.

Right now, most of them are pretty oblivious to the current chip problems. These problems start turning into active exploits, and that's going to change.

Ok. Ramble over.


Sorry, your > 3yo Mac Pro has a critical security flaw in our Apple CPU... sucks to be you, buy a new one.


Does Apple have a track record of supporting anything for 10 years? The only chips Intel isn't patching are about that old.


I have a 2009 iMac running the latest macOS version (High Sierra) but won’t get a microcode update from Intel.


That the W3690 is not the same uarch as the W3670 and W3680 is weird as all hell. Even weirder that it differs from the X5690, to which it is almost identical. Did they start selling the W3690 before the other Xeon W-series SKUs?

Saw the headline and my heart sank, but I got a lucky dodge on this. Bought a W3680 because at the time, I couldn't find a W3690 at a reasonable price (from what I could tell they were a top choice for people refreshing their Mac Pros?). Maybe I'll squeeze another 7 years from this X58 machine yet!


> That the W3690 is not the same uarch as the W3670 and W3680 is weird as all hell.

Well that's the thing - they are the same thing! The difference between Gulftown and Westmere-EP seems to be entirely marketing, but this marketing difference now results in patching difference.


Sigh, I put a W3690 in an old Mac Pro a couple of years ago, and it's been working nicely. Now time for plan B...


Just make sure to get a processor that's not Intel. No need to reward them for bad behaviour.


That's going to be hard without changing the mainboard, which will most likely not make it easy to (continue? to) run MacOS.


Good point. For me it's not an issue as I barely use OSX any more.

But for people wedded to that platform... not much room to move. :/


This list includes the base model CPU in the 2009, 2010, and 2012 Mac Pros, as well as some of the BTO upgrades. I'm disappointed, but not surprised.

The 2012 Mac Pros, in particular, were still being sold less than 5 years ago, so this means it's still officially supported by Apple. I wonder if there's some awkward conversations happening between the two companies about that.

Fortunately, it's possible to upgrade the CPU in a Mac Pro to a newer part which is still supported by Intel.


I think the "awkward conversations" are already over:

https://news.ycombinator.com/item?id=16737072


I think this means we've only seen the beginning of the full effects of Spectre. I'm expecting consequences for years to come.


This list includes the Penryns used in most Mac laptops and the Mac Minis up to ~2010 vintage. I still use mine to host various Internet-facing utility services, which it does handily.


So, all the Libreboot laptops are done. Frog boiled.

Freedom's last holdout now are Coreboot ARM machines like the latest ARM Chromebooks.


I am not sure of that: https://github.com/speed47/spectre-meltdown-checker#quick-su... seems to say that software mitigation exists for all three variants.


RISC-V: A new hope


Until you can run x86_64 at native speeds, replacing it will take a long time.


I wouldn't even bother mentioning X86(64) in the context of RISC-V. When RISC-V becomes financially viable for manufacturers they'll switch. Cost alone is enough to justify the change. Most of the innovation happening these days is in the mobile sector with mobile devices replacing more and more of the average consumer's computing needs. This alone has made for some pretty nimble software already. Every device sold with one of those ARM-based processors has an Arm holding "tax." ALL vendors are happy to not pay that tax and will be even happier to have nothing to do with ARM Holdings at all (I've heard they're shit to work with). Arm and RISC-V are both RISC architecture; not hard for software to switch. What happens in the mobile sector will trickle down to the rest of the tech industry. Microsoft has even embraced RISC with Windows on snapdragon devices. I doubt the consumer will even notice a difference.


Doesn't have to be native, only fast enough to power gaming, office and extensive image collections. Only one of those requires lots of computing horse and that mainly on the GPU (though there are some offenders like PUBG or Minecraft, the later also slurping up a significant chunk of memory bandwidth)


https://youtu.be/Ii_pEXKKYUg?t=5m16s

RISC-V is already faster. It just needs better fabs.


I already knew RISC-V was/is faster in benchmarks. But does that translate to transparently emulating x86_64 for the majority of use cases?


You can't be serious...


Libreboot laptops run without intel microcode patches


I think you are confusing EFI firmware with CPU microcode, the EFI does often contain microcode ROMs to upload to the CPU at boot but the microcode itself is proprietary and signed and reverse engineering is quite a challenge - In fact there was a submission of a presentation here not long ago showing the painstaking progress of a small group of individuals attempting to reverse engineer some intel microcode.

I assure you there is no working libre microcode for intel CPUs and it seems far more likely people will successfully focus their efforts on open source hardware before being able to successfully replace substantial microcode of complex closed source hardware.

In "libre" EFI mods they tend to disable ME as well, maybe you were confusing that with microcode?


Libreboot is a "de-blobbed" fork of Coreboot

One of its omissions is that it excludes microcode ROM updates that can be inserted at power on by the BIOS

As I understand it. The CPU's of that era are old enough that they can run without updated microcode being inserted either at system bootup or operating system boot time


Ommiting microcode from the EFI has nothing to do with whether a CPU has loadable microcode capability or whether it is vulnerable. Unless you are using some pre-pentium intel CPU, an initial microcode revision is included in an on die ROM and an updated revision can be loaded at boot. Loading it in EFI/BIOS vs OS is a matter of convenience, which is why it's usually left to the OS these days.

Not having microcode blobs in the EFI doesn't magically mean your CPU doesn't use microcode or doesn't need patched versions to stay secure as in this case.

I do find it a little deceptive with some of these "libre" projects where they draw an arbitrary box around something, evict all proprietary blobs from it and then announce victory despite it operating underneath a whole load of other blobs that could easily subvert it. However I suspect the intent behind evicting microcode from libreboot was more due to it being a redundant task for EFI today.


Oh fucking great... my CPU's on the list, they didn't ask me but apparently I don't mind someone stealing all of my credentials from my main computer... what kind of BS non user said that.

I will never buy another Intel CPU, fuck you very much Intel.

If you have an old macbook you might want to check that list, the various flavours of C2Duos on that list were pretty common.


The Bloomfield i7s are still perfectly serviceable processors. People will almost certainly continue using them unpatched.


My Q6600 based desktop (g0 stepping) died right before all this news came out after a decade of dedicated use. Guess it would have had to be retired anyways.


Has AMD released Spectre patches for all of their old chips? I'm guessing they haven't so it looks likes Intel has company.


If I'm not mistaken, the weaknesses of AMD processors with regards to Spectre were less pronounced than Intel's, so maybe they could get by.


According to Wikipedia, AMD CPU's are just as vulnerable to Spectre variant 1 and 2 as is Intel. The confusion that AMD was not vulnerable to variant 2 was due to a mistake made by AMD and later corrected by them 9 days later after verifying they were also vulnerable to variant 2.

AMD originally acknowledged vulnerability to one of the Spectre variants (GPZ variant 1), but stated that vulnerability to another (GPZ variant 2) had not been demonstrated on AMD processors, claiming it posed a "near zero risk of exploitation" due to differences in AMD architecture. In an update nine days later, AMD said that "GPZ Variant 2…is applicable to AMD processors" and defined upcoming steps to mitigate the threat. Several sources took AMD's news of the vulnerability to GPZ variant 2 as a change from AMD's prior claim, though AMD maintained that their position had not changed.


Their position didn't change. AMD architecture simply doesn't prefetch data that requires elevated permissions to execute.


Unfortunate, but not unexpected.

A shame about Bloomfield and Gulftown, but the rest of the products seem to be firmly in the legacy/obsolete category.


Bloomfield's a decade old, Gulftown only moderately less. I'm pretty sure I'd put them in the legacy category today (and I have a 975 around here, so I'm a little bummed, but I get it).


Afaik Westmere was the first to support PCID in the first place.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: