Hmm.. not sure. Entire (OS) page data is read and many such pages are read + cached. "find pointer" like memory walking features would suffer with this data cloning. BTW, a very slow debugger against a large core dump is useless at times.
As David mentioned, I'm not sure if this is even a bug! sun.* and other package prefixes are listed under "package.access" and so these are not accessible under a security manager even in jdk8 or below. With jdk9, over and above "package.access" security check, we have modular access checks which are done regardless of security manager. Code scanning tools need to be updated for jdk9 - which I'm sure will happen in future. For now, we should just treat these warnings as false positives. -Sundar On 8/1/2016 9:43 AM, Jini Susan George wrote: > 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>
