RFR: JDK-8230413: Support Pre JDK 6 class with CDS

[Jiangli Zhou]

Hi David,

Thanks for quick response!

On Mon, Nov 11, 2019 at 3:12 PM David Holmes <david.holmes at oracle.com> wrote:
>
> Hi Jiangli,
>
> On 12/11/2019 8:12 am, Jiangli Zhou wrote:
> > Please review the following change that allows archiving
> > pre-JAVA_6_VERSION classes with -Xverify:none.
> >
> > webrev: http://cr.openjdk.java.net/~jiangli/8230413/webrev.00/
> > RFE: https://bugs.openjdk.java.net/browse/JDK-8230413
> >
> > Currently there are still large number of existing classes (pre-built)
> > with older class versions (< 50) in real world applications. Those
> > classes are missing the benefit of archiving. Particularly, in some
> > use cases, class verification can be safely disabled. For those use
> > cases, supporting archiving pre JDK 6 classes shows good performance
> > benefit. We can re-evaluate this support when -Xverify:none is removed
> > in the future, hopefully the needs for supporting class version < 50
> > is no longer significant at that time.
> >
> > This change brings back the pre-JDK-8198849 behavior. Runtime makes
> > sure the dump-time verification mode must be the same or stronger than
> > the current mode.
> >
> > A CSR may be needed for the change. Any thoughts on that?
>
> A CSR request is definitely required given that you are proposing to
> undo a change that was itself put in place via a CSR request! And given
> this is relaxing a "defense-in-depth" check which will result in
> increasing exploitability, I think you will need a very strong argument
> to justify this.

Thanks for confirming this! Will do.

>
> Further this not only undoes JDK-8197972 but it also invalidates
> JDK-8155671 being closed as a duplicate of JDK-8197972. JDK-8155671
> requested a way to know if verification had been disabled, to help with
> analyzing crash reports, but instead we decided to not allow
> verification to be disabled.

I had some concerns about JDK-8155671 initially before making the
change, as it's a closed bug and my memory about the specific issue
was flushed out. I brought up the question in the bug. My take on
Ioi's response to my query about JDK-8155671 was that the
pre-JDK-8197972 behavior would not cause any security hole.

Re-evaluating this particular behavior, I think the pre-JDK-8155671
would actually matches user intention better. If user decides to turn
off verification in safe use cases, it seems to be a good idea to
honor that. With the new dynamic archiving capability, archive could
be created at the first time when running a particular application.
Not forcing verification when user decides to can avoid
unnecessary/unwanted overhead.

If verification is turned off at dump time for application classes,
runtime does not allow execution without also turning off
verification. We can determine a crash is not caused by relaxed dump
time verification.

Regards,
Jiangli

>
> David
> -----
>
>
>
> > Tested with jtreg appcds tests.
> >
> > Best,
> > Jiangli
> >