RFR: 8207775: Better management of CipherCore buffers

Anthony Scarpino anthony.scarpino at oracle.com
Fri Aug 3 04:23:55 UTC 2018


Looks good. Only comment is update the copyright year. No need to regenerate a webrev. Assuming it passes all the tests I say it’s ready to push. 

Tony

> On Aug 2, 2018, at 5:15 AM, Seán Coffey <sean.coffey at oracle.com> wrote:
> 
> Thanks Tony. I was asked off thread to add some comments to help code maintenance also.
> 
> webrev updated. Hope we're nearly ready to push now.
> 
> http://cr.openjdk.java.net/~coffeys/webrev.8207775.v4/webrev/
> 
> regards,
> Sean.
> 
>> On 01/08/2018 18:41, Anthony Scarpino wrote:
>> That looks fine to me.
>> 
>> Tony
>> 
>>> On 08/01/2018 08:39 AM, Seán Coffey wrote:
>>> Thanks again for review Tony. I think you raise a good point and should give some performance gain.
>>> 
>>> for line 676: maybe this :
>>> 
>>>                   byte[] copy = Arrays.copyOf(output, len);
>>>                   if (decrypting) {
>>>                       Arrays.fill(output, (byte) 0x00);
>>>                   }
>>>                   return copy;
>>> 
>>> 
>>> perhaps the same again for around line 852 :
>>>                   byte[] copy = Arrays.copyOf(output, len);
>>>                   if (decrypting) {
>>>                       Arrays.fill(output, (byte) 0x00);
>>>                   }
>>>                   return copy;
>>> 
>>> ==
>>> 
>>> Any other reviews/comments from folks before I submit final build/test & webrev ?
>>> 
>>> Regards,
>>> Sean.
>>> 
>>>> On 01/08/18 15:55, Anthony Scarpino wrote:
>>>> 
>>>> 
>>>> My only comment is if it makes sense to have the change at 676 to also only null out on decrypt?
>>>> 
>>>> Otherwise I'm fine with the changes
>>>> 
>>>> Tony
>>>> 
>>>>> On 07/31/2018 02:04 AM, Seán Coffey wrote:
>>>>> Thanks for review Tony. Comments inline..
>>>>> 
>>>>>> On 27/07/18 21:02, Anthony Scarpino wrote:
>>>>>> If we are going to add more, here are two more ton consider:
>>>>>> 
>>>>>> - It looks like there is another Arrays.copyOf() on doFinal() line 851
>>>>> Good point.
>>>>>> - doFinal()
>>>>>> at line 897 there might be something that should be done with 'buffer'.  In particular as a result of line 963's arraycopy().
>>>>> Yes - I've identified two areas where we can be proactive about nulling out 'buffer' contents. That's around the same time where we reset 'buffered' to 0. See lines 777 and 967
>>>>> 
>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8207775.v3/webrev/
>>>>> 
>>>>> regards,
>>>>> Sean.
>>>>>> 
>>>>>> Tony
>>>>>> 
>>>>>> 
>>>>>>> On 07/27/2018 08:29 AM, Seán Coffey wrote:
>>>>>>> Thanks Tony. If it's alright with you, I'd like to make one more edit for this change.
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8207775.v2/webrev/
>>>>>>> 
>>>>>>> There's a condition where we can null out an array early if we're returning a copy. See lines 671-683
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Sean.
>>>>>>> 
>>>>>>>> On 26/07/18 17:42, Anthony Scarpino wrote:
>>>>>>>>> On 07/26/2018 07:36 AM, Seán Coffey wrote:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207775
>>>>>>>>> 
>>>>>>>>> Simple enough fix to null out some internal buffers once they're no longer required.
>>>>>>>>> 
>>>>>>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8207775/webrev/
>>>>>>>>> 
>>>>>>>>> regards,
>>>>>>>>> Sean.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> that looks fine..
>>>>>>>> 
>>>>>>>> Tony
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 




More information about the security-dev mailing list