
MeltdownPrime, SpectrePrime: Exploiting Invalidation-Based Coherence Protocols - gregorymichael
https://arxiv.org/pdf/1802.03802.pdf
======
DannyBee
The attacks here are not surprising in the least, FWIW. It was known this
would work, nobody worked up a POC.

The, IMHO, novel part here is the formalism.

(i'm not trying to denigrate the work mind you, it's definitely hard work and
they did a great job. i'm just pointing out for those who don't know that this
is not a surprising new result, but instead an expected new result)

Otherwise, pretty much anyone who had basic architectural knowledge realized
this was possible the second spectre and meltdown came out:

[https://news.ycombinator.com/item?id=16084318](https://news.ycombinator.com/item?id=16084318)

[https://news.ycombinator.com/item?id=16083964](https://news.ycombinator.com/item?id=16083964)

(there are more, i'm too lazy to find everyone who pointed it out, sorry)

I can't speak for gpderetta, but like, if i can predict this problem, I expect
pretty much anyone can :)

~~~
cryptonector
"Not original but formal" is not denigrating, IMO. Formalism is a big deal.

------
rando444
The link was changed from this:

"New Spectre/Meltdown Variants"

[https://www.schneier.com/blog/archives/2018/02/new_spectreme...](https://www.schneier.com/blog/archives/2018/02/new_spectremelt.html)

While the original link didn't provide much extra, what I found particularly
interesting there were the comments from the person who is running a patched
system, yet finding that one of the spectre PoC code examples was still
working.

Would be interesting to know if anyone else is experiencing anything similar.

~~~
bennofs
yes, I am also experiencing this. But this is not unexpected: if you take this
spectre PoC:
[https://github.com/crozone/SpectrePoC/blob/master/spectre.c](https://github.com/crozone/SpectrePoC/blob/master/spectre.c)
then all that is doing is reading data from the same process. With spectre
variant 1, it is the code that is vulnerable (in this case, an unmasked bounds
check). As the compiler does not do any mitigations for this, it is the
software that has to protect against it (that's one reason why browsers for
example needed mitigations, along with everything else running untrusted
code). This variant is only a problem if you're trying to run untrusted code
though... so you could say that the PoC itself has a security vulnerability,
no wonder that still works (an OS does not prevent you from running vulnerable
programs - there could be hardining techniques that can make it harder or
impossible to exploit that vulernerability though.)

------
thom_nic
The real interesting part of this is the formal verification tools they
described which were used to uncover these vulns.

It seems that, while not a silver bullet, FV tools of this sort would be the
most reliable way of discovering (and preventing) these sort of issues in
microarchitecture.

------
chapill
I'm using an aarch64 Chromebook with the A72 cores disabled. The low power A53
quad core is invulnerable, but I'm still disappointed in the lack of response
by Google [1] on this issue with all currently shipping 64-bit ARM
Chromebooks.

[1]
[https://news.ycombinator.com/item?id=16433020](https://news.ycombinator.com/item?id=16433020)

------
Upvoter33
welcome, folks, to what architecture research is going to be focused upon for
the next decade. a good thing, probably -- but there are going to be a lot of
papers like this to wade through....

------
enzanki_ars
Better links from the article (original link before change is only a paragraph
linking to the following article and paper):

[http://www.tomshardware.com/news/new-variants-meltdown-
spect...](http://www.tomshardware.com/news/new-variants-meltdown-spectre-
exploit-discovered,36533.html)

[https://arxiv.org/pdf/1802.03802.pdf](https://arxiv.org/pdf/1802.03802.pdf)

TL;DR:

MeltdownPrime and SpectrePrime are the two new variant names.

From the Tom's Hardware article:

"Princeton and Nvidia researchers teamed up to produce a testing method that
can generate code that represents the essence of an attack. More precisely,
their method is CPU architecture-aware, so it emulates exactly what a software
attack would translate into on the hardware level. According the the
researchers, their tool can be used to quickly generate a set of 'security
litmus tests' for a class of security exploits."

"In the process of their testing, they discovered that the speculative
execution methods that are exploited by the Meltdown and Spectre
vulnerabilities leave a trail that might not be observable in only a CPU's
shared cache, but in its cores' individual caches as well."

"What the researchers discovered is that, because certain caches might be
partially mirrored across cores, the effects of speculative execution
occurring on one core can be detectable on another core. Test cases exploiting
this principle created by the researchers were able to recover hidden data at
99.95% accuracy. By comparison, their test cases of a traditional Spectre
exploit only reached 97.9% accuracy."

"[...] the researchers said that current software-based Meltdown/Spectre
mitigations seem successful in blocking their new exploits. However, these
exploits will likely need their own distinct fix, different from those for
traditional Spectre, if they are to be mitigated in hardware."

------
sctb
We've updated the link from
[https://www.schneier.com/blog/archives/2018/02/new_spectreme...](https://www.schneier.com/blog/archives/2018/02/new_spectremelt.html),
which points to this.

