3 ms·

This is how this terrible CEO tells us about microcode fixes, at a CES speech? Or is he even talking about a microcode update, or about the patches everybody el

This is how this terrible CEO tells us about microcode fixes, at a CES speech? Or is he even talking about a microcode update, or about the patches everybody else has been losing their lives working on? What a crap response to such a huge and existential issue. Make a web page on the Intel site with concise, real information on what's going on and what to do. We're a week into disclosure and there's still no patch for most people's servers. A patch that takes up to a 30% performance hit but may not be necessary if there's going to be a microcode fix? I know this is just a cute speech and debate practice session for the Intel execs, but I have servers that will have to get trashed because of the slowdown patch, they will be too slow to function in their current role and will need to be replaced. This is seriously affecting my life, my work schedule and my wallet. Please have real engineers provide real information here.

sounds 9y ago
Let me break down what the article really says (it's pretty short): > He also said that Intel expects to issue updates > to its processors soon. More than 90 percent will be > getting them within the week, and the rest by the end > of January. Intel expects 90 percent will "get an update." 90 percent of what? It should be self-evident that Intel means 90 percent in whichever way gives them the largest percentage. I expect this means Intel discounts "older CPUs" that are "probably not in use." In other words, 90 percent of CPUs sold in the last N years for whatever N makes the percentage largest (5 years [1]) "The rest by the end of January" can be taken with a huge grain of salt. Intel is documenting and exposing an MSR to flush the [ed] branch predictor, but only for recent CPUs, and admits they aren't able to do so in a timely manner, or they would have said "100 percent." [1] https://newsroom.intel.com/news-releases/intel-issues-updates-protect-systems-security-exploits/ https://newsroom.intel.com/news-releases/intel-issues-update... "Intel has already issued updates for the majority of processor products introduced within the past five years. By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years" Edit: I incorrectly stated the MSR was for the TLB, it is not. It is for the branch predictor.
- vardump 9y ago
  > exposing an MSR to flush the TLB, but only for recent CPUs You write to CR3 register to flush TLB (or use INVPCID to invalidate just a subset of TLB). So not sure what that means, why would you need an MSR for that?
  - sounds 9y ago
    I stand corrected, the MSR is to flush the branch prediction state. Updating my comment above.
- userbinator 9y ago
  ...or maybe the other 10% are in-order non-speculative designs which are intrinsically immune; they still have a few: https://en.wikipedia.org/wiki/Intel_Quark https://en.wikipedia.org/wiki/Intel_Quark (basically a die-shrink of a 486!) https://en.wikipedia.org/wiki/Bonnell_(microarchitecture) https://en.wikipedia.org/wiki/Bonnell_(microarchitecture)
  - sounds 9y ago
    "Intel expects to issue updates to its processors soon. ... the rest by the end of January." Not "the rest are not affected," or "the rest are intrinsically immune." If they were, Intel could have deflated a lot of the PR around AMD being immune while Intel is affected.
  - planteen 9y ago
    Just read the Wikipedia, looks like you are trading one hardware bug for another on the Quark. At least you know when a segfault happens I guess. "Intel Quark SoC X1000 contains a bug #71538[11] that "under specific circumstances" results in crash, known in the industry as a segfault. The workaround implemented by Intel is to omit LOCK instructions in the compiled code.[12] While Yocto Project based embedded systems incorporate this workaround, general purpose Linux distributions such as Debian are deeply affected by the bug. Such a workaround is not easy to implement on multithreading systems as they require LOCK instruction to function properly."

sounds 9y ago

Let me break down what the article really says (it's pretty short): > He also said that Intel expects to issue updates > to its processors soon. More than 90 percent will be > getting them within the week, and the rest by the end > of January. Intel expects 90 percent will "get an update." 90 percent of what? It should be self-evident that Intel means 90 percent in whichever way gives them the largest percentage. I expect this means Intel discounts "older CPUs" that are "probably not in use." In other words, 90 percent of CPUs sold in the last N years for whatever N makes the percentage largest (5 years [1]) "The rest by the end of January" can be taken with a huge grain of salt. Intel is documenting and exposing an MSR to flush the [ed] branch predictor, but only for recent CPUs, and admits they aren't able to do so in a timely manner, or they would have said "100 percent." [1] https://newsroom.intel.com/news-releases/intel-issues-updates-protect-systems-security-exploits/ https://newsroom.intel.com/news-releases/intel-issues-update... "Intel has already issued updates for the majority of processor products introduced within the past five years. By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years" Edit: I incorrectly stated the MSR was for the TLB, it is not. It is for the branch predictor.

vardump 9y ago
> exposing an MSR to flush the TLB, but only for recent CPUs You write to CR3 register to flush TLB (or use INVPCID to invalidate just a subset of TLB). So not sure what that means, why would you need an MSR for that?
- sounds 9y ago
  I stand corrected, the MSR is to flush the branch prediction state. Updating my comment above.
userbinator 9y ago
...or maybe the other 10% are in-order non-speculative designs which are intrinsically immune; they still have a few: https://en.wikipedia.org/wiki/Intel_Quark https://en.wikipedia.org/wiki/Intel_Quark (basically a die-shrink of a 486!) https://en.wikipedia.org/wiki/Bonnell_(microarchitecture) https://en.wikipedia.org/wiki/Bonnell_(microarchitecture)
- sounds 9y ago
  "Intel expects to issue updates to its processors soon. ... the rest by the end of January." Not "the rest are not affected," or "the rest are intrinsically immune." If they were, Intel could have deflated a lot of the PR around AMD being immune while Intel is affected.
- planteen 9y ago
  Just read the Wikipedia, looks like you are trading one hardware bug for another on the Quark. At least you know when a segfault happens I guess. "Intel Quark SoC X1000 contains a bug #71538[11] that "under specific circumstances" results in crash, known in the industry as a segfault. The workaround implemented by Intel is to omit LOCK instructions in the compiled code.[12] While Yocto Project based embedded systems incorporate this workaround, general purpose Linux distributions such as Debian are deeply affected by the bug. Such a workaround is not easy to implement on multithreading systems as they require LOCK instruction to function properly."