RFR: JDK-8202384: Introduce alternate jvm variant with speculative execution disabled
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Mon Sep 10 08:27:02 UTC 2018
On 2018-09-07 19:30, Erik Joelsson wrote:
> Hello again,
>
> Resurrecting this review. It is now part of proposed JEP and some
> details have changed. The alternate jvm variant is now called
> "nonspeculative", and so is activated with the command line flag
> "-nonspeculative". This is all in line with the proposed JEP.
>
> Differences from last webrev are:
>
> * The name of the new JVM variant
> * Removed an unused AC_SUBST
>
> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.07/index.html
Looks good to me. But what about the change in GensrcJfr.gmk? (I might
have asked about this before...)
/Magnus
>
> /Erik
>
>
> On 2018-06-11 23:29, Magnus Ihse Bursie wrote:
>>
>>
>> On 2018-06-11 22:42, Erik Joelsson wrote:
>>> Hello,
>>>
>>> Based on the discussion here, I have reverted back to something more
>>> similar to webrev.02, but with a few changes. Mainly fixing a bug
>>> that caused JVM_FEATURES_hardened to not actually be the same as for
>>> server (if you have custom additions in configure). I also added a
>>> check so that configure fails if you try to enable either variant
>>> hardened or feature no-speculative-cti and the flags aren't available.
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.05/index.html
>> Looks good to me. Thanks for all the effort!
>>
>> /Magnus
>>
>>>
>>> /Erik
>>>
>>> On 2018-06-11 00:10, Magnus Ihse Bursie wrote:
>>>> On 2018-06-08 23:50, Erik Joelsson wrote:
>>>>> On 2018-06-07 17:30, David Holmes wrote:
>>>>>> On 8/06/2018 6:11 AM, Erik Joelsson wrote:
>>>>>>> I just don't think the extra work is warranted or should be
>>>>>>> prioritized at this point. I also cannot think of a combination
>>>>>>> of options required for what you are suggesting that wouldn't be
>>>>>>> confusing to the user. If someone truly feels like these flags
>>>>>>> are forced on them and can't live with them, we or preferably
>>>>>>> that person can fix it then. I don't think that's dictatorship.
>>>>>>> OpenJDK is still open source and anyone can contribute.
>>>>>>
>>>>>> I don't see why --enable-hardened-jdk and
>>>>>> --enable-hardened-hotspot to add to the right flags would be
>>>>>> either complicated or confusing.
>>>>>>
>>>>> For me the confusion surrounds the difference between
>>>>> --enable-hardened-hotspot and --with-jvm-variants=server, hardened
>>>>> and making the user understand it. But sure, it is doable. Here is
>>>>> a new webrev with those two options as I interpret them. Here is
>>>>> the help text:
>>>>>
>>>>> --enable-hardened-jdk enable hardenening compiler flags for all
>>>>> jdk
>>>>> libraries (except the JVM), typically
>>>>> disabling
>>>>> speculative cti. [disabled]
>>>>> --enable-hardened-hotspot
>>>>> enable hardenening compiler flags for
>>>>> hotspot (all
>>>>> jvm variants), typically disabling
>>>>> speculative cti.
>>>>> To make hardening of hotspot a runtime
>>>>> choice,
>>>>> consider the "hardened" jvm variant
>>>>> instead of this
>>>>> option. [disabled]
>>>>>
>>>>> Note that this changes the default for jdk libraries to not enable
>>>>> hardening unless the user requests it.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/
>>>>
>>>> Hold it, hold it! I'm not sure how we ended up here, but I don't
>>>> like it at all. :-(
>>>>
>>>> I think Eriks initial patch is much better than this. Some
>>>> arguments in random order to defend this position:
>>>>
>>>> 1) Why should we have a configure option to disable security
>>>> relevant flags for the JDK, if there has been no measured negative
>>>> effect? We don't do this for any other compiler flags, especially
>>>> not security relevant ones!
>>>>
>>>> I've re-read the entire thread to see if I could understand what
>>>> could possibly motivate this, but the only thing I can find is
>>>> David Holmes vague fear that these flags would not be well-tested
>>>> enough. Let me counter with my own vague guesses: I believe the
>>>> spectre mitigation methods to have been fully and properly tested,
>>>> since they are rolled-out massively on all products. And let me
>>>> complement with my own fear: the PR catastrophe if OpenJDK were
>>>> *not* built with spectre mitigations, and someone were to exploit
>>>> that!
>>>>
>>>> In fact, I could even argue that "server" should be hardened *by
>>>> default*, and that we should instead introduce a non-hardened JVM
>>>> named something akin to "quick-but-dangerous-server" instead. But I
>>>> realize that a 25% performance hit is hard to swallow, so I won't
>>>> push this agenda.
>>>>
>>>> 2) It is by no means clear that "--enable-hardened-jdk" does not
>>>> harden all aspects of the JDK! If we should keep the option (which
>>>> I definitely do not think we should!) it should be renamed to
>>>> "--enable-hardened-libraries", or something like that. And it
>>>> should be on by default, so it should be a
>>>> "--disabled-hardened-jdk-libraries".
>>>>
>>>> Also, the general-sounding name "hardened" sounds like it might
>>>> encompass more things than it does. What if I disabled a hardened
>>>> jdk build, should I still get stack banging protection? If so, you
>>>> need to move a lot more security-related flags to this option.
>>>> (And, just to be absolutely clear: I don't think you should do that.)
>>>>
>>>> 3) Having two completely different ways of turning on Spectre
>>>> protection for hotspot is just utterly confusing! This was a
>>>> perfect example of how to use the JVM features, just as in the
>>>> original patch.
>>>>
>>>> If you want to have spectre mitigation enabled for both server and
>>>> client, by default, you would just need to run "configure
>>>> --with-jvm-variants=server,client
>>>> --with-jvm-features=no-speculative-cti", which will enable that
>>>> feature for all variants. That's not really hard *at all* for
>>>> anyone building OpenJDK. And it's way clearer what will happen,
>>>> than a --enable-hardened-hotspot.
>>>>
>>>> 4) If you are a downstream provider building OpenJDK and you are
>>>> dead set on not including Spectre mitigations in the JDK libraries,
>>>> despite being shown to have no negative effects, then you can do
>>>> just as any other downstream user with highly specialized
>>>> requirements, and patch the source. I have no sympathies for this;
>>>> I can't stop it but I don't think there's any reason for us to
>>>> complicate the code to support this unlikely case.
>>>>
>>>> So, to recap, I think the webrev as published in
>>>> http://cr.openjdk.java.net/~erikj/8202384/webrev.02/ (with
>>>> "altserver" renamed to "hardened") is the way to go.
>>>>
>>>> /Magnus
>>>>
>>>>
>>>>
>>>>>
>>>>> /Erik
>>>>
>>>
>>
>
More information about the build-dev
mailing list