Intel Wraps Up Spectre Patching, Partially Cancels Plans For 1st Gen Core & Core 2 Processorsby Ryan Smith on April 4, 2018 7:00 AM EST
Intel this week has published an update to their ongoing microcode guidance document. In the roughly 3 weeks since the last update, the company is offering some unexpectedly mixed news: some additional microcode updates have been finished and released to production, but the company is also aborting their previous plans for issuing updates for some early-generation Core processors.
Last month we reported on the state of Intel’s efforts to issue microcode updates for processors to mitigate the Spectre v2 vulnerability. As of mid-March Intel had finished developing microcode updates for architectures going back to 2nd generation Core (Sandy Bridge), and was in the middle of planning or pre-beta development of updates for processors going back to the Core 2 era. Instead, with this latest guidance, Intel is essentially putting an end to their microcode program, coming to a halt with microcode updates for about half of their 1st generation Core lineup. The end result is that no Core 2 CPUs will be receiving updates, and only some 1st gen Cores will.
Intel’s chip/architecture stack for these earlier generations is somewhat confusing due to a multitude of codenames, which doesn’t help matters here, but here’s the general breakdown of what processor families have been excised from Intel’s support plans.
|Intel's Spectre v2 Microcode Updates|
|Microarchitecture||Core Generation||Product Lines||Status|
|Penryn||45nm Core 2||Core 2||Cancelled|
|Nehalem||1st (45nm Core)||Core i7-900||Cancelled|
|Mobile Core i7-900/800/700||Cancelled|
|Westmere||1st (32nm Core)||Core i7-900||Cancelled|
|Mobile Core i7-600|
|Mobile Core i5-500/400|
|Mobile Core i3-300|
|Sandy Bridge||2nd||Core 2000||Released|
In short, no Core 2 processors will be receiving a microcode update. Updates for Penryn and all derivative processors have been cancelled.
As for the 1st generation Core family, what did and didn’t get updated is an odd mix. Ignoring the Xeon side of the equation, Intel has essentially opted to deliver updates for most of their mainstream 1st gen Core processors, but not updates for their high-end models. So the desktop Core 900 series is out, for example, while the Core 800 and below is in. Meanwhile on the mobile side of matters, the Core 900M, 800M, and 700M processors have been excluded, but the Core 600M and below are included.
Overall there isn’t an apparent rhyme or reason from an architectural standpoint for the split. The patched processors include both the newer 32nm models and older 45nm models, but it’s not a complete set from either the tick or the tock side. Which, if nothing else, makes it difficult to make blanket statements about patches for the 1st generation Core processors.
The good news here is that for those 1st gen Core processors that are going to be covered with those microcode updates, Intel has completed them and delivered them to production. So the usual disclaimers about distribution aside – and I’ll be surprised if virtually all of these updates in the consumer space don’t eventually have to be distributed by OS vendors – the necessary microcode updates are available. In fact with this latest release, Intel has now completed their microcode update plans according to their roadmap; there are no additional processor families slated to get the Spectre v2 mitigations.
As for Intel’s rationale for the change in plans, the microcode guidance update document includes a new production status, “stopped,” which covers the cancelled processor families. Under which, Intel states:
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 including, but not limited to the following:
- Micro-architectural characteristics that preclude a practical implementation of features mitigating 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.
Presumably the checkerboard nature of the 1st gen Core updates falls to business reasons. Though it would be interesting to hear what micro-architectural characteristics are presumably preventing deploying patches on Intel’s 45nm Core 2 processors.
Overall this is an unsatisfying (but not upsetting) end to Intel’s microcode update program. After a rough start, Intel has essentially updated 8 years’ worth of processors, an important distinction since it means they’ve covered the Sandy Bridge generation and beyond, which remain in service and reasonably popular to this day (ed: not that I’d know anything about that). And while it was always clear that Intel wouldn’t continue going backwards forever, stopping halfway through the 1st gen Core family after previously scheduling it for support ends things on a disjointed note. Meanwhile for Core 2 owners, the bell is finally tolling, it seems. The processor family that reinvigorated Intel after the Pentium 4 era is finally being left behind.
Update: Intel sent over the following statement this afternoon in response to all of the articles today about the change in microcode update plans.
We’ve now completed release of microcode updates for Intel microprocessor products launched in the last 9+ years that required protection against the side-channel vulnerabilities discovered by Google. However, as indicated in our latest microcode revision guidance, we will not be providing updated microcode for a select number of older platforms for several reasons, including limited ecosystem support and customer feedback.”
Source: Intel (via Tom's Hardware)
Post Your CommentPlease log in or sign up to comment.
View All Comments
menthol1979 - Wednesday, April 4, 2018 - linkAh, farewell my beloved Q9650 :)
solnyshok - Wednesday, April 4, 2018 - linkI still have 2 kids' PCs running Q9650 o.c. to 4.2GHz with 8GB RAM and ssds, gtx960, win 10. I am going to keeps those around for another 1-2 years
willis936 - Wednesday, April 4, 2018 - linkI’d argue it’s somewhat upsetting. I keep a Q6600 under my electronics bench because it has a parallel port. I’d like to also keep it on the network but it seems like that may be a bad idea going forward. In principle I don’t like intel just getting away with this without doing their due dilligence.
Elstar - Wednesday, April 4, 2018 - linkDid you read the article? They tried, and they found limits to what can be accomplished with the older chips. Is that not due diligence?
willis936 - Wednesday, April 4, 2018 - linkWhat I read was "We decided this was good enough and people won't mind the over promising. It helped save face at the time so we've already extract the most value from it we would. Here is the last note that an engineer wrote down before we told him to stop working on it".
The_Assimilator - Wednesday, April 4, 2018 - linkBecause it's not possible to buy a USB-to-parallel-port adapter, or a PCIe card with a parallel port, that can be plugged into any computer.
DanNeely - Wednesday, April 4, 2018 - linkHow well do those work in practice? USB-Serial adapters have a lognstanding reputation of being awful if you need to do anything beyond the most basic spraying of data back and forth.
willis936 - Wednesday, April 4, 2018 - linkIf you had experience with parallel you would know that the drivers require DMA to the parallel port and have tight timings. USB adapters don't work for most any application and the host OS needs to be windows 7 or earlier.
chipped - Thursday, April 5, 2018 - linkYou can get USB serial adaptor that support Windows 10 and also DMA. Seriously guys, in this day and age it’s not so hard to look something up...
willis936 - Thursday, April 5, 2018 - linkSerial is not parallel. It isn't hard to look something up but I'd like you to go ahead and try to use a parallel printer or flash a gameshark through a setup newer than a windows 7 host OS on a native parallel port and a windows 98 VM. Protip: you can't.