JEP 342: Limit Speculative Execution

OwnerJesper Wilhelmsson
TypeFeature
ScopeJDK
StatusCandidate
Componenthotspot
Discussionjdk dash dev at openjdk dot java dot net
EffortL
DurationL
Reviewed byMikael Vidstedt
Created2018/07/12 21:36
Updated2018/09/12 19:35
Issue8207206

Summary

Help developers and deployers defend against speculative-execution (“Spectre”) vulnerabilities by providing a means to limit speculative execution, and enable further mitigations to be implemented in future releases.

Non-Goals

It is not a goal to automatically detect when speculative execution should be limited. End users will have to make that determination.

It is not a goal to provide a complete defense against all forms of speculative execution.

Description

One of the defenses against speculative-execution vulnerabilities is to recompile C and C++ code with compiler options that limit the extent to which the CPU can do speculative execution. Limiting speculative execution can, however, impact performance. This impact can be significant for the C and C++ code in the HotSpot JVM, but it is negligible for the C and C++ code outside of the JVM.

We will therefore include a distinct, alternate JVM in the JDK that is compiled with these options and can be selected at launch time. We will compile all non-JVM code with these options by default; since the performance impact is small, it’s not worth including second copies of all of that code.

It will be up to the end user to decide whether to limit speculative execution. The performance impact may vary widely based on such factors as CPU type, operating system, and workload, and should be assessed via performance testing. If untrusted code is running anywhere on the system, however, then we recommend using the alternate JVM.

Selecting and detecting the alternate JVM

A new launcher command-line option, -nonspeculative, will select the alternate JVM. The current JVM, which does not limit speculative execution, will remain the default.

The output of java --version will indicate which JVM is being used. For example:

$ java --version
java 11-ea 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11-ea+19)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+19, mixed mode, sharing)
$ java -nonspeculative --version
java 11-ea 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11-ea+19)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+19, limit speculative execution, mixed mode)
$

(This is a custom-built JDK; the exact output in a product build will be slightly different.)

On platforms where the alternate JVM is not available, but explicitly asked for with the -nonspeculative flag, an error will be displayed and the JVM will terminate:

Unrecognized option: -nonspeculative
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Differences in the alternate JVM

The alternate JVM will be compiled as follows:

The JIT compilers in the JVM will also need to be updated in much the same way as the C/C++ compilers have been. The changes might have a significant performance impact on most JIT compiled code and for this reason the JIT compiler changes will only be enabled in the alternate JVM. In future releases we may include additional changes in the alternate JVM to strengthen the defense that it provides.

Testing

This feature does not require new functional tests, but appropriate stress and performance testing should be done on the alternate JVM.