Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Magnus Ihse Bursie]

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 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[jesper . wilhelmsson]

Looks good to me.
/Jesper

> On 11 Jun 2018, at 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
> 
> /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 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Erik Joelsson]

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

/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 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[David Holmes]

Sorry this is making my head spin.

Doh! jvm-features only apply to the JVM.

So I retract my last email - sorry.

And with that I'm going to just bow out. You and Erik can figure it out.

Thanks,
David

On 11/06/2018 6:19 PM, Magnus Ihse Bursie wrote:


On 2018-06-11 09:38, David Holmes wrote:

Hi Magnus,

On 11/06/2018 5:10 PM, 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!


All I'm looking for is the ability to select whether you can build 
with or without this "hardening". The default OpenJDK build can of 
course churn out a "hardened" implementation. Anyone who opts out of 
that is on their own.


With Erik's original proposal (webrev.02), you will, by default, get a 
hotspot "server" JVM variant that is identical to what you got without 
the patch. This should definitely cover your case.


You will also get all the non-hotspot libraries built as hardened. You 
*can* get the JDK libraries built non-hardened, by removing the 
${$2NO_SPECULATIVE_CTI_CFLAGS} from the line 
$1_CFLAGS_JDK="${$1_DEFINES_CPU_JDK} ${$1_CFLAGS_CPU} 
${$1_CFLAGS_CPU_JDK} ${$1_TOOLCHAIN_CFLAGS} 
${$2NO_SPECULATIVE_CTI_CFLAGS}".


As I said, I believe this is enough to support that case.



I don't share your faith or confidence in the quality of any software 
rushed out in a fairly short space of time. Prudence, if nothing else, 
says you should be able to not build this way IMHO.
AFAIU, these compiler flags has received extensive testing inside 
Oracle. It is also part of a global, high-visibility project, where key 
players have had time to prepare for handling the issues ahead of the 
public awareness of the exploits. *And* it's been almost half a year 
since the Spectre exploit was made public.


I have much more faith in enabling these flags than I'd have for e.g. 
upgrading to a newer version of Solaris Studio. :-)





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 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Magnus Ihse Bursie]

On 2018-06-11 09:38, David Holmes wrote:

Hi Magnus,

On 11/06/2018 5:10 PM, 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!


All I'm looking for is the ability to select whether you can build 
with or without this "hardening". The default OpenJDK build can of 
course churn out a "hardened" implementation. Anyone who opts out of 
that is on their own.


With Erik's original proposal (webrev.02), you will, by default, get a 
hotspot "server" JVM variant that is identical to what you got without 
the patch. This should definitely cover your case.


You will also get all the non-hotspot libraries built as hardened. You 
*can* get the JDK libraries built non-hardened, by removing the 
${$2NO_SPECULATIVE_CTI_CFLAGS} from the line 
$1_CFLAGS_JDK="${$1_DEFINES_CPU_JDK} ${$1_CFLAGS_CPU} 
${$1_CFLAGS_CPU_JDK} ${$1_TOOLCHAIN_CFLAGS} ${$2NO_SPECULATIVE_CTI_CFLAGS}".


As I said, I believe this is enough to support that case.



I don't share your faith or confidence in the quality of any software 
rushed out in a fairly short space of time. Prudence, if nothing else, 
says you should be able to not build this way IMHO.
AFAIU, these compiler flags has received extensive testing inside 
Oracle. It is also part of a global, high-visibility project, where key 
players have had time to prepare for handling the issues ahead of the 
public awareness of the exploits. *And* it's been almost half a year 
since the Spectre exploit was made public.


I have much more faith in enabling these flags than I'd have for e.g. 
upgrading to a newer version of Solaris Studio. :-)





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. 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[David Holmes]

Hi Magnus,

On 11/06/2018 5:10 PM, 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!


All I'm looking for is the ability to select whether you can build with 
or without this "hardening". The default OpenJDK build can of course 
churn out a "hardened" implementation. Anyone who opts out of that is on 
their own.


I don't share your faith or confidence in the quality of any software 
rushed out in a fairly short space of time. Prudence, if nothing else, 
says you should be able to not build this way IMHO.


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.


Okay. I have had some confusion over "features" versus "variants" based 
on Eriks earlier comments. Erik's email from June 6 first states:


"I agree, and you sort of can. By adding the jvm feature 
"no-speculative-cti" to any jvm variant, you get the flags."


but then later said:

"We don't see the point in giving the choice on the JDK libraries ..."

by which I now think he meant not giving the choice at the VM variant 
level, but I mistook it for meaning at the "feature" level. Hence I came 
back with the two flags suggestion. If we can already select features 
arbitrarily at configure time then this is all addressed already.

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Magnus Ihse Bursie]

On 2018-06-10 15:28, David Holmes wrote:

On 9/06/2018 7:50 AM, 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 


That's the problem: "hardened" is not a jvm-variant as we have always 
defined that! "hardened" is a variation in the same way as product vs 
fastdebug versus slow-debug versus (the old) optimized. It is _not_ at 
all the same kind of thing as server versus client versus zero etc. 
The desire to ship "hardened" in the same image as non-hardened is 
what is causing the semantic conflict here. It is like shipping a 
product and debug VM together. Sure you can do it, but that's not how 
we've categorised things in the past.
I disagree. The "no-speculative-cti" is a perfectly fine JVM feature, 
which can be applied to any JVM variant. It is not a JVM feature as a 
separate software component (like cmsgc or compiler1) that could be left 
in or kept out and that affects the functionality of hotspot. Instead, 
it is a JVM feature very much like the existing link-time-opt, in that 
it affects all aspects of the JVM; not the functionality, but the 
performance (and security).


The way we bundle a certain set of JVM features as a named JVM variant 
has always been a bit, well, semantically odd, but it has served us okay 
in the past and serve us just as well for this fix.




I understand the need to make things work this way, so in that sense 
selecting jvm-variant=hardened should be seen as specifying 
"--enable-hardened-hotspot --enable-hardened-jdk". But 
jvm-variant=hardened is really jvm-variant=hardened-server.
Yes, jvm-variant=hardened is actually hardned-server. Despite the longer 
name, it might be more clear to use that name. It ties in into a bit 
into Erik's original "altserver" proposal.


I think the reason just "hardened" sounds like a reasonable alternative 
to the more proper but longer "hardened-server" is due to how "server" 
has become the mainstream variant, even for clients, and "client" feels 
like it's being put on death row. Nobody really believes that it will 
survive in the long term, and nowadays Oracle don't even build it 
anymore (we stopped doing that when we stopped doing 32-bit builds). So 
"server" is increasingly incorrectly named, and should really just be 
considered a legacy name for what should perhaps be "default" or so.


/Magnus



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.


That's your call. I don't care what the default is as long as the 
developer has control over it.


Thanks,
David


Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/

/Erik

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Magnus Ihse Bursie]

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

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[David Holmes]

On 9/06/2018 7:50 AM, 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 


That's the problem: "hardened" is not a jvm-variant as we have always 
defined that! "hardened" is a variation in the same way as product vs 
fastdebug versus slow-debug versus (the old) optimized. It is _not_ at 
all the same kind of thing as server versus client versus zero etc. The 
desire to ship "hardened" in the same image as non-hardened is what is 
causing the semantic conflict here. It is like shipping a product and 
debug VM together. Sure you can do it, but that's not how we've 
categorised things in the past.


I understand the need to make things work this way, so in that sense 
selecting jvm-variant=hardened should be seen as specifying 
"--enable-hardened-hotspot --enable-hardened-jdk". But 
jvm-variant=hardened is really jvm-variant=hardened-server.


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.


That's your call. I don't care what the default is as long as the 
developer has control over it.


Thanks,
David


Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/

/Erik

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Erik Joelsson]

Doh, thanks, updated in place.

/Erik


On 2018-06-08 14:53, Daniel D. Daugherty wrote:

On 6/8/18 5:50 PM, 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


Typo: 'hardenening' -> 'hardening'



libraries (except the JVM), typically disabling
  speculative cti. [disabled]
 --enable-hardened-hotspot
  enable hardenening compiler flags for 
hotspot (all


Typo: 'hardenening' -> 'hardening'



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/

/Erik


Dan

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Daniel D. Daugherty]

On 6/8/18 5:50 PM, 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


Typo: 'hardenening' -> 'hardening'



libraries (except the JVM), typically disabling
  speculative cti. [disabled]
 --enable-hardened-hotspot
  enable hardenening compiler flags for 
hotspot (all


Typo: 'hardenening' -> 'hardening'



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/

/Erik


Dan

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Erik Joelsson]

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/

/Erik

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[David Holmes]

On 8/06/2018 6:11 AM, Erik Joelsson wrote:

On 2018-06-07 11:56, jesper.wilhelms...@oracle.com wrote:
On 6 Jun 2018, at 06:17, David Holmes > wrote:


Hi Erik, Jesper,


So "benevolent dictatorship"?  ;-)

My main concern is that the updated toolchains that support this have 
all been produced in a mad rush and quite frankly I expect them to be 
buggy. I don't think it is hard to enable the builder of OpenJDK to 
have full choice and control here.


My assumption has been, and still is, that we're not the only ones 
that will use gcc 7.3.0 with these flags. If there were bugs in the 
new code they would most likely have been found already. The 
experience from our own work in this area is that the bugs are 
unlikely to be crashes due to the new code, but rather weird corner 
cases where the new code is not inserted where it was needed, leaving 
speculative execution unblocked in that single case.


That said, I have no strong opinions on what is possible to configure 
in the build, as long as the Oracle OpenJDK builds comes with two JVM 
libraries and one copy of all other libraries. But that is of course a 
slightly different issue as long as it is possible to do.


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.


David


/Erik

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Erik Joelsson]

On 2018-06-07 11:56, jesper.wilhelms...@oracle.com wrote:
On 6 Jun 2018, at 06:17, David Holmes > wrote:


Hi Erik, Jesper,


So "benevolent dictatorship"?  ;-)

My main concern is that the updated toolchains that support this have 
all been produced in a mad rush and quite frankly I expect them to be 
buggy. I don't think it is hard to enable the builder of OpenJDK to 
have full choice and control here.


My assumption has been, and still is, that we're not the only ones 
that will use gcc 7.3.0 with these flags. If there were bugs in the 
new code they would most likely have been found already. The 
experience from our own work in this area is that the bugs are 
unlikely to be crashes due to the new code, but rather weird corner 
cases where the new code is not inserted where it was needed, leaving 
speculative execution unblocked in that single case.


That said, I have no strong opinions on what is possible to configure 
in the build, as long as the Oracle OpenJDK builds comes with two JVM 
libraries and one copy of all other libraries. But that is of course a 
slightly different issue as long as it is possible to do.


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.


/Erik

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[jesper . wilhelmsson]

> On 6 Jun 2018, at 06:17, David Holmes  wrote:
> 
> Hi Erik, Jesper,
> 
> On 6/06/2018 2:59 AM, jesper.wilhelms...@oracle.com 
>  wrote:
>>> On 5 Jun 2018, at 08:10, David Holmes  wrote:
>>> 
>>> Sorry to be late to this party ...
>>> 
>>> On 5/06/2018 6:10 AM, Erik Joelsson wrote:
 New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
 Renamed the new jvm variant to "hardened".
>>> 
>>> As it is a hardened server build I'd prefer if that were somehow reflected 
>>> in the name. Though really I don't see why this should be restricted this 
>>> way ... to be honest I don't see hardened as a variant of server vs. client 
>>> vs. zero etc at all, you should be able to harden any of those.
>>> 
>>> So IIUC with this change we will:
>>> - always build JDK native code "hardened" (if toolchain supports it)
>>> - only build hotspot "hardened" if requested; and in that case
>>>  - jvm.cfg will list -server and -hardened with server as default
>>> 
>>> Is that right? I can see that we may choose to always build Oracle JDK this 
>>> way but it isn't clear to me that its suitable for OpenJDK. Nor why hotspot 
>>> is selectable but JDK is not. ??
>> Sorry for the lack of information here. There has been a lot of off-list 
>> discussions behind this change, I've added the background to the bug now.
>> The short version is that we see a ~25% regression in startup times if the 
>> JVM is compiled with the gcc flags to avoid speculative execution. We have 
>> not observed any performance regressions due to compiling the rest of the 
>> native libraries with these gcc flags, so there doesn't seem to be any 
>> reason to have different versions of other libraries.
> 
> So "benevolent dictatorship"?  ;-)
> 
> My main concern is that the updated toolchains that support this have all 
> been produced in a mad rush and quite frankly I expect them to be buggy. I 
> don't think it is hard to enable the builder of OpenJDK to have full choice 
> and control here.

My assumption has been, and still is, that we're not the only ones that will 
use gcc 7.3.0 with these flags. If there were bugs in the new code they would 
most likely have been found already. The experience from our own work in this 
area is that the bugs are unlikely to be crashes due to the new code, but 
rather weird corner cases where the new code is not inserted where it was 
needed, leaving speculative execution unblocked in that single case.

That said, I have no strong opinions on what is possible to configure in the 
build, as long as the Oracle OpenJDK builds comes with two JVM libraries and 
one copy of all other libraries. But that is of course a slightly different 
issue as long as it is possible to do.

Thanks,
/Jesper

> 
> Cheers,
> David
> 
>> /Jesper
>>> Sorry.
>>> 
>>> David
>>> -
>>> 
 /Erik
 On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:
>> On 4 Jun 2018, at 17:52, Erik Joelsson  wrote:
>> 
>> Hello,
>> 
>> On 2018-06-01 14:00, Aleksey Shipilev wrote:
>>> On 06/01/2018 10:53 PM, Erik Joelsson wrote:
 This patch defines flags for disabling speculative execution for GCC 
 and Visual Studio and applies
 them to all binaries except libjvm when available in the compiler. It 
 defines a new jvm feature
 no-speculative-cti, which is used to control whether to use the flags 
 for libjvm. It also defines a
 new jvm variant "altserver" which is the same as server, but with this 
 new feature added.
>>> I think the classic name for such product configuration is "hardened", 
>>> no?
>> I don't know. I'm open to suggestions on naming.
> "hardened" sounds good to me.
> 
> The change looks good as well.
> /Jesper
> 
>> /Erik
>>> -Aleksey

RE: RFR: JDK-8202384: Introduce altserver jvm variant with

[Baesken, Matthias]

Thanks for the clarification !

From: Erik Joelsson [mailto:erik.joels...@oracle.com]
Sent: Dienstag, 5. Juni 2018 17:51
To: Baesken, Matthias ; 
'hotspot-...@openjdk.java.net' ; 
'build-dev@openjdk.java.net' 
Cc: Zeller, Arno 
Subject: Re: RFR: JDK-8202384: Introduce altserver jvm variant with


Hello Matthias,

For GCC, you need 7.3.0 or later. For Microsoft you need VS2017 and I think 
some minimal update version (the option is called -Qspectre), we use 15.5.5.

I was not involved in the benchmarking so I don't know any details there, only 
the conclusion.

/Erik

On 2018-06-05 01:30, Baesken, Matthias wrote:

Hi Erik , is there  some info available about  the performance impact when  
disabling  disabling speculative execution  ?



And which compiler versions are needed for this ?



Best regards, Matthias





>We need to add compilation flags for disabling speculative execution to

>our native libraries and executables. In order to allow for users not

>affected by problems with speculative execution to run a JVM at full

>speed, we need to be able to ship two JVM libraries - one that is

>compiled with speculative execution enabled, and one that is compiled

>without. Note that this applies to the build time C++ flags, not the

>compiler in the JVM itself. Luckily adding these flags to the rest of

>the native libraries did not have a significant performance impact so

>there is no need for making it optional there.

>

>This patch defines flags for disabling speculative execution for GCC and

>Visual Studio and applies them to all binaries except libjvm when

>available in the compiler. It defines a new jvm feature

>no-speculative-cti, which is used to control whether to use the flags

>for libjvm. It also defines a new jvm variant "altserver" which is the

>same as server, but with this new feature added.

>

>For Oracle builds, we are changing the default for linux-x64 and

>windows-x64 to build both server and altserver, giving the choice to the

>user which JVM they want to use. If others would prefer this default, we

>could make it default in configure as well.

>

>The change in GensrcJFR.gmk fixes a newly introduced race that appears

>when building multiple jvm variants.

>

>Bug: https://bugs.openjdk.java.net/browse/JDK-8202384

>

>Webrev: 
>http://cr.openjdk.java.net/~erikj/8202384/webrev.01<http://cr.openjdk.java.net/%7Eerikj/8202384/webrev.01>

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[David Holmes]

Hi Erik, Jesper,

On 6/06/2018 2:59 AM, jesper.wilhelms...@oracle.com wrote:

On 5 Jun 2018, at 08:10, David Holmes  wrote:

Sorry to be late to this party ...

On 5/06/2018 6:10 AM, Erik Joelsson wrote:

New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
Renamed the new jvm variant to "hardened".


As it is a hardened server build I'd prefer if that were somehow reflected in 
the name. Though really I don't see why this should be restricted this way ... 
to be honest I don't see hardened as a variant of server vs. client vs. zero 
etc at all, you should be able to harden any of those.

So IIUC with this change we will:
- always build JDK native code "hardened" (if toolchain supports it)
- only build hotspot "hardened" if requested; and in that case
  - jvm.cfg will list -server and -hardened with server as default

Is that right? I can see that we may choose to always build Oracle JDK this way 
but it isn't clear to me that its suitable for OpenJDK. Nor why hotspot is 
selectable but JDK is not. ??


Sorry for the lack of information here. There has been a lot of off-list 
discussions behind this change, I've added the background to the bug now.

The short version is that we see a ~25% regression in startup times if the JVM 
is compiled with the gcc flags to avoid speculative execution. We have not 
observed any performance regressions due to compiling the rest of the native 
libraries with these gcc flags, so there doesn't seem to be any reason to have 
different versions of other libraries.


So "benevolent dictatorship"?  ;-)

My main concern is that the updated toolchains that support this have 
all been produced in a mad rush and quite frankly I expect them to be 
buggy. I don't think it is hard to enable the builder of OpenJDK to have 
full choice and control here.


Cheers,
David


/Jesper


Sorry.

David
-


/Erik
On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:

On 4 Jun 2018, at 17:52, Erik Joelsson  wrote:

Hello,

On 2018-06-01 14:00, Aleksey Shipilev wrote:

On 06/01/2018 10:53 PM, Erik Joelsson wrote:

This patch defines flags for disabling speculative execution for GCC and Visual 
Studio and applies
them to all binaries except libjvm when available in the compiler. It defines a 
new jvm feature
no-speculative-cti, which is used to control whether to use the flags for 
libjvm. It also defines a
new jvm variant "altserver" which is the same as server, but with this new 
feature added.

I think the classic name for such product configuration is "hardened", no?

I don't know. I'm open to suggestions on naming.

"hardened" sounds good to me.

The change looks good as well.
/Jesper


/Erik

-Aleksey

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[jesper . wilhelmsson]

> On 5 Jun 2018, at 08:10, David Holmes  wrote:
> 
> Sorry to be late to this party ...
> 
> On 5/06/2018 6:10 AM, Erik Joelsson wrote:
>> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
>> Renamed the new jvm variant to "hardened".
> 
> As it is a hardened server build I'd prefer if that were somehow reflected in 
> the name. Though really I don't see why this should be restricted this way 
> ... to be honest I don't see hardened as a variant of server vs. client vs. 
> zero etc at all, you should be able to harden any of those.
> 
> So IIUC with this change we will:
> - always build JDK native code "hardened" (if toolchain supports it)
> - only build hotspot "hardened" if requested; and in that case
>  - jvm.cfg will list -server and -hardened with server as default
> 
> Is that right? I can see that we may choose to always build Oracle JDK this 
> way but it isn't clear to me that its suitable for OpenJDK. Nor why hotspot 
> is selectable but JDK is not. ??

Sorry for the lack of information here. There has been a lot of off-list 
discussions behind this change, I've added the background to the bug now.

The short version is that we see a ~25% regression in startup times if the JVM 
is compiled with the gcc flags to avoid speculative execution. We have not 
observed any performance regressions due to compiling the rest of the native 
libraries with these gcc flags, so there doesn't seem to be any reason to have 
different versions of other libraries.

/Jesper

> Sorry.
> 
> David
> -
> 
>> /Erik
>> On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:
 On 4 Jun 2018, at 17:52, Erik Joelsson  wrote:
 
 Hello,
 
 On 2018-06-01 14:00, Aleksey Shipilev wrote:
> On 06/01/2018 10:53 PM, Erik Joelsson wrote:
>> This patch defines flags for disabling speculative execution for GCC and 
>> Visual Studio and applies
>> them to all binaries except libjvm when available in the compiler. It 
>> defines a new jvm feature
>> no-speculative-cti, which is used to control whether to use the flags 
>> for libjvm. It also defines a
>> new jvm variant "altserver" which is the same as server, but with this 
>> new feature added.
> I think the classic name for such product configuration is "hardened", no?
 I don't know. I'm open to suggestions on naming.
>>> "hardened" sounds good to me.
>>> 
>>> The change looks good as well.
>>> /Jesper
>>> 
 /Erik
> -Aleksey
> 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Volker Simonis]

On Tue, Jun 5, 2018 at 6:47 PM, Erik Joelsson  wrote:
> Hello Volker,
>
> On 2018-06-05 09:35, Volker Simonis wrote:
>>
>> Hi Erik,
>>
>> you wrote: "Note that this applies to the build time C++ flags, not
>> the compiler in the JVM itself." So what about the code generated by
>> the HotSpot (i.e. stubs, template interpreter, c1, c2, Graal)? Is this
>> code already "hardened" against speculative execution? If yes, that's
>> fine, if not, I don't see the point in hardening the HotSpot code
>> itself if the VM still generates potentially "insecure" code.
>
> Correct. These are just the build changes for the build time compiler
> options. Further work will be done by Hotspot engineers.
>>
>> And I still don't fully understand how things work if you build both
>> variants by default (as you intend to do it for Oracle builds). Will
>> you end up with two subdirectories (lib/server/ and lib/altserver)
>> where both contain a libjvm.so and the user can use "java -altserver"
>> on the command line to choose the hardened version?
>
> Correct, we use the old jvm variant mechanism, so this will work just like
> -server/-client used to work, two completely separate libjvm.so in separate
> sub directories.
>

OK. Thanks for the quick confirmation.

> /Erik
>
>> Thank you and best regards,
>> Volker
>>
>>
>> On Tue, Jun 5, 2018 at 5:47 PM, Erik Joelsson 
>> wrote:
>>>
>>> Hello,
>>>
>>> On 2018-06-04 23:10, David Holmes wrote:

 Sorry to be late to this party ...

 On 5/06/2018 6:10 AM, Erik Joelsson wrote:
>
> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
>
> Renamed the new jvm variant to "hardened".


 As it is a hardened server build I'd prefer if that were somehow
 reflected
 in the name. Though really I don't see why this should be restricted
 this
 way ... to be honest I don't see hardened as a variant of server vs.
 client
 vs. zero etc at all, you should be able to harden any of those.

>>> I agree, and you sort of can. By adding the jvm feature
>>> "no-speculative-cti"
>>> to any jvm variant, you get the flags. The name of the predefined variant
>>> can be discussed. I initially suggested altserver because I, as you,
>>> thought
>>> it should include server in the name. But ultimately, I don't care that
>>> much
>>> about a name. There is also little point in defining a whole set of
>>> predefined variants that nobody has requested. If we ever need more
>>> specialized variants in the same image, we will add them.

 So IIUC with this change we will:
 - always build JDK native code "hardened" (if toolchain supports it)
>>>
>>> Yes, this is correct. The reason being that no significant performance
>>> impact was detected, so there is no cost.

 - only build hotspot "hardened" if requested; and in that case
- jvm.cfg will list -server and -hardened with server as default
>>>
>>> Correct.


 Is that right? I can see that we may choose to always build Oracle JDK
 this way but it isn't clear to me that its suitable for OpenJDK. Nor why
 hotspot is selectable but JDK is not. ??

>>> We would prefer to always build with security features enabled, but the
>>> performance impact on the JVM is so high that we want to leave it to the
>>> user to decide, both at bulid time and at runtime. With these changes,
>>> Oracle will build OracleJDK, and OpenJDK, with dual JVMs by default, but
>>> any
>>> other person or entity just building the OpenJDK source will just get the
>>> server variant for now (as has been the default for a long time), unless
>>> they specifically ask for "hardened" or activate the new jvm feature
>>> (--with-jvm-feature=no-speculative-cti).
>>>
>>> We don't see the point in giving the choice on the JDK libraries simply
>>> because there is no drawback to enabling the flags.
>>>
>>> /Erik
>>>
 Sorry.

 David
 -

> /Erik
>
>
> On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:
>>>
>>> On 4 Jun 2018, at 17:52, Erik Joelsson 
>>> wrote:
>>>
>>> Hello,
>>>
>>> On 2018-06-01 14:00, Aleksey Shipilev wrote:

 On 06/01/2018 10:53 PM, Erik Joelsson wrote:
>
> This patch defines flags for disabling speculative execution for
> GCC
> and Visual Studio and applies
> them to all binaries except libjvm when available in the compiler.
> It
> defines a new jvm feature
> no-speculative-cti, which is used to control whether to use the
> flags
> for libjvm. It also defines a
> new jvm variant "altserver" which is the same as server, but with
> this new feature added.

 I think the classic name for such product configuration is
 "hardened",
 no?
>>>
>>> I don't know. I'm open to suggestions on naming.
>>
>> "hardened" sounds good to me.
>>
>> The 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with

[Erik Joelsson]

Hello again,

Looks like Jesper updated the bug description with more info.

/Erik


On 2018-06-05 08:50, Erik Joelsson wrote:

Hello Matthias,

For GCC, you need 7.3.0 or later. For Microsoft you need VS2017 and I 
think some minimal update version (the option is called -Qspectre), we 
use 15.5.5.


I was not involved in the benchmarking so I don't know any details 
there, only the conclusion.


/Erik


On 2018-06-05 01:30, Baesken, Matthias wrote:


Hi Erik , is there  some info available about  the performance impact 
when  disabling  disabling speculative execution  ?


And which compiler versions are needed for this ?

Best regards, Matthias

>We need to add compilation flags for disabling speculative execution to

>our native libraries and executables. In order to allow for users not

>affected by problems with speculative execution to run a JVM at full

>speed, we need to be able to ship two JVM libraries - one that is

>compiled with speculative execution enabled, and one that is compiled

>without. Note that this applies to the build time C++ flags, not the

>compiler in the JVM itself. Luckily adding these flags to the rest of

>the native libraries did not have a significant performance impact so

>there is no need for making it optional there.

>

>This patch defines flags for disabling speculative execution for GCC 
and


>Visual Studio and applies them to all binaries except libjvm when

>available in the compiler. It defines a new jvm feature

>no-speculative-cti, which is used to control whether to use the flags

>for libjvm. It also defines a new jvm variant "altserver" which is the

>same as server, but with this new feature added.

>

>For Oracle builds, we are changing the default for linux-x64 and

>windows-x64 to build both server and altserver, giving the choice to 
the


>user which JVM they want to use. If others would prefer this 
default, we


>could make it default in configure as well.

>

>The change in GensrcJFR.gmk fixes a newly introduced race that appears

>when building multiple jvm variants.

>

>Bug: https://bugs.openjdk.java.net/browse/JDK-8202384

>

>Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.01 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Erik Joelsson]

Hello Volker,

On 2018-06-05 09:35, Volker Simonis wrote:

Hi Erik,

you wrote: "Note that this applies to the build time C++ flags, not
the compiler in the JVM itself." So what about the code generated by
the HotSpot (i.e. stubs, template interpreter, c1, c2, Graal)? Is this
code already "hardened" against speculative execution? If yes, that's
fine, if not, I don't see the point in hardening the HotSpot code
itself if the VM still generates potentially "insecure" code.
Correct. These are just the build changes for the build time compiler 
options. Further work will be done by Hotspot engineers.

And I still don't fully understand how things work if you build both
variants by default (as you intend to do it for Oracle builds). Will
you end up with two subdirectories (lib/server/ and lib/altserver)
where both contain a libjvm.so and the user can use "java -altserver"
on the command line to choose the hardened version?
Correct, we use the old jvm variant mechanism, so this will work just 
like -server/-client used to work, two completely separate libjvm.so in 
separate sub directories.


/Erik

Thank you and best regards,
Volker


On Tue, Jun 5, 2018 at 5:47 PM, Erik Joelsson  wrote:

Hello,

On 2018-06-04 23:10, David Holmes wrote:

Sorry to be late to this party ...

On 5/06/2018 6:10 AM, Erik Joelsson wrote:

New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/

Renamed the new jvm variant to "hardened".


As it is a hardened server build I'd prefer if that were somehow reflected
in the name. Though really I don't see why this should be restricted this
way ... to be honest I don't see hardened as a variant of server vs. client
vs. zero etc at all, you should be able to harden any of those.


I agree, and you sort of can. By adding the jvm feature "no-speculative-cti"
to any jvm variant, you get the flags. The name of the predefined variant
can be discussed. I initially suggested altserver because I, as you, thought
it should include server in the name. But ultimately, I don't care that much
about a name. There is also little point in defining a whole set of
predefined variants that nobody has requested. If we ever need more
specialized variants in the same image, we will add them.

So IIUC with this change we will:
- always build JDK native code "hardened" (if toolchain supports it)

Yes, this is correct. The reason being that no significant performance
impact was detected, so there is no cost.

- only build hotspot "hardened" if requested; and in that case
   - jvm.cfg will list -server and -hardened with server as default

Correct.


Is that right? I can see that we may choose to always build Oracle JDK
this way but it isn't clear to me that its suitable for OpenJDK. Nor why
hotspot is selectable but JDK is not. ??


We would prefer to always build with security features enabled, but the
performance impact on the JVM is so high that we want to leave it to the
user to decide, both at bulid time and at runtime. With these changes,
Oracle will build OracleJDK, and OpenJDK, with dual JVMs by default, but any
other person or entity just building the OpenJDK source will just get the
server variant for now (as has been the default for a long time), unless
they specifically ask for "hardened" or activate the new jvm feature
(--with-jvm-feature=no-speculative-cti).

We don't see the point in giving the choice on the JDK libraries simply
because there is no drawback to enabling the flags.

/Erik


Sorry.

David
-


/Erik


On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:

On 4 Jun 2018, at 17:52, Erik Joelsson 
wrote:

Hello,

On 2018-06-01 14:00, Aleksey Shipilev wrote:

On 06/01/2018 10:53 PM, Erik Joelsson wrote:

This patch defines flags for disabling speculative execution for GCC
and Visual Studio and applies
them to all binaries except libjvm when available in the compiler. It
defines a new jvm feature
no-speculative-cti, which is used to control whether to use the flags
for libjvm. It also defines a
new jvm variant "altserver" which is the same as server, but with
this new feature added.

I think the classic name for such product configuration is "hardened",
no?

I don't know. I'm open to suggestions on naming.

"hardened" sounds good to me.

The change looks good as well.
/Jesper


/Erik

-Aleksey

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Volker Simonis]

Hi Erik,

you wrote: "Note that this applies to the build time C++ flags, not
the compiler in the JVM itself." So what about the code generated by
the HotSpot (i.e. stubs, template interpreter, c1, c2, Graal)? Is this
code already "hardened" against speculative execution? If yes, that's
fine, if not, I don't see the point in hardening the HotSpot code
itself if the VM still generates potentially "insecure" code.

And I still don't fully understand how things work if you build both
variants by default (as you intend to do it for Oracle builds). Will
you end up with two subdirectories (lib/server/ and lib/altserver)
where both contain a libjvm.so and the user can use "java -altserver"
on the command line to choose the hardened version?

Thank you and best regards,
Volker


On Tue, Jun 5, 2018 at 5:47 PM, Erik Joelsson  wrote:
> Hello,
>
> On 2018-06-04 23:10, David Holmes wrote:
>>
>> Sorry to be late to this party ...
>>
>> On 5/06/2018 6:10 AM, Erik Joelsson wrote:
>>>
>>> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
>>>
>>> Renamed the new jvm variant to "hardened".
>>
>>
>> As it is a hardened server build I'd prefer if that were somehow reflected
>> in the name. Though really I don't see why this should be restricted this
>> way ... to be honest I don't see hardened as a variant of server vs. client
>> vs. zero etc at all, you should be able to harden any of those.
>>
> I agree, and you sort of can. By adding the jvm feature "no-speculative-cti"
> to any jvm variant, you get the flags. The name of the predefined variant
> can be discussed. I initially suggested altserver because I, as you, thought
> it should include server in the name. But ultimately, I don't care that much
> about a name. There is also little point in defining a whole set of
> predefined variants that nobody has requested. If we ever need more
> specialized variants in the same image, we will add them.
>>
>> So IIUC with this change we will:
>> - always build JDK native code "hardened" (if toolchain supports it)
>
> Yes, this is correct. The reason being that no significant performance
> impact was detected, so there is no cost.
>>
>> - only build hotspot "hardened" if requested; and in that case
>>   - jvm.cfg will list -server and -hardened with server as default
>
> Correct.
>>
>>
>> Is that right? I can see that we may choose to always build Oracle JDK
>> this way but it isn't clear to me that its suitable for OpenJDK. Nor why
>> hotspot is selectable but JDK is not. ??
>>
> We would prefer to always build with security features enabled, but the
> performance impact on the JVM is so high that we want to leave it to the
> user to decide, both at bulid time and at runtime. With these changes,
> Oracle will build OracleJDK, and OpenJDK, with dual JVMs by default, but any
> other person or entity just building the OpenJDK source will just get the
> server variant for now (as has been the default for a long time), unless
> they specifically ask for "hardened" or activate the new jvm feature
> (--with-jvm-feature=no-speculative-cti).
>
> We don't see the point in giving the choice on the JDK libraries simply
> because there is no drawback to enabling the flags.
>
> /Erik
>
>> Sorry.
>>
>> David
>> -
>>
>>> /Erik
>>>
>>>
>>> On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:
>
> On 4 Jun 2018, at 17:52, Erik Joelsson 
> wrote:
>
> Hello,
>
> On 2018-06-01 14:00, Aleksey Shipilev wrote:
>>
>> On 06/01/2018 10:53 PM, Erik Joelsson wrote:
>>>
>>> This patch defines flags for disabling speculative execution for GCC
>>> and Visual Studio and applies
>>> them to all binaries except libjvm when available in the compiler. It
>>> defines a new jvm feature
>>> no-speculative-cti, which is used to control whether to use the flags
>>> for libjvm. It also defines a
>>> new jvm variant "altserver" which is the same as server, but with
>>> this new feature added.
>>
>> I think the classic name for such product configuration is "hardened",
>> no?
>
> I don't know. I'm open to suggestions on naming.

 "hardened" sounds good to me.

 The change looks good as well.
 /Jesper

> /Erik
>>
>> -Aleksey
>>
>>>
>

Re: RFR: JDK-8202384: Introduce altserver jvm variant with

[Erik Joelsson]

Hello Matthias,

For GCC, you need 7.3.0 or later. For Microsoft you need VS2017 and I 
think some minimal update version (the option is called -Qspectre), we 
use 15.5.5.


I was not involved in the benchmarking so I don't know any details 
there, only the conclusion.


/Erik


On 2018-06-05 01:30, Baesken, Matthias wrote:


Hi Erik , is there  some info available about  the performance impact 
when  disabling  disabling speculative execution  ?


And which compiler versions are needed for this ?

Best regards, Matthias

>We need to add compilation flags for disabling speculative execution to

>our native libraries and executables. In order to allow for users not

>affected by problems with speculative execution to run a JVM at full

>speed, we need to be able to ship two JVM libraries - one that is

>compiled with speculative execution enabled, and one that is compiled

>without. Note that this applies to the build time C++ flags, not the

>compiler in the JVM itself. Luckily adding these flags to the rest of

>the native libraries did not have a significant performance impact so

>there is no need for making it optional there.

>

>This patch defines flags for disabling speculative execution for GCC and

>Visual Studio and applies them to all binaries except libjvm when

>available in the compiler. It defines a new jvm feature

>no-speculative-cti, which is used to control whether to use the flags

>for libjvm. It also defines a new jvm variant "altserver" which is the

>same as server, but with this new feature added.

>

>For Oracle builds, we are changing the default for linux-x64 and

>windows-x64 to build both server and altserver, giving the choice to the

>user which JVM they want to use. If others would prefer this default, we

>could make it default in configure as well.

>

>The change in GensrcJFR.gmk fixes a newly introduced race that appears

>when building multiple jvm variants.

>

>Bug: https://bugs.openjdk.java.net/browse/JDK-8202384

>

>Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.01 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Erik Joelsson]

Hello,

On 2018-06-04 23:10, David Holmes wrote:

Sorry to be late to this party ...

On 5/06/2018 6:10 AM, Erik Joelsson wrote:

New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/

Renamed the new jvm variant to "hardened".


As it is a hardened server build I'd prefer if that were somehow 
reflected in the name. Though really I don't see why this should be 
restricted this way ... to be honest I don't see hardened as a variant 
of server vs. client vs. zero etc at all, you should be able to harden 
any of those.


I agree, and you sort of can. By adding the jvm feature 
"no-speculative-cti" to any jvm variant, you get the flags. The name of 
the predefined variant can be discussed. I initially suggested altserver 
because I, as you, thought it should include server in the name. But 
ultimately, I don't care that much about a name. There is also little 
point in defining a whole set of predefined variants that nobody has 
requested. If we ever need more specialized variants in the same image, 
we will add them.

So IIUC with this change we will:
- always build JDK native code "hardened" (if toolchain supports it)
Yes, this is correct. The reason being that no significant performance 
impact was detected, so there is no cost.

- only build hotspot "hardened" if requested; and in that case
  - jvm.cfg will list -server and -hardened with server as default

Correct.


Is that right? I can see that we may choose to always build Oracle JDK 
this way but it isn't clear to me that its suitable for OpenJDK. Nor 
why hotspot is selectable but JDK is not. ??


We would prefer to always build with security features enabled, but the 
performance impact on the JVM is so high that we want to leave it to the 
user to decide, both at bulid time and at runtime. With these changes, 
Oracle will build OracleJDK, and OpenJDK, with dual JVMs by default, but 
any other person or entity just building the OpenJDK source will just 
get the server variant for now (as has been the default for a long 
time), unless they specifically ask for "hardened" or activate the new 
jvm feature (--with-jvm-feature=no-speculative-cti).


We don't see the point in giving the choice on the JDK libraries simply 
because there is no drawback to enabling the flags.


/Erik

Sorry.

David
-


/Erik


On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:
On 4 Jun 2018, at 17:52, Erik Joelsson  
wrote:


Hello,

On 2018-06-01 14:00, Aleksey Shipilev wrote:

On 06/01/2018 10:53 PM, Erik Joelsson wrote:
This patch defines flags for disabling speculative execution for 
GCC and Visual Studio and applies
them to all binaries except libjvm when available in the 
compiler. It defines a new jvm feature
no-speculative-cti, which is used to control whether to use the 
flags for libjvm. It also defines a
new jvm variant "altserver" which is the same as server, but with 
this new feature added.
I think the classic name for such product configuration is 
"hardened", no?

I don't know. I'm open to suggestions on naming.

"hardened" sounds good to me.

The change looks good as well.
/Jesper


/Erik

-Aleksey

RE: RFR: JDK-8202384: Introduce altserver jvm variant with

[Baesken, Matthias]

Hi Erik , is there  some info available about  the performance impact when  
disabling  disabling speculative execution  ?



And which compiler versions are needed for this ?



Best regards, Matthias





>We need to add compilation flags for disabling speculative execution to

>our native libraries and executables. In order to allow for users not

>affected by problems with speculative execution to run a JVM at full

>speed, we need to be able to ship two JVM libraries - one that is

>compiled with speculative execution enabled, and one that is compiled

>without. Note that this applies to the build time C++ flags, not the

>compiler in the JVM itself. Luckily adding these flags to the rest of

>the native libraries did not have a significant performance impact so

>there is no need for making it optional there.

>

>This patch defines flags for disabling speculative execution for GCC and

>Visual Studio and applies them to all binaries except libjvm when

>available in the compiler. It defines a new jvm feature

>no-speculative-cti, which is used to control whether to use the flags

>for libjvm. It also defines a new jvm variant "altserver" which is the

>same as server, but with this new feature added.

>

>For Oracle builds, we are changing the default for linux-x64 and

>windows-x64 to build both server and altserver, giving the choice to the

>user which JVM they want to use. If others would prefer this default, we

>could make it default in configure as well.

>

>The change in GensrcJFR.gmk fixes a newly introduced race that appears

>when building multiple jvm variants.

>

>Bug: https://bugs.openjdk.java.net/browse/JDK-8202384

>

>Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.01

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[David Holmes]

Sorry to be late to this party ...

On 5/06/2018 6:10 AM, Erik Joelsson wrote:

New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/

Renamed the new jvm variant to "hardened".


As it is a hardened server build I'd prefer if that were somehow 
reflected in the name. Though really I don't see why this should be 
restricted this way ... to be honest I don't see hardened as a variant 
of server vs. client vs. zero etc at all, you should be able to harden 
any of those.


So IIUC with this change we will:
- always build JDK native code "hardened" (if toolchain supports it)
- only build hotspot "hardened" if requested; and in that case
  - jvm.cfg will list -server and -hardened with server as default

Is that right? I can see that we may choose to always build Oracle JDK 
this way but it isn't clear to me that its suitable for OpenJDK. Nor why 
hotspot is selectable but JDK is not. ??


Sorry.

David
-


/Erik


On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:

On 4 Jun 2018, at 17:52, Erik Joelsson  wrote:

Hello,

On 2018-06-01 14:00, Aleksey Shipilev wrote:

On 06/01/2018 10:53 PM, Erik Joelsson wrote:
This patch defines flags for disabling speculative execution for 
GCC and Visual Studio and applies
them to all binaries except libjvm when available in the compiler. 
It defines a new jvm feature
no-speculative-cti, which is used to control whether to use the 
flags for libjvm. It also defines a
new jvm variant "altserver" which is the same as server, but with 
this new feature added.
I think the classic name for such product configuration is 
"hardened", no?

I don't know. I'm open to suggestions on naming.

"hardened" sounds good to me.

The change looks good as well.
/Jesper


/Erik

-Aleksey

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[jesper . wilhelmsson]

Looks good to me.
/Jesper

> On 4 Jun 2018, at 22:10, Erik Joelsson  wrote:
> 
> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
> 
> Renamed the new jvm variant to "hardened".
> 
> /Erik
> 
> 
> On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:
>>> On 4 Jun 2018, at 17:52, Erik Joelsson  wrote:
>>> 
>>> Hello,
>>> 
>>> On 2018-06-01 14:00, Aleksey Shipilev wrote:
 On 06/01/2018 10:53 PM, Erik Joelsson wrote:
> This patch defines flags for disabling speculative execution for GCC and 
> Visual Studio and applies
> them to all binaries except libjvm when available in the compiler. It 
> defines a new jvm feature
> no-speculative-cti, which is used to control whether to use the flags for 
> libjvm. It also defines a
> new jvm variant "altserver" which is the same as server, but with this 
> new feature added.
 I think the classic name for such product configuration is "hardened", no?
>>> I don't know. I'm open to suggestions on naming.
>> "hardened" sounds good to me.
>> 
>> The change looks good as well.
>> /Jesper
>> 
>>> /Erik
 -Aleksey
 
> 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Erik Joelsson]

New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/

Renamed the new jvm variant to "hardened".

/Erik


On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:

On 4 Jun 2018, at 17:52, Erik Joelsson  wrote:

Hello,

On 2018-06-01 14:00, Aleksey Shipilev wrote:

On 06/01/2018 10:53 PM, Erik Joelsson wrote:

This patch defines flags for disabling speculative execution for GCC and Visual 
Studio and applies
them to all binaries except libjvm when available in the compiler. It defines a 
new jvm feature
no-speculative-cti, which is used to control whether to use the flags for 
libjvm. It also defines a
new jvm variant "altserver" which is the same as server, but with this new 
feature added.

I think the classic name for such product configuration is "hardened", no?

I don't know. I'm open to suggestions on naming.

"hardened" sounds good to me.

The change looks good as well.
/Jesper


/Erik

-Aleksey

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[jesper . wilhelmsson]

> On 4 Jun 2018, at 17:52, Erik Joelsson  wrote:
> 
> Hello,
> 
> On 2018-06-01 14:00, Aleksey Shipilev wrote:
>> On 06/01/2018 10:53 PM, Erik Joelsson wrote:
>>> This patch defines flags for disabling speculative execution for GCC and 
>>> Visual Studio and applies
>>> them to all binaries except libjvm when available in the compiler. It 
>>> defines a new jvm feature
>>> no-speculative-cti, which is used to control whether to use the flags for 
>>> libjvm. It also defines a
>>> new jvm variant "altserver" which is the same as server, but with this new 
>>> feature added.
>> I think the classic name for such product configuration is "hardened", no?
> I don't know. I'm open to suggestions on naming.

"hardened" sounds good to me.

The change looks good as well.
/Jesper

> 
> /Erik
>> -Aleksey
>> 
> 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Erik Joelsson]

Hello,

On 2018-06-01 14:00, Aleksey Shipilev wrote:

On 06/01/2018 10:53 PM, Erik Joelsson wrote:

This patch defines flags for disabling speculative execution for GCC and Visual 
Studio and applies
them to all binaries except libjvm when available in the compiler. It defines a 
new jvm feature
no-speculative-cti, which is used to control whether to use the flags for 
libjvm. It also defines a
new jvm variant "altserver" which is the same as server, but with this new 
feature added.

I think the classic name for such product configuration is "hardened", no?

I don't know. I'm open to suggestions on naming.

/Erik

-Aleksey

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Magnus Ihse Bursie]

> 1 juni 2018 kl. 23:53 skrev Erik Joelsson :
> 
> We need to add compilation flags for disabling speculative execution to our 
> native libraries and executables. In order to allow for users not affected by 
> problems with speculative execution to run a JVM at full speed, we need to be 
> able to ship two JVM libraries - one that is compiled with speculative 
> execution enabled, and one that is compiled without. Note that this applies 
> to the build time C++ flags, not the compiler in the JVM itself. Luckily 
> adding these flags to the rest of the native libraries did not have a 
> significant performance impact so there is no need for making it optional 
> there.
> 
> This patch defines flags for disabling speculative execution for GCC and 
> Visual Studio and applies them to all binaries except libjvm when available 
> in the compiler. It defines a new jvm feature no-speculative-cti, which is 
> used to control whether to use the flags for libjvm. It also defines a new 
> jvm variant "altserver" which is the same as server, but with this new 
> feature added.
> 
> For Oracle builds, we are changing the default for linux-x64 and windows-x64 
> to build both server and altserver, giving the choice to the user which JVM 
> they want to use. If others would prefer this default, we could make it 
> default in configure as well.

I think we should keep the praxis of only having server as default. 

> 
> The change in GensrcJFR.gmk fixes a newly introduced race that appears when 
> building multiple jvm variants.

Thanks for fixing this!

> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202384
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.01

Looks good to me. 

/Magnus

> 
> /Erik
> 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Magnus Ihse Bursie]

/Magnus

> 1 juni 2018 kl. 23:53 skrev Erik Joelsson :
> 
> We need to add compilation flags for disabling speculative execution to our 
> native libraries and executables. In order to allow for users not affected by 
> problems with speculative execution to run a JVM at full speed, we need to be 
> able to ship two JVM libraries - one that is compiled with speculative 
> execution enabled, and one that is compiled without. Note that this applies 
> to the build time C++ flags, not the compiler in the JVM itself. Luckily 
> adding these flags to the rest of the native libraries did not have a 
> significant performance impact so there is no need for making it optional 
> there.
> 
> This patch defines flags for disabling speculative execution for GCC and 
> Visual Studio and applies them to all binaries except libjvm when available 
> in the compiler. It defines a new jvm feature no-speculative-cti, which is 
> used to control whether to use the flags for libjvm. It also defines a new 
> jvm variant "altserver" which is the same as server, but with this new 
> feature added.
> 
> For Oracle builds, we are changing the default for linux-x64 and windows-x64 
> to build both server and altserver, giving the choice to the user which JVM 
> they want to use. If others would prefer this default, we could make it 
> default in configure as well.
> 
> The change in GensrcJFR.gmk fixes a newly introduced race that appears when 
> building multiple jvm variants.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202384
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.01
> 
> /Erik
> 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Aleksey Shipilev]

On 06/01/2018 10:53 PM, Erik Joelsson wrote:
> This patch defines flags for disabling speculative execution for GCC and 
> Visual Studio and applies
> them to all binaries except libjvm when available in the compiler. It defines 
> a new jvm feature
> no-speculative-cti, which is used to control whether to use the flags for 
> libjvm. It also defines a
> new jvm variant "altserver" which is the same as server, but with this new 
> feature added.

I think the classic name for such product configuration is "hardened", no?

-Aleksey

RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Erik Joelsson]

We need to add compilation flags for disabling speculative execution to 
our native libraries and executables. In order to allow for users not 
affected by problems with speculative execution to run a JVM at full 
speed, we need to be able to ship two JVM libraries - one that is 
compiled with speculative execution enabled, and one that is compiled 
without. Note that this applies to the build time C++ flags, not the 
compiler in the JVM itself. Luckily adding these flags to the rest of 
the native libraries did not have a significant performance impact so 
there is no need for making it optional there.


This patch defines flags for disabling speculative execution for GCC and 
Visual Studio and applies them to all binaries except libjvm when 
available in the compiler. It defines a new jvm feature 
no-speculative-cti, which is used to control whether to use the flags 
for libjvm. It also defines a new jvm variant "altserver" which is the 
same as server, but with this new feature added.


For Oracle builds, we are changing the default for linux-x64 and 
windows-x64 to build both server and altserver, giving the choice to the 
user which JVM they want to use. If others would prefer this default, we 
could make it default in configure as well.


The change in GensrcJFR.gmk fixes a newly introduced race that appears 
when building multiple jvm variants.


Bug: https://bugs.openjdk.java.net/browse/JDK-8202384

Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.01

/Erik