RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation

[Jini Susan George]

Thank you, Sundar, Dan, David. Shouldn’t performance be of a slightly lesser concern here given that this is a debugging scenario?

Thanks,
Jini.

> -----Original Message-----
> From: David Holmes
> Sent: Monday, August 01, 2016 6:25 AM
> To: Daniel Daugherty; Sundararajan Athijegannathan; Jini Susan George;
> serviceability-dev at openjdk.java.net
> Subject: Re: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger
> may expose internal representation
> 
> On 30/07/2016 2:26 AM, Daniel D. Daugherty wrote:
> > I didn't miss this part:
> >
> >> Besides, Page data may be very big - cloning that ever
> >> constructor and getter may be too costly.
> >
> > of what you originally wrote. :-)
> >
> > In my opinion, even defense-in-depth security trumps space savings.
> 
> But in this case you have to explicitly enable module accessibility for
> this to be an issue. Doesn't seem reasonable to guard against that when
> it potentially involves a big penalty for well behaved users. It isn't
> clear to me whether futzing with these byte[]'s is really an issue.
> 
> David
> -----
> 
> > Dan
> >
> >
> > On 7/29/16 10:16 AM, Sundararajan Athijegannathan wrote:
> >>
> >> Agreed that it could be considered as a defense-in-depth fix. But, in
> >> this case Page data could be huge. I think it was not cloned in first
> >> place to avoid copying many big byte[] instances around.
> >>
> >> -Sundar
> >>
> >> On 7/29/2016 9:36 PM, Daniel D. Daugherty wrote:
> >>> Two points:
> >>>
> >>> 1) if Findbugs reports the same issue on JDK9 code, then we want to
> >>>    address such that we reduce any Findbugs noise
> >>>
> >>> 2) Fixing it could be considered to be a defense-in-depth change.
> >>>
> >>> Dan
> >>>
> >>>
> >>> On 7/29/16 7:19 AM, Sundararajan Athijegannathan wrote:
> >>>> Well, we can't code for that kind of overrides - Findbugs or any
> >>>> such tool is about normal mode of execution. With that argument,
> >>>> people can override classes using -Xpatch option as well!
> >>>>
> >>>> -Sundar
> >>>>
> >>>> On 7/29/2016 6:05 PM, Jini Susan George wrote:
> >>>>>
> >>>>> Thank you, JB and Sundar. Sundar, would that hold true even if
> >>>>> –XaddExports is used ?
> >>>>>
> >>>>>
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Jini.
> >>>>>
> >>>>>
> >>>>>
> >>>>> *From:*Sundararajan Athijegannathan
> >>>>> *Sent:* Friday, July 29, 2016 5:11 PM
> >>>>> *To:* serviceability-dev at openjdk.java.net
> >>>>> *Subject:* Re: RFR: (XS): JDK-8068004:
> >>>>> [Findbugs]sun.jvm.hotspot.debugger may expose internal
> representation
> >>>>>
> >>>>>
> >>>>>
> >>>>> If cloning is done to avoid exposing byte[] outside SA, this fix is
> >>>>> not needed in jdk9. In jdk9, none of the SA packages are exposed
> >>>>> and code outside SA cannot access this. Besides, Page data may be
> >>>>> very big - cloning that ever constructor and getter may be too costly.
> >>>>>
> >>>>> -Sundar
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 7/29/2016 5:07 PM, Jaroslav Bachorik wrote:
> >>>>>
> >>>>>     Hi Jini,
> >>>>>
> >>>>>
> >>>>>
> >>>>>     'null' seems to be a valid value for 'data' field in both of
> >>>>>     the places you are using 'data.clone()' - you should guard for
> >>>>>     null and call 'clone()' only if the passed in value is non-null.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     Cheers,
> >>>>>
> >>>>>
> >>>>>
> >>>>>     -JB-
> >>>>>
> >>>>>
> >>>>>
> >>>>>     On Fri, Jul 29, 2016 at 11:29 AM, Jini Susan George
> >>>>>     <jini.george at oracle.com <mailto:jini.george at oracle.com>> wrote:
> >>>>>
> >>>>>     Hi all,
> >>>>>
> >>>>>     Please review the fix for the following SA defect (to avoid
> >>>>>     exposing internal representations by storing or returning
> >>>>>     externally mutable objects directly).
> >>>>>
> >>>>>     Bug ID: https://bugs.openjdk.java.net/browse/JDK-8068004
> >>>>>
> >>>>>     Webrev:
> >>>>>
> http://cr.openjdk.java.net/~sballal/sponsorship/8068004/webrev.00/
> >>>>>
> <http://cr.openjdk.java.net/%7Esballal/sponsorship/8068004/webrev.00/>
> >>>>>
> >>>>>     Thanks,
> >>>>>
> >>>>>     - Jini Susan George
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >