We should quote OpenBSD's Theo de Raadt here, all the way back from 2007:

"x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit."

https://marc.info/?l=openbsd-misc&m=119318909016582&w=2

Hmm. Is OpenBSD patched for Meltdown? I don't see anything on their main site.

> The infrastructure that runs Compute Engine and isolates customer workloads from each other is protected against known attacks. This also means that customer VMs are protected against known, infrastructure-based attacks from other malicious VMs.

Doesn't Google say that they are protected...?

This means that Customer A's VM cannot attack Customer B's VM.

However, if the OS inside the VM is unpatched, then code inside the VM can attack other code inside the VM. If for example you install some malware on your VM, it could use this attack.

(I am not a security expert, this is just my understanding and not a official Google statement)

Right. But it means that once the VM is fixed, assuming the customer does this, they are guarded from such attack right?

Not against Spectre, which can extract any memory via javascript or user applications. Eg your secret keys or passwords

Spectre is a much more serious bug I feel, but it requires the VM to run the malicious code snippet inside itself and with the right context, not from other guest VM, that is how I understand this. The kinda bug that would totally destroy cloud as a business is the one that other guest VM can read your memory...which doesn't seem like to be the case, for now...

Spectre is mostly about JavaScript extracting keys and passwords from the browser process. Install their ChromeZero extension for a start.

Meltdown on the other hand can do everything. But only on Intel.

This basically kills cloud computing for anything sensitive using shared hardware. In the short term this will actually be good for cloud providers because the demand for dedicated instances will shoot up as there is no short-term alternative.

> The infrastructure that runs Compute Engine and isolates customer workloads from each other is protected against known attacks. This also means that customer VMs are protected against known, infrastructure-based attacks from other malicious VMs.

The short term answer is to patch the servers and swallow the 30% performance cut. Still likely cheaper than dedicated servers.

Which could mean huge sales for Intel, or even AMD, if Amazon, DigitalOcean, Linode and others want to rush to get that lost performance back.

Going to AMD would be incredibly expensive as you'd be replacing nearly everything, but if Intel gets new chips out in a reasonable amount of time, they might actually make a killing on this.

"Compute Engine customers must update their virtual machine operating systems and applications so that their virtual machines are protected from intra-guest attacks and inter-guest attacks that exploit application-level vulnerabilities."

"Compute Engine customers should work with their operating system provider(s) to download and install the necessary patches."

Main/Big impacts are on the cloud computer.

For home computer, standard office use, there is no impact at this point, right?

Until someone figures out how to exploit it using JavaScript. The speed this moves it could be any minute now.

From spectre.pdf:

> In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it.

(granted I think site isolation, if enabled, mitigates crossing domain boundaries)

It goes on to show a sample JS impl that JITs into the expected insns using V8.

And we can't even read TFA with javascript disabled, you have to be less secure just to read the google security blog.

Edit - mixing it up with this other article (https://security.googleblog.com/2018/01/todays-cpu-vulnerabi...)

I can read the article without JS just fine.

Yet another argument against running any native or 1-to-1 bytecode in the browser like WASM

the big if is whether javascript code that can exploit this can be written. (edit: that's a yes, from the pdf itself...) if yes, nobody's safe, as any webpage (any webpage, even that ad in an iframe) could in theory read your password if it's anywhere in RAM.

Firefox and Chrome have both started posting mitigation strategies. They're mentioned in other comments, some depending on making time functions less accurate since this is a timing attack.

Chrome is listed as impacted. People use chrome password managers.

Chrome is listed as impacted due to javascript being able to read memory from outside the browser sandbox.

"In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it." - from the spectre paper

Was this quote removed from the article? I'm no longer able to find it.