Wednesday, January 3rd 2018
Dear Intel, If a Glaring Exploit Affects Intel CPUs and Not AMD, It's a Flaw
Intel tried desperately in a press note late Wednesday to brush aside allegations that the recent hardware security-vulnerability are a "bug" or a "flaw," and that the media is exaggerating the issue, notwithstanding the facts that the vulnerability only affects Intel x86 processors and not AMD x86 processors (despite the attempt to make it appear in the press-release as if the vulnerability is widespread among other CPU vendors such as AMD and ARM by simply throwing their brand names into the text); notwithstanding the fact that Intel, Linux kernel lead developers with questionable intentions, and other OS vendors such as Microsoft are keeping their correspondence under embargoes and their Linux kernel update mechanism is less than transparent; notwithstanding the fact that Intel shares are on a slump at the expense of AMD and NVIDIA shares, and CEO Brian Kraznich sold a lot of Intel stock while Intel was secretly firefighting this issue.
The exploits, titled "Meltdown," is rather glaring to be a simple vulnerability, and is described by the people who discovered it, as a bug. Apparently, it lets software running on one virtual machine (VM) access data of another VM, which hits at the very foundations of cloud-computing (integrity and security of virtual machines), and keeps customers wanting cost-effective cloud services at bay. It critically affects the very business models of Amazon, Google, Microsoft, and Alibaba, some of the world's largest cloud computing providers; and strikes at the economics of choosing Intel processors over AMD, in cloud-computing data centers, since the software patches that mitigate the vulnerability, if implemented ethically, significantly reduce performance of machines running Intel processors and not machines running AMD processors (that don't require the patch in the first place). You can read Intel's goalpost-shifting masterpiece after the break.
Linus Torvalds wrote an interesting comment on one of his Linux kernel mailers.
The exploits, titled "Meltdown," is rather glaring to be a simple vulnerability, and is described by the people who discovered it, as a bug. Apparently, it lets software running on one virtual machine (VM) access data of another VM, which hits at the very foundations of cloud-computing (integrity and security of virtual machines), and keeps customers wanting cost-effective cloud services at bay. It critically affects the very business models of Amazon, Google, Microsoft, and Alibaba, some of the world's largest cloud computing providers; and strikes at the economics of choosing Intel processors over AMD, in cloud-computing data centers, since the software patches that mitigate the vulnerability, if implemented ethically, significantly reduce performance of machines running Intel processors and not machines running AMD processors (that don't require the patch in the first place). You can read Intel's goalpost-shifting masterpiece after the break.
Intel Responds to Security Research Findings==END==
Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data.
Recent reports that these exploits are caused by a "bug" or a "flaw" and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices - with many different vendors' processors and operating systems - are susceptible to these exploits.
Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Intel has begun providing software and firmware updates to mitigate these exploits. Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.
Intel is committed to the industry best practice of responsible disclosure of potential security issues, which is why Intel and other vendors had planned to disclose this issue next week when more software and firmware updates will be available. However, Intel is making this statement today because of the current inaccurate media reports.
Check with your operating system vendor or system manufacturer and apply any available updates as soon as they are available. Following good security practices that protect against malware in general will also help protect against possible exploitation until updates can be applied.
Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.
Linus Torvalds wrote an interesting comment on one of his Linux kernel mailers.
From Linus Torvalds <>
Date Wed, 3 Jan 2018 15:51:35 -0800
Subject Re: Avoid speculative indirect calls in kernel
On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen wrote:
> This is a fix for Variant 2 in https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
> Any speculative indirect calls in the kernel can be tricked to execute any kernel code, which may allow side channel attacks that can leak arbitrary kernel data.
Why is this all done without any configuration options?
A *competent* CPU engineer would fix this by making sure speculation doesn't happen across protection domains. Maybe even a L1 I$ that is keyed by CPL.
I think somebody inside of Intel needs to really take a long hard look at their CPU's, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.
.. and that really means that all these mitigation patches should be written with "not all CPU's are crap" in mind.
Or is Intel basically saying "we are committed to selling you shit forever and ever, and never fixing anything"?
Because if that's the case, maybe we should start looking towards the ARM64 people more.
Please talk to management. Because I really see exactly two possibibilities:
Intel never intends to fix anything
OR
these workarounds should have a way to disable them.
Which of the two is it?
Linus
53 Comments on Dear Intel, If a Glaring Exploit Affects Intel CPUs and Not AMD, It's a Flaw
With good code sitting inside a single process, there should be almost no performance changes. Looking forward to your results, xkm1948!Those are superscalar, out of order, speculative architectures too. You have to go down to the original P5 (Pentium) or AM5x86 (predecessor to K5, itself preceding K6, both of which are speculative) architectures to get a non-speculative x86 chip. For those wondering: Pentium Pro to Nehalem/Westmere are more or less P6 in various states of evolution, with NetBurst and Sandy Bridge (the basis of everything from Sandy Bridge all the way up to Coffee Lake and beyond) being the succeeding ground-up x86 architectures. To not leave ARM out in the cold: ARM7 jumped on the pipelined, superscalar, speculative bandwagon circa 2000, and then the out of order bandwagon with the ARM Cortex-A9 around 2010. And finally we have POWER, which had all of those since the first gen in 1990.
For the most part, since the Pentium Pro showed up, all high-performance chips have been at least pipelined, superscalar and speculative, and very often out of order too, which is why Spectre is gonna be such a pain for us for the next 2-4 years.NFS: Payback uses Denuvo as well, but no VMProtect. Despite it's name, VMProtect doesn't use hardware virtualization (read more here) and shouldn't be affected performance-wise since it runs within the same process (same process => no context-switch => doesn't get affected). I'm gonna suspect something else unless VMProtect has changed since 3.5 years ago (which I don't think has happened)
forum.level1techs.com/t/list-of-cpus-most-likely-immune-to-spectre/123128
:D