RFR: 8261433: Better pkcs11 performance for libpkcs11:C_EncryptInit/libpkcs11:C_DecryptInit

[Valerie Peng]

On Tue, 26 Mar 2024 15:57:55 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> 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.
> > 
> > 
> > Yes, it's better to add one boolean argument and just have one EncryptInit/DecryptInit() method. As times goes by, I'd expect old NSS library usage to die out and we should optimize the flow toward normative version.
> 
> I just noticed, If I add boolean variable, it'll affect all classes (like P11RSA.java etc.) that extends PKCS11.java and we will have to modify all subclasses which might not be the right approach.

Hmm, good point, let me try it out and see if there are other choices.

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

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