RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get

Martin Buchholz martinrb at google.com
Thu May 12 19:00:43 UTC 2016


I have a new simpler webrev following your suggestion:
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/
Old one available at
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race.0/

On Wed, May 11, 2016 at 11:41 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> Hi Martin,
>
> If you agree with the update, I will sponsor your contribution for the
> testing and integration for JDK 9.
>
> Thanks,
> Xuelei
>
> On 5/12/2016 2:27 PM, Martin Buchholz wrote:
>> Xuelei,
>>
>> I again invite you to take ownership of this change.
>> It needs to be ported to jdk9.
>>
>> If we simply delete OidTableSize then the initialization code will be
>> close to optimal for the default configuration, and it will still work
>> well if configured a little differently, so I would keep it.  But we
>> can also use the default initial capacity (16) if you prefer.
>>
>> On Wed, May 11, 2016 at 10:54 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>> On 5/12/2016 1:21 PM, Martin Buchholz wrote:
>>>> Hi Xuelei,
>>>>
>>>> I think the non-test code will work well with any set of providers,
>>>> but is optimized for the default set of providers.  If the user
>>>> removes a provider, then the hashmap will be auto-compacted.  The
>>>> OidTableSize test will fail if the default providers are changed, but
>>>> that actually helps maintenance efforts (if you care about optimizing
>>>> startup; it's also reasonable not to care, and to delete the
>>>> OidTableSize test entirely).
>>>>
>>> The test is used to test JDK default providers, but not the application
>>> customized configurations.  Application customized providers may be
>>> different.  And the providers may also be different from platform to
>>> platform.  So sometimes, the hard-coded size code may make the startup
>>> performance worse.  For maintenance, even if the OidTableSize test
>>> failed in the future, it may be hard to find the need to update the code
>>> here.
>>>
>>> Xuelei
>>>
>>>> On Wed, May 11, 2016 at 9:33 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>>> AlgorithmId.java
>>>>> ================
>>>>> Line 582-587, about the capacity of hash map, applications may customize
>>>>> Security providers and more OID numbers may get removed/added later, so
>>>>> the oid number may be not a fixed hard-coded number.  It may be easier
>>>>> to maintain the code if using the default initial capacity of HashMap.
>>>>>
>>>>> Thanks,
>>>>> Xuelei
>>>>>
>>>>>
>>>>> On 5/12/2016 1:01 AM, Martin Buchholz wrote:
>>>>>> Webrev updated.
>>>>>> Still looking for crypto-collaborator.
>>>>>>
>>>>>> On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz <martinrb at google.com> wrote:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156584
>>>>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/
>>>>>>>
>>>>>>> I'm not a crypto engineer, so I'm hoping someone on security-dev
>>>>>>> adopts this fix.  But current webrev is intended to be a complete fix
>>>>>>> for jdk8.
>>>>>
>>>
>



More information about the security-dev mailing list