Google's Project Zero Team Discovered Critical CPU Flaw Last Year (techcrunch.com)

An anonymous reader quotes a report from TechCrunch: In a blog post published minutes ago, Google's Security team announced what they have done to protect Google Cloud customers against the chip vulnerability announced earlier today. They also indicated their Project Zero team discovered this vulnerability last year (although they weren't specific with the timing). The company stated that it informed the chip makers of the issue, which is caused by a process known as "speculative execution." This is an advanced technique that enables the chip to essentially guess what instructions might logically be coming next to speed up execution. Unfortunately, that capability is vulnerable to malicious actors who could access critical information stored in memory, including encryption keys and passwords. According to Google, this affects all chip makers, including those from AMD, ARM and Intel (although AMD has denied they are vulnerable). In a blog post, Intel denied the vulnerability was confined to their chips, as had been reported by some outlets. The Google Security team wrote that they began taking steps to protect Google services from the flaw as soon as they learned about it.

Comments

AMD, ARM mostly immune to the bad stuff

[Anonymous Coward]

There are two exploits revealed here: Meltdown and Phantom

Intel, AMD, and some/all ARM chip are vulnerable to at least one of the two Phantom attacks, but patching Phantom will not produce any significant performance reductions.

At this time, only Intel systems have exhibited vulnerability to Metldown. Patching Meltdown comes with serious consequences.

So AMD is basically correct in stating that they are not in the same position as Intel .

Nope, no virtual machine needed.

[DrYak]

This is more of a server attack and a web host attack.

No, it's not specific to web servers.
They do use web servers as an example of where the exploit might be applied, but it's not specific.

Basically, this exploit allows to abuse the way speculative execution is done to leak information out of the kernel space into the user space.
(And there are presentation at the CCC of successful abuses done... in Javascript. In a browser).

For more details :

most modern CISC processors (Intel - except for Atoms and Xeon Phi - AMD, etc.) are pipelined and do out-of-order execution.
Executing a CISC instruction requires several steps (micro-ops) and for performance reasons, they keep several instruction in flight (Once instruction A goes out of step 1 and into step 2, you can try already pushing instruction B into step 1).
To gain even more performance, CPUs try to be clever about this (instruction B actually needs results of instruction A, so it needs to wait. But the next instruction C actually can already be started, it doesn't depend on anything still in the pipeline).
Bordering on crystal ball-clever (the next instruction B is a conditional jump. But it looks like a loop, so there's a high chance that it will jump back and repeat. We might as well start working back on instruction A, in case we are correct about this jump).
That's speculative execution : working in advance on stuff that might not even be needed.
(Sometimes, you end up needing to bail out of your speculation, throw the work away and restart because you got your crystal ball wrong. But it's better than just sitting there waiting).

now about memory :
any modern processor worth its salt has memory protection, meaning it handles access rights : Which process can read-write which virtual addresses ?
Usually, sensitive information in the OS is shielded away from the regular software.
On a modern Linux, you can't crash the whole system by writing junk at the wrong address, like you used to do in the old MS-DOS days.
If your software attempts to read something out of the system, the read attempt will be rejected.

the exploit relies on how these both play together.

It happens to be that, in the case of Intel's processors (but not of AMD's), the step where the memory page is loaded from the DRAM stick into the cache happens before the check if the read is valid.
By the time the Intel CPU does the check and notice that the read is invalid and rejects it, quite a lot has happened.
(Things got loaded into cache, other instructions have started their speculative execution in the pipeline, etc.)
These things are measurable (you can measure the timing of some computation to guess what's in the cache and what's not).

Meaning that it's possible to leak sensitive information, that normally pertain in to the OS and shouldn't be application-accessible, by doing a ton of such speculative-execution and timings.
At CCC there was some presentation of this done in javascript: Technically, your browser right now could be executing some random javascript shit from some shaddy website in one of your background tabs and trying to learn as much from your OS as possible.
Such information could further be used while mounting privilege escalations, or other attacks.

In the specific situation of AMD processors, the check is done much earlier (according to their lklm post) and thus not much else has happened already, and there's not much leak from which you could learn.

I have no idea how ARM64 are affected. (But it might also be the cache getting populated before the read attempts get rejected).

In all seriousness....

[DrYak]

What about my Commodore 64?

In all seriousness :

- old, in-order, non-pipelined CPU like the 6502 in your good old trusted C64 don't do speculative execution and thus aren't affected specifically by such exploits.

but:

- your 6502 doesn't do any form of memory protection : any piece of software can access any part of the whole system (because poking weird memory location is how you control the hardware on such old system) so any software has full access to anything.
So you C64 is leaking sensitive information.

(Later 68k motorola CPU (68030 and up) eventually started to include an built-in MMU to protect memory access, and thus later Amiga machine featuring them (A2500/30, A3000) can be made imune to OS information leaking into userland. That would the first Comodore hardware - vaguely remote cousin of your C64 - to do so)

Yup, i'm giving a technical answer to a joke.