Summary

Always set byte code verification mode to -Xverify:remote during CDS dump time.

Problem

Up to JDK 10, we allow -Xverify:none to be specified during dump time. This allows unverifiable application classes to be archived, with the following consequences:

1. The archived unverifiable classes may be exploited by an attacker. Removing such classes from the archive is a good measure of security defense-in-depth.
2. If a failure happens due to the use of unverifiable classes loaded at run time, we are not sure if such classes were loaded from the archive or dynamically (e.g., from the CLASSPATH). This makes failure analysis complicated.

Solution

Always use the -Xverify:remote setting during CDS dump time.

If the user explicitly specifies the -Xverify:none setting, an info message will be printed at the beginning of CDS dumping.

This change also has two benefits:

1. Defense in depth -- ensure no unverifiable (app) classes are archived to reduce exploitability.
2. Limited usefulness in failure analysis Since the -Verify:remote will be set during CDS dump time, there won't be any unverifiable classes stored in the archive. When a failure happens and and we suspect that it may be related to unverifiable bytecode, we can limit the suspects to the classes that are dynamically loaded.

Specification

If the user specifies -Xverify:none during CDS dump time, vm will output the following message:

All non-system classes will be verified (-Xverify:remote) during CDS dump time.