Retpoline integration

[Jan Stola]

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