MeltdownPrime, SpectrePrime: Exploiting Invalidation-Based Coherence Protocols | Hacker News Reader

MeltdownPrime, SpectrePrime: Exploiting Invalidation-Based Coherence Protocols

arxiv.org

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=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 :)

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

The link was changed from this:

"New Spectre/Meltdown Variants"

https://www.schneier.com/blog/archives/2018/02/new_spectreme...

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.

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

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.

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

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

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

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

We've updated the link from https://www.schneier.com/blog/archives/2018/02/new_spectreme..., which points to this.

Reply on news.ycombinator.com