RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation
Daniel D. Daugherty
daniel.daugherty at oracle.com
Fri Jul 29 16:26:40 UTC 2016
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>
More information about the serviceability-dev
mailing list