I’ve tested it with some success on FreeBSD/HardenedBSD on an Intel Xeon. It works on bare metal, but doesn’t work in bhyve.

oh god that runs quickly. terrifying.

$ ./spectre
Reading 40 bytes:
Illegal instruction (core dumped)

That was kinda disappointing. (OpenBSD on Hyper-V here.)

I’m impressed how easy it is to run this PoC - even for somebody who didn’t do C programming for years. Just one file, correct the line

#define CACHE_HIT_THRESHOLD(80)

to

#define CACHE_HIT_THRESHOLD 80

then compile: gcc -O0 -o spectre spectre.c

run:

./spectre

and look for lines with “Success: “.

I am wondering if there is some PoC for JavaScript in the Browser - single HTML page with no dependencies containing everything to show the vulnerability?

I’ve been playing quickly with the PoC. It seems to work just fine on memory with PROT_WRITE only, but doesn’t work on memory protected with PROT_NONE. (At least on my CPU)

From the project zero blog post:

We reported this issue to Intel, AMD and ARM on 2017-06-01

Even if he knew, I think it matters whether this is a recurring event. If he always sells his shares at the end of the year, it would be insane to demand that he doesn’t do it.

Otherwise people could just start shorting as soon as they see an executive not selling stock, because they can infer now that there is some bad news incoming.

And this in the Spectre paper is horrifying:

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.

This is likely an unprecedentedly huge problem for the next several decades (thinking of all the enterprise and embedded systems this affects), and the “mitigation” sections of the papers are not encouraging.

Another good tl;dr

Not right now. I’m sure someone at OpenBSD is looking at it, though.

I’m curious if all the randomization protects machines.

Does anyone know: how can I see whether the version I have has these mitigation(s)? These announcements aren’t explicit about the version numbers that introduce the change.

Seems odd that project zero disclosed this six months ago and so many seem caught off guard. Was the problem only disclosed to CPU vendors and not to OS, compiler, browser vendors? And yet many of the mitigations are only now going into compilers+browsers?

It occurs to me that, in a real and practical sense, one of the biggest exploit mitigations we have at our disposal is the inaccessibility of hardware and kernel architecture knowledge due to complexity. The real reason the systems I’m in charge of aren’t compromised right now (to my knowledge) is because it’s complicated and I’m not on the radar of the few people who can do it.

My understanding (from David May’s lectures and asking lots of questions) is that memory caches are far too much on the hot path (of everything, all the time) to be controlled by microcode.

I remember he mentioned some processor (research? not mainstream, I think) being made with a mechanism wherein you could set a constant in a special register that would be added to the low bits of every physical address before it hit the cache system, so that you could have some user level control of which addresses alias each other. But I got the impression from that conversation that nobody had ever really seriously considered putting anything more than one adder’s worth of gate delays for user control of a cache system because it’s so important to performance and nobody could think of amazingly useful ways that running code could customise cache behaviour that can’t already be achieved well enough anyway using CPU features like prefetches or by cleverly changing the layout of your data structures.

The architecture of snooping caches is ridiculously baroque.

Looking at the Spectre proof of concept code, it looks like there already actually is a way for user mode code to explicitly invalidate a cache line, and it’s used in the attack.

Perhaps a microcode patch could use this feature of the cache to invalidate any cache lines loaded by speculative execution?

AMD’s inability to generate positive PR from this is really an incredible accomplishment for their fabled PR department.

The spectre PoC linked elsewhere in this thread works perfectly on my Ryzen 5. From my reading, it sounds like AMD processors aren’t susceptible to userspace reading kernelspace because the cache is in some sense protection-level-aware, but the speculative-execution, cache-timing one-two punch still works.

From reading the google paper on this it’s not quite true but not quite false. According to google AMD and ARM are vulnerable to a specific limited form of Spectre. They’re not susceptible to Meltdown. The google Spectre PoCs for AMD and ARM aren’t successful in accessing beyond the user’s memory space so it’s thought that while the problem exists in some form it doesn’t lead to compromise as far as we currently know.

I just found this in a Linux kernel commit:

AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

AMD is not vulnerable to Meltdown, an Intel-specific attack.

AMD (and ARM, and essentially anything with a speculative execution engine on the planet) is vulnerable to Spectre.

More bonus link: https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

I believe the only remotely recent Intel chips that completely lack speculative/OoO features are the Atoms based on the first-gen Bonnell microarchitecture. That started off 32-bit-only, but some of them towards the end of the run do have x86-64 support, e.g. the Atom D5xx and S12xx.

And any javascript in your web browser, happily served to you without your knowledge by untrusted third parties.