Retpoline integration

Mon Jan 8 17:47:39 UTC 2018

Yes, you are right, I also need to make sure the index is >= 0, which is fortunately just a single additional “and" assembly instruction.

- thomas

> On 07.01.2018, at 21:34, Jan Stola <jan.stola at oracle.com> wrote:
> 
> array[min(index, length-1)] blocks the access to indices that are too large. It does not help against indices that are too small (i.e. negative). Don't you need also max the result with 0?
> 
> Honza
> 
> On 7.1.2018 19:35, Thomas Wuerthinger wrote:
>> 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).
>>>> 
>>>> 
>> 
> 