4 ms·
The botched embargo destroyed their chances of managing the PR like they thought they would be able to do. Intel thought they could roll Spector and Meltdown i
by phire 9y ago
The botched embargo destroyed their chances of managing the PR like they thought they would be able to do.
Intel thought they could roll Spector and Meltdown into a single massive bug, that all CPUs were vulnerable to. Instead, AMD leaked the fact that AMD CPUs didn't need the KPTI patch, which meant the very first thing people knew was "it's an Intel bug". This very much put the Intel PR effort on a back foot.
Then Intel thought they could just release their microcode update (hell, they even coordinated with AMD to release the same microcode patches), and tell linux "here are the patches to use it, you must merge it". I assume the plan involved disclosing on the 9th and essentially bully Linus into merging the patches by the 10th.
They wanted people to thank them for spending millions to develop the new microcode and once-and-for-all solving this problem. They wanted the headlines "Intel releases microcode which fixes Spectre/Meltdown flaw" so that people would stop demanding intel replaces their broken silicon.
Then google releases details about their retpoline idea (I'm assuming it was developed not long before the embargo ended). It achieves the same thing, but with less performance penalty and no microcode update needed.
So now the Linux mailing list has something to debate. The Intel engineers are very motivated to get their patches merged, because they spent millions developing that microcode and they want the PR wins for "fixing the problem". Watch how the immediately segway into "oh, but retpolines don't work on skylake"
The Linux engineers are not happy with this, they are angry at Intel for being the source of the problem and probably see through Intel's little PR plan. They are triple checking intel's work and seeing if they can come up with an even better solution that works on skylake too.
- walterbell 9y agoIs Microsoft relying on Intel & AMD microcode to mitigate Spectre, or could they also use the approach now being proposed by the Linux kernel developers? If they don’t, will Windows performance be worse than Linux on the same hardware, for a comparable workload?
- sgc 9y agoIt seems pretty obvious that they will be following what happens at the very least, and won't allow themselves to fall into irrelevance if better classes of solutions come along.
- walterbell 9y agoSince Microsoft is in the Linux Foundation and runs Linux guests on Windows, they could contribute to the public discussion on Spectre mitigation in Linux.
- phire 9y agoYes, RHEL too (and probably apple). The Intel engineer in that email seems to be bragging about it: I think we also want to expose IBRS to VM guests, even if we don't use it ourselves. Because Windows guests (and RHEL guests; yay!) do use it.
- bonzini 9y agoRHEL is going to switch to retpolines too. But it will take some time.
- forgot-my-pw 9y agoI hope so. Their first round of bug fixes caused pretty significant slowdown on 2015 and older CPUs. > With Windows 10 on older silicon (2015-era PCs with Haswell or older CPU), some benchmarks show more significant slowdowns, and we expect that some users will notice a decrease in system performance. > With Windows 8 and Windows 7 on older silicon (2015-era PCs with Haswell or older CPU), we expect most users to notice a decrease in system performance. > Windows Server on any silicon, especially in any IO-intensive application, shows a more significant performance impact when you enable the mitigations to isolate untrusted code within a Windows Server instance. This is why you want to be careful to evaluate the risk of untrusted code for each Windows Server instance, and balance the security versus performance tradeoff for your environment. https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems/ https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/...
- amaranth 9y agoAccording to https://plus.google.com/+jwildeboer/posts/jj6a9JUaovP https://plus.google.com/+jwildeboer/posts/jj6a9JUaovP Google was deploying a retpoline-based mitigation in production in September. Seems likely that existed _before_ any thought of microcode fixes. I wonder if, based on working with Skylake and newer chips only at the time, Intel thought the microcode version was going to be a performance alternative to retpoline instead of it being the other way around.
- marksomnian 9y agonit: segue, not segway
- Santosh83 9y agoPerhaps a naive question but can we expect something like retpolines for Windows or is it already done that way, or does Windows rely on the slower Intel microcode? Any idea? EDIT: I just saw replies to walterbell asking the same question as me, so please ignore this one.
- bonzini 9y agoRetpolines certainly existed in November, perhaps before. But it's somewhat harder to modify compiler+kernel than shipping microcode you get from Intel and modifying the kernel to adopt a (no matter how ill-designed) new CPU feature. Also, it's not easy to make sure that retpolines cover all the corner cases. There was little time. Intel engineers are a nice and cool bunch. It's not their fault.