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

Volker Simonis volker.simonis at gmail.com
Tue Jun 5 16:35:44 UTC 2018

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,

On Tue, Jun 5, 2018 at 5:47 PM, Erik Joelsson <erik.joelsson at oracle.com> 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.wilhelmsson at oracle.com wrote:
>>>>> On 4 Jun 2018, at 17:52, Erik Joelsson <erik.joelsson at oracle.com>
>>>>> 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

More information about the hotspot-dev mailing list