Just tested this on systems of varying age.

Works on processors going back as far as 2007 (the oldest I have access to now is an Athlon 64 X2 6000+), but the example code relies on an instruction that the Atom D510 does not suport.

Because Spectre seems to be an intrinsic problem with out-of-order execution, which is almost as old as the FDIV bug in intel processors, I would be very surprised if the Atom D510 did not turn out to be susceptible using other methods as outlined in the paper.

EDIT: I originally suspected this instruction was CLFLUSH and erroneously claimed the D510 doesn't support sse2. It does support sse2, so it must be that it does not support the RDTSCP instruction used for timing.

EDIT: This gets very interesting. I made some modifications to use a CPUID followed by RDTSC, which now runs without illegal instructions and works everywhere the previous version worked. Except on the D510, this runs but I cannot get the leak to happen despite exploring values of CACHE_HIT_THRESHOLD. Could the Atom D510 really be immune from Spectre?

The D510 might not have speculative execution. https://en.wikipedia.org/wiki/Bonnell_(microarchitecture)

Certain Atom CPUs have no speculative execution nor OoO execution.

Thanks for this. Would love an annotated version of this if anyone is up for it. My C is pretty good, but some high level "what is being done here" and "this is what shouldn't work" comments would be cool to see.

Worked on a Intel(R) Celeron(R) CPU 847 @ 1.10GHz.

With "gcc (GCC) 7.2.1 20171128", remove the parenthesis from CACHE_HIT_THRESHOLD macro[1] to compile correctly.

[1]: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9...

Worked on my system.

(Set cache_hit_threshold to the default value of 80, my cpu is an Intel i7-6700k.)

I thought it was supposed to be exploitable by javascript? If you can get to the machine and run c code, well, that doesn't seem like an exploit?

At its core both vulnerabilities are essentially local privilege escalation bugs (i.e. a random process can read e.g. secret keys from another process), but that still is a very important exploit - if I can run unprivileged C code on e.g. AWS and are able to read the memory of someone else running on the same shared machine, that's really bad.

The Javascript case is the main one that makes it remotely exploitable.

My understanding is it's anything that can make a running process mis-train the CPU core and read the values back. Consider, for example, shared hosts without separate process pools, running code from different users with the same interpreter processes.

Just because it runs in a C PoC does not mean it only runs in C.

From the Spectre whitepaper:

> 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.

The whitepaper doesn't contain example JS code however

This whitepaper describes the Javascript exploit in Section IV. I'm struggling to understand it though: http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf

This too was provided as a proof of concept (without explanation): https://brainsmoke.github.io/misc/slicepattern.html. I'm not sure what I'm looking at though

This is the first implementation in Javascript I have seen so far: http://xlab.tencent.com/special/spectre/js/check.js

At its core both vulnerabilities are essentially privilege escalation bugs (i.e. a random process can read e.g. secret keys from another process), but the Javascript case is the one that makes it remotely exploitable.

It is.

Work's on Intel® Core™2 Duo Processor T7200. Had to replace __rdtscp(&junk) with __rdtsc(), the Core 2 doesn't have the former.

Works on MacOS 10.13.2.

Looking back, the Mac patches were to address KPTI (Meltdown) which is separate to Spectre.

Terrifyingly, this seems to work on a DigitalOcean droplet. I'm assuming this means people could potentially read memory from other VMs on the same system, albeit with a great deal of difficulty.

So... it reads a string that was declared at the top of the file?