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

[Daniel D. Daugherty]

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.

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
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160729/1e69733c/attachment-0001.html>