Thoughts on possible options to JDK-8027598

[Chris Hegarty]

On 11/20/2013 11:35 PM, Rajan Halade wrote:
> ....
>>>>
>>>> Possible approaches -
>>>> 1. Enhance JTREG - This option would require change in jtreg to
>>>> store/restore security providers when run in agentvm mode.
>>> If I am correct, JTREG has support provider cleanup already. But the
>>> question is even JTREG reset the providers, it still cannot ensure next
>>> test won't be impacted because in some circumstances JDK may need to
>>> cache something which depends on previous providers.  Still need to
>>> analysis the test case by case.
>>
>> Right, any static or cached data may be invalid, and this will require
>> careful changes to the JRE itself.
> Pardon my ignorance - if I gather correctly then ProvidersSnapshot
> library also doesn't sandbox effects completely.

FYI. I am not part of the security team, and someone from the security 
group should ultimately have to agree/disagree, but we have similar 
issues in other parts of the platform. I don't know the specifics of the 
code here so it may, or may not, be an issue.

If any part of the security framework stores values in static fields, 
that is dependent on the security providers, then when the providers 
change this static value may be incorrect.

We encounter this from time to time with system properties. E.g. JDK 
HTTP Client code reads system property and stores in static field, JDK 
HTTP Client will never never re-read the property as it believes it will 
not change. Having jtreg reset/clean certain system properties will not 
help in this case.

>> If there are not too many of these tests, I don't think that
>> explicitly marking them othervm will hurt too much. And making them
>> reliable will reduce greatly the amount of time spent head scratching
>> chasing intermittent failures.
> I agree with you, we need to consider using othervm mode. There are ~66
> (1% of all reg tests) such tests which are run in agentvm, don't use
> ProvidersSnapshot library, and are modifying providers. I think its safe
> to go with othervm option, let me know.

IMHO, this is the right way to go here.

-Chris.

>
> - Rajan
>>
>> -Chris.
>>
>>>
>>> Xuelei
>>>
>>>> 2. Update impacting tests to run in othervm - simple change but may
>>>> slow
>>>> down batch execution slightly.
>>>> 3. Update each test to use library
>>>> java/security/KeyPairGenerator/Failover.java like done in
>>>> java/security/Provider tests - another easy change and tests would
>>>> continue to run agentvm but would have added overhead of restoring
>>>> providers.
>>>>
>>>> We will continue to pursue option 1 but many not be possible. Option
>>>> 2 &
>>>> 3 above are equally good and are debatable so would like your thoughts
>>>> on it.
>>>>
>>>> Thanks,
>>>> Rajan
>>>>
>>>>
>>>
>