10 ms·

Intel Publishes Spectre and Meltdown Hardware Plans: Fixed Gear Later This Year

202 points by nuriaion 9y ago

zaarn 9y ago
*For the datacenter. There doesn't seem to be a concrete plan for consumer chips.
- kikoreis 9y ago
  Actually they say 8th generation Core.
  - neuronflux 9y ago
    I guess there is nothing that can be done about existing processors.
    - wila 9y ago
      Perhaps a bit of a dark thought, but fixing existing processors means you might not buy their new 'fixed' processor. As a result they are not that motivated to fix it as well as they should.
      - perl4ever 9y ago
        I am reading about microcode updates, but I'm wondering if Dell doesn't update the BIOS for my (early Core i3, admittedly pretty old) computer am I SOL regardless of what Intel does?
        wila 9y ago
        The microcode updates can also be loaded via your OS if they are not installed via a firmware update. This happens before the OS itself is loaded early on in the boot stage. See [0] for Linux and possibly [1] for Windows. Not 100% sure if Windows does handle this via Windows Updates or not. [0] https://wiki.gentoo.org/wiki/Intel_microcode https://wiki.gentoo.org/wiki/Intel_microcode [1] http://www.overclock.net/forum/5-intel-cpus/1633419-how-update-intel-microcode-windows-7-x64-bootup-skylake-kabylake-others.html http://www.overclock.net/forum/5-intel-cpus/1633419-how-upda...
  - willvarfar 9y ago
    The article says > "Meanwhile for updating Intel’s consumer chips, this is a bit more nebulous" And then says why it's still ambiguous where that leaves non-DC users
    - tarlinian 9y ago
      I'm not exactly sure what's more "nebulous" about the timing for consumer chips. This timing is specified for both the consumer and server chips in the same sentence in the press release: "These changes will begin with our next-generation Intel® Xeon® Scalable processors (code-named Cascade Lake) as well as 8th Generation Intel® Core™ processors expected to ship in the second half of 2018." (I guess the nebulous thing is exactly which 8th generation Cores will have the update.)
      - wmf 9y ago
        I guess the nebulous thing is exactly which 8th generation Cores will have the update. Indeed. Plenty of 8th gen processors have already shipped so it won't be easy to tell which ones are fixed. Also, 8th gen includes Kaby Lake-R, Coffee Lake, Cannonlake, and maybe Whiskey Lake; I doubt all of those will be fixed. And I was expecting Intel to be selling 9th gen in 2H2018.
        wilun 9y ago
        > Also, 8th gen includes Kaby Lake-R, Coffee Lake, Cannonlake, and maybe Whiskey Lake hm what are they smoking exactly? I want some! :p
- wyldfire 9y ago
  Gee, too bad. While their datacenter customers take security very seriously, their ordinary consumers probably run lots more unsigned code (JS, etc).
  - jerf 9y ago
    One of the most dangerous practical manifestations of this is in datacenters, though, where you use it to go poking around in other people's VMs. On the consumer desktop/laptop, there's many other vectors a lot easier to use already, not least of which is plain old social engineering. Right now an in-the-wild virus that tried to use these vulnerabilities would strike me as somebody showboating more than a serious attempt to exploit systems with these methods.
- ISL 9y ago
  When it's working for the datacenter, it'd be natural for the new designs to rattle down into consumer devices.
  - zaarn 9y ago
    Naturally it goes the other way round: consumer (high end) chips receive new designs first and datacenters get them once they're somewhat battletested.
Slansitartop 9y ago
I'm glad their going to be releasing microcode fixes for older processors, mainly because my hardware still uses one: > Finally, Intel will also be going even further back with their microcode updates. Their latest schedule calls for processors as old as the Core 2 lineup to get updates, including the 1st gen Core processors (Nehalem/Gulftown/Westmere/Lynnfield/Clarksfield/Bloomfield/Arrandale/Clarkdale), and the 45nm Core 2 processors (Penryn/Yorkfield/Wolfdale/Hapertown), which would cover most Intel processors going back to late 2007 or so.
- lathiat 9y ago
  I think it's pretty great that they can actually develop mitigations partly in microcode and they can still do it that far back.
magd 9y ago
How much will go to the CTS fund?
daxfohl 9y ago
Would a hardware fix also eliminate the perf degradation that the software fixes introduced? Or does it just increase security?
- mlindner 9y ago
  It should (depending on how they implement it), as long as the software is re-modified to run the original way on only this platform and later. The performance degradation at least would move into hardware instead of software.
  - samfisher83 9y ago
    How are they going to fix it without some performance penalty. If the memory is in cache isn't there going to be a timing difference? or an extra check will have to be made which is going to have to slow down the lookup?
    - swsieber 9y ago
      From what I underst and this fixes variants two and three which are cross ring and cross process data extraction. I believe their hardware mitigation is to separate the caches between those (or something to that effect). So there will still be a minor penalty hit for running multiple identical process compared to before. That's my interpretation though, I don't know enough to say that's the correct interpretation.
      - Someone1234 9y ago
        Does the hardware on x86 even know which cache is owned by which process? It knows which is elevated (kernel Vs. User Vs. Hypervisor, etc) but process isolation on x86 is largely a kernel API construct rather than a hardware one. Unless I'm mistaken.
        rzzzt 9y ago
        The answer is yes, if the processor supports PCID: https://news.ycombinator.com/item?id=16094349 https://news.ycombinator.com/item?id=16094349 Simplistically, it allows TLB-cached page table contents to be tagged with a context identifier, and limits the lookups in the TLB to only match within the currently allowed context. TLB cached entires with a different PCID will be ignored.
magoghm 9y ago
That was faster than I expected.
- hinkley 9y ago
  Is it? They’ve known about the problem for a while now.
  - sambe 9y ago
    Yes. Most reports placed time-to-available-hardware in the low years (a whole dev cycle). Perhaps those were early sensationalist reports (this article would suggest they were!), but it is a surprise if you only read them.
    - bri3d 9y ago
      Most of the long-horizon reports that I read centered around Spectre 1 (intra-process OOB reads by racing bounds check against conditional branch prediction, currently mitigated by lfence), which is still a fundamental-principles issue that would be exceptionally challenging to solve without either substantial performance loss or some form of userland/compilation-level workaround. Intel still haven't indicated a hardware fix for that one. I expect that most mitigations for this will center around improving static analysis tooling and giving the compiler finer-grained control around fencing to reduce performance impact. Variant 2 (branch target injection, retpoline style software mitigation) is the most interesting. There are certainly obvious theoretical hardware mitigation strategies like tagged BTB entries and this is the most interesting hardware fix. To me it's very cool but not particularly surprising that Intel believe they'll have pure-hardware mitigations for that soon. And Meltdown was frankly an Intel mistake that would have been shocking if left unfixed in the next hardware revision.
- BLKNSLVR 9y ago
  Well, it was the day after the AMD news release, so it's timed pretty well. "Our goal is to offer not only the best performance, but also the best secure performance." Jab!
yalogin 9y ago
Wat exactly is the hardware fix? Is that detailed somewhere?
givinguflac 9y ago
I think I’ll wait for 9th gen to see how this all shakes out.
- frou_dh 9y ago
  For those of use that keep computers for many years, these flaws certainly put a dampener on new sales. No way I'd buy a brand new computer today with a known flawed/suboptimal CPU, and be lumbered with that for the next 5-10 years.
  - sundvor 9y ago
    Yep right there with you. Was hoping to upgrade my OG X1 Carbon laptop this year, now I'm pushing it back another year at least.
  - sintaxi 9y ago
    I suspect CPUs have been flaky for some time. We are only hearing about this because there is finally competition in the space again.
  - mehrdadn 9y ago
    > No way I'd buy a brand new computer today with a known flawed/suboptimal CPU I think at some point you have to give up on the notion that most things will (or even can) ever be perfectly optimal. Whether it's performance, security, reliability, or anything else, everything is flawed in one way or another... it's just a question of how relevant the flaws are for your use cases. In this case I'm not too worried until I hear about an actual Spectre-based attack carried out against a random user in the wild.
    - frou_dh 9y ago
      All I'm saying is that for a certain set of potential customers, this tips the balance from spending money to not spending money. A handful of people inside Intel and computer OEMs are probably spitting feathers about this circumstance. At the present time, I feel no pressure to accept anything.
modeless 9y ago
I'm still waiting to hear if there's ever going to be a hardware mitigation for Spectre variant 1. It's not accurate to call things "fixed" without it. Is anyone even working on it?
- Scaevolus 9y ago
  Spectre variant 1 is only really a problem for JITs, and it's mitigated with masking. Disabling speculation to defeat variant 1 is probably not worth the performance cost.
  - hansendc 9y ago
    Disclaimer: I work on software (Linux) at Intel. There are certainly non-JIT-related mitigations out there. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=56c30ba7b348b90484969054d561f711ba196507 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- hansendc 9y ago
  Disclaimer: I work on software (Linux) at Intel. Spectre variant 1 is arguably a software problem. It's not about consuming "bad" data that was placed by an adversary like variant 2, or allowing a rogue data cache loads like with Meltdown. It happens as the result of normal execution. The processor manuals are also very clear that speculation can be wrong and can have observable side-effects[1][2]. The processors also have ways to constrain speculation architecturally (like lfence) in the case that speculation can do something that results in exposure to a vulnerability. Those two things put together make it a software problem _now_, and perhaps forever. This means that those of us who write security-sensitive software have a long road ahead of us to learn how this affects us and to continue to enhance our defenses. Adding array_index_nospec()'s in Linux, for instance. 1. Intel SDM Vol 3a, 4.10.2.3 Details of TLB Use: "The processor may cache translations required ... for accesses that are a result of speculative execution that would never actually occur in the executed code path." 2. CLFLUSH instruction definition says: "processors are free to speculatively fetch and cache data from system memory regions assigned a memory-type allowing for speculative reads"
narrator 9y ago
Got to have something to sell in case Canon Lake gets delayed again...

202 points by nuriaion 9y ago

zaarn 9y ago

*For the datacenter. There doesn't seem to be a concrete plan for consumer chips.

kikoreis 9y ago
Actually they say 8th generation Core.
- neuronflux 9y ago
  I guess there is nothing that can be done about existing processors.
  - wila 9y ago
    Perhaps a bit of a dark thought, but fixing existing processors means you might not buy their new 'fixed' processor. As a result they are not that motivated to fix it as well as they should.
    - perl4ever 9y ago
      I am reading about microcode updates, but I'm wondering if Dell doesn't update the BIOS for my (early Core i3, admittedly pretty old) computer am I SOL regardless of what Intel does?
      - wila 9y ago
        The microcode updates can also be loaded via your OS if they are not installed via a firmware update. This happens before the OS itself is loaded early on in the boot stage. See [0] for Linux and possibly [1] for Windows. Not 100% sure if Windows does handle this via Windows Updates or not. [0] https://wiki.gentoo.org/wiki/Intel_microcode https://wiki.gentoo.org/wiki/Intel_microcode [1] http://www.overclock.net/forum/5-intel-cpus/1633419-how-update-intel-microcode-windows-7-x64-bootup-skylake-kabylake-others.html http://www.overclock.net/forum/5-intel-cpus/1633419-how-upda...
- willvarfar 9y ago
  The article says > "Meanwhile for updating Intel’s consumer chips, this is a bit more nebulous" And then says why it's still ambiguous where that leaves non-DC users
  - tarlinian 9y ago
    I'm not exactly sure what's more "nebulous" about the timing for consumer chips. This timing is specified for both the consumer and server chips in the same sentence in the press release: "These changes will begin with our next-generation Intel® Xeon® Scalable processors (code-named Cascade Lake) as well as 8th Generation Intel® Core™ processors expected to ship in the second half of 2018." (I guess the nebulous thing is exactly which 8th generation Cores will have the update.)
    - wmf 9y ago
      I guess the nebulous thing is exactly which 8th generation Cores will have the update. Indeed. Plenty of 8th gen processors have already shipped so it won't be easy to tell which ones are fixed. Also, 8th gen includes Kaby Lake-R, Coffee Lake, Cannonlake, and maybe Whiskey Lake; I doubt all of those will be fixed. And I was expecting Intel to be selling 9th gen in 2H2018.
      - wilun 9y ago
        > Also, 8th gen includes Kaby Lake-R, Coffee Lake, Cannonlake, and maybe Whiskey Lake hm what are they smoking exactly? I want some! :p
wyldfire 9y ago
Gee, too bad. While their datacenter customers take security very seriously, their ordinary consumers probably run lots more unsigned code (JS, etc).
- jerf 9y ago
  One of the most dangerous practical manifestations of this is in datacenters, though, where you use it to go poking around in other people's VMs. On the consumer desktop/laptop, there's many other vectors a lot easier to use already, not least of which is plain old social engineering. Right now an in-the-wild virus that tried to use these vulnerabilities would strike me as somebody showboating more than a serious attempt to exploit systems with these methods.
ISL 9y ago
When it's working for the datacenter, it'd be natural for the new designs to rattle down into consumer devices.
- zaarn 9y ago
  Naturally it goes the other way round: consumer (high end) chips receive new designs first and datacenters get them once they're somewhat battletested.

Slansitartop 9y ago

I'm glad their going to be releasing microcode fixes for older processors, mainly because my hardware still uses one: > Finally, Intel will also be going even further back with their microcode updates. Their latest schedule calls for processors as old as the Core 2 lineup to get updates, including the 1st gen Core processors (Nehalem/Gulftown/Westmere/Lynnfield/Clarksfield/Bloomfield/Arrandale/Clarkdale), and the 45nm Core 2 processors (Penryn/Yorkfield/Wolfdale/Hapertown), which would cover most Intel processors going back to late 2007 or so.

lathiat 9y ago
I think it's pretty great that they can actually develop mitigations partly in microcode and they can still do it that far back.

magd 9y ago

How much will go to the CTS fund?

daxfohl 9y ago

Would a hardware fix also eliminate the perf degradation that the software fixes introduced? Or does it just increase security?

mlindner 9y ago
It should (depending on how they implement it), as long as the software is re-modified to run the original way on only this platform and later. The performance degradation at least would move into hardware instead of software.
- samfisher83 9y ago
  How are they going to fix it without some performance penalty. If the memory is in cache isn't there going to be a timing difference? or an extra check will have to be made which is going to have to slow down the lookup?
  - swsieber 9y ago
    From what I underst and this fixes variants two and three which are cross ring and cross process data extraction. I believe their hardware mitigation is to separate the caches between those (or something to that effect). So there will still be a minor penalty hit for running multiple identical process compared to before. That's my interpretation though, I don't know enough to say that's the correct interpretation.
    - Someone1234 9y ago
      Does the hardware on x86 even know which cache is owned by which process? It knows which is elevated (kernel Vs. User Vs. Hypervisor, etc) but process isolation on x86 is largely a kernel API construct rather than a hardware one. Unless I'm mistaken.
      - rzzzt 9y ago
        The answer is yes, if the processor supports PCID: https://news.ycombinator.com/item?id=16094349 https://news.ycombinator.com/item?id=16094349 Simplistically, it allows TLB-cached page table contents to be tagged with a context identifier, and limits the lookups in the TLB to only match within the currently allowed context. TLB cached entires with a different PCID will be ignored.

magoghm 9y ago

That was faster than I expected.

hinkley 9y ago
Is it? They’ve known about the problem for a while now.
- sambe 9y ago
  Yes. Most reports placed time-to-available-hardware in the low years (a whole dev cycle). Perhaps those were early sensationalist reports (this article would suggest they were!), but it is a surprise if you only read them.
  - bri3d 9y ago
    Most of the long-horizon reports that I read centered around Spectre 1 (intra-process OOB reads by racing bounds check against conditional branch prediction, currently mitigated by lfence), which is still a fundamental-principles issue that would be exceptionally challenging to solve without either substantial performance loss or some form of userland/compilation-level workaround. Intel still haven't indicated a hardware fix for that one. I expect that most mitigations for this will center around improving static analysis tooling and giving the compiler finer-grained control around fencing to reduce performance impact. Variant 2 (branch target injection, retpoline style software mitigation) is the most interesting. There are certainly obvious theoretical hardware mitigation strategies like tagged BTB entries and this is the most interesting hardware fix. To me it's very cool but not particularly surprising that Intel believe they'll have pure-hardware mitigations for that soon. And Meltdown was frankly an Intel mistake that would have been shocking if left unfixed in the next hardware revision.
BLKNSLVR 9y ago
Well, it was the day after the AMD news release, so it's timed pretty well. "Our goal is to offer not only the best performance, but also the best secure performance." Jab!

yalogin 9y ago

Wat exactly is the hardware fix? Is that detailed somewhere?

givinguflac 9y ago

I think I’ll wait for 9th gen to see how this all shakes out.

frou_dh 9y ago
For those of use that keep computers for many years, these flaws certainly put a dampener on new sales. No way I'd buy a brand new computer today with a known flawed/suboptimal CPU, and be lumbered with that for the next 5-10 years.
- sundvor 9y ago
  Yep right there with you. Was hoping to upgrade my OG X1 Carbon laptop this year, now I'm pushing it back another year at least.
- sintaxi 9y ago
  I suspect CPUs have been flaky for some time. We are only hearing about this because there is finally competition in the space again.
- mehrdadn 9y ago
  > No way I'd buy a brand new computer today with a known flawed/suboptimal CPU I think at some point you have to give up on the notion that most things will (or even can) ever be perfectly optimal. Whether it's performance, security, reliability, or anything else, everything is flawed in one way or another... it's just a question of how relevant the flaws are for your use cases. In this case I'm not too worried until I hear about an actual Spectre-based attack carried out against a random user in the wild.
  - frou_dh 9y ago
    All I'm saying is that for a certain set of potential customers, this tips the balance from spending money to not spending money. A handful of people inside Intel and computer OEMs are probably spitting feathers about this circumstance. At the present time, I feel no pressure to accept anything.

modeless 9y ago

I'm still waiting to hear if there's ever going to be a hardware mitigation for Spectre variant 1. It's not accurate to call things "fixed" without it. Is anyone even working on it?

Scaevolus 9y ago
Spectre variant 1 is only really a problem for JITs, and it's mitigated with masking. Disabling speculation to defeat variant 1 is probably not worth the performance cost.
- hansendc 9y ago
  Disclaimer: I work on software (Linux) at Intel. There are certainly non-JIT-related mitigations out there. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=56c30ba7b348b90484969054d561f711ba196507 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
hansendc 9y ago
Disclaimer: I work on software (Linux) at Intel. Spectre variant 1 is arguably a software problem. It's not about consuming "bad" data that was placed by an adversary like variant 2, or allowing a rogue data cache loads like with Meltdown. It happens as the result of normal execution. The processor manuals are also very clear that speculation can be wrong and can have observable side-effects[1][2]. The processors also have ways to constrain speculation architecturally (like lfence) in the case that speculation can do something that results in exposure to a vulnerability. Those two things put together make it a software problem _now_, and perhaps forever. This means that those of us who write security-sensitive software have a long road ahead of us to learn how this affects us and to continue to enhance our defenses. Adding array_index_nospec()'s in Linux, for instance. 1. Intel SDM Vol 3a, 4.10.2.3 Details of TLB Use: "The processor may cache translations required ... for accesses that are a result of speculative execution that would never actually occur in the executed code path." 2. CLFLUSH instruction definition says: "processors are free to speculatively fetch and cache data from system memory regions assigned a memory-type allowing for speculative reads"

narrator 9y ago

Got to have something to sell in case Canon Lake gets delayed again...