RFR: JDK-8007607

[Chris Hegarty]

On 02/08/2013 10:24 PM, Valerie (Yu-Ching) Peng wrote:
>
> The NULL in my earlier email is about the second argument for the OOM
> error and not about the return code/value. As long as an OOM is thrown,
> the return code/value won't be used. Since we must return a value per
> JNI syntax even when OOM has been thrown, maybe we can just return -1,
> or 0, or NULL. I don't think it really matters.

Agreed.

-Chris.

>
> Valerie
>
> On 02/08/13 13:47, Dmitry Samersoff wrote:
>> Valerie,
>>
>> C is not distinguish between 0 and NULL.
>>
>> In GSS case GSS_C_NO_CHANNEL_BINDINGS (expanded to 0) means that client
>> and server agreed that basic context is OK.
>>
>> So return of GSS_C_NO_CHANNEL_BINDINGS(0) in OOM case could lead to
>> security issue if upper level doesn't check for exception.
>>
>> I have no good and cheap solution for this problem.
>>
>>
>> -Dmitry
>>
>>
>>
>> On 2013-02-09 00:19, Valerie (Yu-Ching) Peng wrote:
>>> I think it's ok just to use NULL. An OOM is pretty self-explanatory.
>>> Most if not all invocations that I recall seeing simply use NULL.
>>> Valerie
>>>
>>> On 02/08/13 12:00, John Zavgren wrote:
>>>> All:
>>>>
>>>> I assume that anytime a "JNI" procedure in the native code experiences
>>>> an OOM (Out Of Memory) error, then it should throw an exception, by
>>>> executing:  JNU_ThrowOutOfMemoryError(env, NULL);
>>>>
>>>> src/share/native/sun/security/jgss/wrapper/GSSLibStub.c
>>>> src/share/native/sun/security/jgss/wrapper/NativeUtil.c
>>>> src/share/native/sun/security/smartcardio/pcsc.c
>>>> src/solaris/native/com/sun/security/auth/module/Solaris.c
>>>> src/solaris/native/com/sun/security/auth/module/Unix.c
>>>>
>>>> If so, what messages, if any, should I pass as their second argument,
>>>> instead of NULL?
>>>>
>>>>
>>>>
>>>> Thanks!
>>>> John
>>>> ----- Original Message -----
>>>> From: dmitry.samersoff at oracle.com
>>>> To: john.zavgren at oracle.com
>>>> Cc: security-dev at openjdk.java.net
>>>> Sent: Friday, February 8, 2013 1:35:41 PM GMT -05:00 US/Canada Eastern
>>>> Subject: Re: RFR: JDK-8007607
>>>>
>>>> John,
>>>>
>>>>> Ideas?
>>>> It's a JNI so just throw OOM.
>>>>
>>>> -Dmitry
>>>>
>>>>
>>>> On 2013-02-08 21:38, John Zavgren wrote:
>>>>> Although I agree that the name: "GSS_C_NO_CHANNEL_BINDINGS" is
>>>>> misleading,
>>>>> I can't identify anything else that seems more appropriate.
>>>>>
>>>>> The header file:
>>>>> /jdk8-tl/jdk/src/share/native/sun/security/jgss/wrapper/gssapi.h
>>>>> defines
>>>>> GSS_C_NO_CHANNEL_BINDINGS as follows:
>>>>> #define GSS_C_NO_CHANNEL_BINDINGS ((gss_channel_bindings_t) 0)
>>>>>
>>>>> The symbol matches the prototype of the function:
>>>>>
>>>>>       */*
>>>>>        * Utility routine which creates a gss_channel_bindings_t
>>>>> structure
>>>>>        * using the specified org.ietf.jgss.ChannelBinding object.
>>>>>        */
>>>>>       gss_channel_bindings_t getGSSCB(JNIEnv *env, jobject jcb) {
>>>>>         gss_channel_bindings_t cb;
>>>>>         jobject jinetAddr;
>>>>>         jbyteArray value;
>>>>>
>>>>>         if (jcb == NULL) {
>>>>>           return GSS_C_NO_CHANNEL_BINDINGS;
>>>>>         }
>>>>>           cb = malloc(sizeof(struct gss_channel_bindings_struct));
>>>>>
>>>>>           if(cb == NULL)
>>>>>               return  GSS_C_NO_CHANNEL_BINDINGS;*
>>>>>
>>>>> There doesn't appear to be anything in our set of options that is more
>>>>> suggestive of a memory allocation failure and the symbol:
>>>>> GSS_C_NO_CHANNEL_BINDINGS seems to be logically correct.
>>>>>
>>>>> Ideas?
>>>>>
>>>>> On 02/06/2013 04:57 AM, Dmitry Samersoff wrote:
>>>>>> John,
>>>>>>
>>>>>> Not sure GSS_C_NO_CHANNEL_BINDINGS; is correct return value for this
>>>>>> case.
>>>>>>
>>>>>> I'm second to Valerie - it's better to throw OOM
>>>>>>
>>>>>> -Dmitry
>>>>>>
>>>>>>
>>>>>> On 2013-02-06 03:44, John Zavgren wrote:
>>>>>>> Greetings:
>>>>>>>
>>>>>>> I modified the native code to eliminate potential memory loss and
>>>>>>> crashes by checking the return values of malloc() and realloc()
>>>>>>> calls.
>>>>>>>
>>>>>>> The webrev image of these changes is visible at:
>>>>>>> http://cr.openjdk.java.net/~jzavgren/8007607/webrev.01/
>>>>>>>
>>>>>>> Thanks!
>>>>>>> John Zavgren
>>>>>>>
>>>>> --
>>>>> John Zavgren
>>>>> john.zavgren at oracle.com
>>>>> 603-821-0904
>>>>> US-Burlington-MA
>>>>>
>>
>