Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8198849

Always verify non-system classes during CDS dump time

    XMLWordPrintable

    Details

    • Type: CSR
    • Status: Closed
    • Priority: P3
    • Resolution: Approved
    • Fix Version/s: 11
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Compatibility Kind:
      behavioral
    • Compatibility Risk:
      minimal
    • Compatibility Risk Description:
      Hide
      Before the proposed change, it used to be possible to archive unverifiable classes and load them from the archive at runtime (by specifying -Xverify:none during both dump time and runtime).

      After the proposed change, unverifiable classes can never be archived.

      So this may cause programs that use bad code to run slightly more slowly. However, there's no impact to correct programs that use only verifiable classes.
      Show
      Before the proposed change, it used to be possible to archive unverifiable classes and load them from the archive at runtime (by specifying -Xverify:none during both dump time and runtime). After the proposed change, unverifiable classes can never be archived. So this may cause programs that use bad code to run slightly more slowly. However, there's no impact to correct programs that use only verifiable classes.
    • Interface Kind:
      add/remove/modify command line option

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              ccheung Calvin Cheung
              Reporter:
              ccheung Calvin Cheung
              Reviewed By:
              Ioi Lam, Jiangli Zhou
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: