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

[Jiangli Zhou]

The use case for this RFE is when verification is explicitly disabled
with -Xverify:none by users. For example, users want to disable
verification when running trusted tools.

Regards,
Jiangli

On Mon, Nov 11, 2019 at 8:55 PM Ioi Lam <ioi.lam at oracle.com> wrote:
>
> I wonder if there's a safer alternative. Are there tools that can add
> stackmaps to pre-JDK6 classes? That way they can be verified with the
> split verifier during CDS dump time.
>
> Thanks
> - Ioi
>
> On 11/11/19 4:25 PM, Jiangli Zhou wrote:
> > 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
> >>>
>