[jasode]

>Its hard to get your head around how big a deal this is.

It truly is difficult to predict all the ripple effects from this. I can't think of a single computer bug in the last 30 years that's similar in reach to this Intel Meltdown.

[EDITED following text to replace "Intel bug" with "Spectre bug" based on ars and jcranmer clarification. The Intel Meltdown can be fixed with operating system update patches for kpti instead of a complete recompile.]

Journalists like to overuse the bombastic metaphor "shaken the very foundations" but this Spectre bug actually seems very fitting of it. Off the top of my head:

- browsers like Chrome & Firefox have to compile with new defensive compilation flags because it runs untrusted Javascript

- cloud providers have to recompile and patch their code to protect themselves from hostile customer vms

- operating systems like Linux/Windows/MacOS have to recompile and patch code to protect users from malware

Imagine the economics of all these mitigations. Also imagine that each of the cloud vendors AWS/Google/Azure/Rackspace had very detailed Excel spreadsheets extrapolating cpu usage for the next few years to plan for millions of $$$ of capital expenditures. Because of the severe performance implications of the bugfix (5% to 50% slowdown?), the cpu utilization assumptions in those spreadsheets are now wrong. They will have to spend more than they thought they did to meet goals of workload throughput.

There are dozens of other scenarios that we can't immediately think of.

[ars]

> to this Intel Meltdown.

Wrong bug. Intel meltdown is bad, but not anywhere near as bad as Spectre which affects everything! No AMD immunity here.

[kllrnohj]

Meltdown is far worse in practice than Spectre.

Spectre needs a more perfect storm of factors to lead to exploitation. No hardware is immune to it, but not all software is vulnerable, either. You need code execution and you need a vulnerable target and you need to somehow trigger the vulnerable targets path and that vulnerable target needs data you want.

Meltdown just needs code execution and you have full read access to all memory.

[ars]

> Meltdown is far worse in practice than Spectre.

Far worse for an unpached system, yes.

But in terms of fixing the problem, Spectre is much worse, with a larger impact.

It's so bad that I suspect some people will deliberately run without Spectre protection.

[kllrnohj]

Other than javascript in a browser there does not appear to be much in the way of actual spectre attack vectors, though. So once browsers are patched spectre appears to be basically "fixed" for most practical purposes.

Worth noting that many of the claims around Spectre are wholly un-demonstrated. The PoC only involves reading memory from within the same process (aka, the PoC read memory through a side channel that it had full ability to read anyway). Trying to exploit this in a different process is entirely undemonstrated, and there's not even any real discussion in the paper of how it would work. In theory it's doable, but the issues around how you do this once process switching and IPC enters the picture seems substantial yet the paper does not make any attempt to tackle any of that.

[cthalupa]

>Worth noting that many of the claims around Spectre are wholly un-demonstrated.

This is untrue.

https://googleprojectzero.blogspot.com/2018/01/reading-privi...

Variant 2 is Spectre.

"This section describes the theory behind our PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific version of Debian's distro kernel running on the host, can read host kernel memory at a rate of around 1500 bytes/second."

[strongholdmedia]

>>Worth noting that many of the claims around Spectre are wholly un-demonstrated.

>This is untrue.

Anything that is not demonstrated in a reproducible way (that is, some downloadable PoC code) is wholly un-demonstrated. To date, afaik, that goes for Spectre in whole.

[kllrnohj]

Note that variant 2 of spectre has not been demonstrated on AMD and AMD claims to be unaffected ( http://www.amd.com/en/corporate/speculative-execution )

However, the description of spectre from spectreattack.com is this:

"Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets."

That, however, is not demonstrated by any of these PoC, not that I can find.

[jasode]

> Intel meltdown is bad, but not anywhere near as bad as Spectre

I mentioned Meltdown because multiple entities (gcc, llvm, Google Cloud, Azure, Linux, Windows, etc) have already converged on concrete solutions such as new compiler flags and patches which gives us a glimpse into the costs and severity. The Spectre bug may be "bigger" but it doesn't have complete consensus mitigation yet and in the meantime, we really can't tell people to "just keep your laptop unplugged from internet and don't run any apps to avoid the Spectre bug." The Spectre hole seems like it will be an open problem for many years and the new gcc/llvm is an incomplete fix.

[jcranmer]

Meltdown is fixed by page-table isolation (unmap the kernel's pagetables after syscalls are done). All the other bugs are Spectre, and these are the ones that require fixing every compiler.

[ghaff]

This document has performance impact estimates from Red Hat Performance Engineering: https://access.redhat.com/node/3307751

[timeu]

As far as I can tell this only measures the impact of the Meltdown bugifx/kernel patch for Intel CPUs. Would be interesting to see the accumulated impact of the mitigation of Meltdown (KPTI) and Spectre (using Retpolines)

[ghaff]

"The Red Hat Performance Engineering team characterized application workloads to help guide partners and customers on the potential impact of the fixes supplied to correct CVE-2017-5754, CVE-2017-5753 and CVE-2017-5715, including OEM microcode, Red Hat Enterprise Linux kernel, and virtualization patches."

The numbers seem to be for patches on several Intel CPUs for all three of the disclosed vulnerabilities. [reworded]

[baq]

they'll be releasing a fix for RHEL 5. hats off to these gentlemen as the patches probably aren't anywhere close to applyable.

[strongholdmedia]

> - browsers like Chrome & Firefox have to compile with new defensive compilation flags because it runs untrusted Javascript

Not meaning to be that rude, yet this itself summarises (and the issue perhaps will shed more light on) how stupid an idea is to let everybody run untrusted code from other peoples, let alone third party stuff like "privacy-intrusion-as-a-service" startups et aliae.

[late2part]

That won’t really be a problem for the cloud providers. That simply charge more because the customers will use more compute.

[jacksmith21006]

But it will cost them on I/O which they can not be passed to consumers as the price is contractual. Either the cloud providers on the hook or have to pass it somehow to Intel.

[Kristine1975]

Which in some cases might make it cheaper for customers to use their own hardware, resulting in cloud providers losing business.

[alanfalcon]

Maybe. But their own hardware will also be slower, no?

[bluGill]

Maybe. When it is your own hardware you can do a different risk analysis. If you control all the code that runs on the system you don't need any mitigation. Most servers don't run arbitrary code form the internet - at least not intentionally. (a security hole that allows remote code execution is a real issue, but that risk can be managed)

My company doesn't need to mitigate the risk of me using these tricks. I'm not going to, but even if I was I have many other ways to get at sensitive data if I tried. If I get caught I'm fired and put in prison which is enough mitigation.

[ikeyany]

Is this a 5% to 50% performance hit on all workloads or specific workloads?

[TheCycoONE]

The 50% was for a microbenchmark of C++ code making heavy use of virtual. V-tables and jump tables get much more expensive. Any execution path that is known at compile time is not affected.

[nikanj]

I wonder where that leaves Java, C#, Node.js etc. Do the VMs generate code that suffers from this?

[Matthias247]

Hmm, interesting question. On the hand JITs do devirtualization, so that on lots of code paths the indirect calls are replaced with direct ones. Which should mitigate the performance issues. However I think the JITs also need to insert the logic and branches for re-jitting and spectreulative execution. These might be additional indirect calls.

Would be interesting how it balances out in total.

[DannyBee]

yes