On Tue, 26 Mar 2024 22:57:59 GMT, Valerie Peng <[email protected]> wrote:

> > Now that we are going with the normative version first, maybe we should 
> > make additional changes to clean up the flow further?Say,
> > 
> > 1. update `jGCMParamsToCKGCMParamPtr(JNIEnv *env, jobject jParam, CK_ULONG 
> > *pLength)` to allocate the normative structure instead.
> > 2. enhance `updateGCMParams(JNIEnv *env, CK_MECHANISM_PTR mechPtr)` to 
> > return a copy of mech pointer containing the non-normative structure.
> 
> If PKCS11 spec version is less than 2.40, we are retaining the same logic as 
> it exists today. If we make the above changes then there will be a crash in 
> NSS version 3.51 and below where PKCS11 2.20 spec is used.
> 
> However, I can optimze the code by introducing new boolean variable in 
> C_DecryptInit and C_EncryptInit to indicate if we need to send normative 
> struct. If so, I'll add a goto statement to updateGCM params. I did not do 
> this initially because in 11u and above I have seen goto being removed.

I prototyped this a bit and we can add GCM specific encrypt/decrypt init 
methods which takes additional boolean argument which indicate which version to 
use first for the PKCS11 init call. This way, we can remove the mechanism check 
in C_EncryptInit/C_DecryptInit since GCM init would go through the new GCM 
specific encrypt/decrypt init methods. I ended up also making changes to 
p11_convert.c and p11_util.c as well to use the normative version by default. 
It's easier to explain though the webrev/patch which I will share with you 
through slack. I don't have the older NSS library to verify the prototype 
changes, but it works fine w/ the current NSS library in the artifactory. Maybe 
you can take a look and let me know what do you think. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18425#issuecomment-2023985885

Reply via email to