Retpoline integration

[Mike Hearn]

[fixing the email address for the c2 developer list]

Hi Remi,

Currently unclear: there's this semi-helpful table that suggests it may
still be needed on some chips, for variant 2?

https://docs.google.com/document/d/e/2PACX-1vSMrwkaoSUBAFc6Fjd19F18c1O9pudkfAY-7lGYGOTN8mc9ul-J6pWadcAaBJZcVA7W_3jlLKRtKRbd/pub

Yesterday AMD was saying Spectre doesn't affect them, but it's not clear
from reading the paper that this is really true. ARM's advice is somewhat
similar to retpoline  (insertion of barriers into recompiled code):

https://developer.arm.com/support/security-update/download-the-whitepaper

Also, for variant 1 compiler changes are still being recommended by Google
for anything that compiles and runs sandboxed code, like a JVM. But this
isn't the retpoline, it's a different set of changes.

Still, the news of an impending microcode update is very welcome. It was
not being mentioned yesterday at all, although the ability to patch variant
2 via microcode would seem to be critical information (!). Given that there
was a coordinated embargo it seemed like the workarounds being proposed
yesterday would be finalised, but apparently not.

So, I probably jumped the gun a bit here. Better to wait for activity on
the kernel mailing list to settle down before drawing conclusions on what
the final set of needed fixes are.


On Fri, Jan 05, 2018 at 01:29:30, Remi Forax<forax at univ-mlv.fr>wrote:

> Hi Mike,
> as far as i understand, it seems that at least Intel has provided a patch
> to mitigate CVE-2017-5715 so retpoline may not be necessary [1].
>
> Rémi
> [1] https://security.googleblog.com/2018/01/
> more-details-about-mitigations-for-cpu_4.html
>
> ----- Mail original -----
>
> De: "Mike Hearn" <mike at plan99.net>
> À: graal-dev at openjdk.java.net, hotspot-compiler-dev at mail.openjdk.net
> Envoyé: Jeudi 4 Janvier 2018 15:38:40
> Objet: Retpoline integration
>
> Hello,
>
> I'm sure many of us spent this morning reading about the new set of side
> channel based attacks that dropped today (Spectre and Meltdown
> <https://spectreattack.com/>). Looks like the talk I gave on side
> channels to the Graal team in Zürich may have been well timed!
>
> While some of these attacks are mitigated by kernel changes, Spectre seems
> to have the problematic property that it works across protection domains
> against programs that contain indirect jumps/virtual calls i.e. all of
> them. Programs that contain such code patterns can have sensitive data
> extracted that was meant to be protected by the page table mappings.
>
> There is a fix, at least for the current wave of side channel attacks (we
> will without a doubt see more advanced attacks in future). It is truly
> atrocious but easy to implement inside a JIT compiler. Google describe it
> conceptually here:
>
> https://support.google.com/faqs/answer/7625886
>
> A patch for LLVM is available here - I provide a Google cache link because
> LLVM's review website appears to have been taken offline, probably by
> weight of traffic right now. Arm's website is also hosed, very likely for
> the same reason.
>
> http://webcache.googleusercontent.com/
> search?q=cache%3Ahttps%3A%2F%2Freviews.llvm.
> org%2FD41723&oq=cache%3Ahttps%3A%2F%2Freviews.llvm.
> org%2FD41723&aqs=chrome..69i57j69i58.950j0j4&sourceid=chrome&ie=UTF-8
>
> Essentially all calls that cannot be devirtualised have to jump through a
> special code pattern that has the effect of breaking the speculative
> execution unit on the core (the so-called "ret trampoline" or "retpoline").
> Unfortunately this has a performance impact: LLVM team report about 10% on
> real world software, that's *after* PGO is applied. I hope that the JVM is
> capable of devirtualising more calls than LLVM can.
>
> Please note that the actual code pattern that should be used seems to be
> varying between different projects, perhaps due to the early collapse of
> the security embargo. The Linux kernel is using *lfence* instructions to
> block speculative execution, but the Google web page describes using
> *pause* to put the speculated execution stream into an infinite loop.
> According to a footnote in the Spectre paper *lfence* is sufficient to
> block speculation and Intel is updating their ISA reference to make this
> behaviour officially documented, so *lfence* is probably the one to go for.
>
> Are there any plans to update Graal or C2 to include this optional
> mitigation? (optional because, it only matters if you share your CPU cores
> with untrusted code).
>
>