Retpoline integration

[Thomas Wuerthinger]

CVE-2017-5753 is not addressed in the linked document. And jcc instructions are quite common. 

A software-level fix for managed languages seems to be to mask the index of array accesses. There is however a performance impact; in particular if the mask should guarantee isolation within the heap and not just isolation of heap vs off-heap accesses (like currently applied in the browser engines). So what one could do is to change every array access code:

array[index]

Into this:

array[min(index, length-1)]

And calculate min(index, length) without any branching via:

array[index + ((length-1-index) & (length-1-index)>>31)]

I created pull request https://github.com/graalvm/graal/pull/279 <https://github.com/graalvm/graal/pull/279> with a patch that performs the modification in Graal to create such a guard for every array access.

- thomas


> On 05.01.2018, at 11:50, Mike Hearn <mike at plan99.net> wrote:
> 
> [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).
>> 
>>