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@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@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.geo...@oracle.com <mailto:jini.geo...@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 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>> > >> > >
