[14] RFR JDK-8176837 "SunPKCS11 provider needs to check more details on PKCS11 Mechanism"

Xuelei Fan xuelei.fan at oracle.com
Fri Sep 20 02:49:32 UTC 2019


Looks good to me.

Thanks,
Xuelei

On 9/19/2019 5:57 PM, Valerie Peng wrote:
> Hi Xuelei,
> 
> I have added the debugging output for the "unknown" case as you suggested.
> 
> Webrev updated in case you feel like taking another look.
> http://cr.openjdk.java.net/~valeriep/8176837/webrev.01/
> 
> Thanks for the review~
> Valerie
> 
> ----- Original Message -----
> From: xuelei.fan at oracle.com
> To: valerie.peng at oracle.com, security-dev at openjdk.java.net
> Sent: Wednesday, September 18, 2019 6:47:31 PM GMT -08:00 US/Canada Pacific
> Subject: Re: [14] RFR JDK-8176837 "SunPKCS11 provider needs to check more details on PKCS11 Mechanism"
> 
> Just a very minor nit.
> 
> In the initToken() implementation, there is a check for the upper 32
> bits set of a mech and may continue to next mech.  The continue may
> ignore the showinfo dump for some cases in the patch.
> 
> Maybe, it might be more straightforward if we don't want to merge the
> log in one place:
> 1. always show the mech info log for every supported mechanism.
> 2. if not enabled, log with "DISABLED ...".
> 3. if upper 32 bits set, log with "UNKNOWN ...".
> 4. if legacy, log with "Legacy ...".
> 
>      for each mech {
>          if (showInfo) {
>              System.out.println("Mechanism " +
>                  Functions.getMechanismName(longMech) + ": " +
>                  p11.C_GetMechanismInfo(slotID, longMech);
>          }
> 
>          if (!config.isEnabled(longMech)) {
>              System.out.println("DISABLED in configuration");
> 
>              continue;
>          }
> 
>          if (longMech >>> 32 != 0) {
>              System.out.println("Unknown mechanism in configuration");
> 
>              continue;
>          }
> 
>          int mech = (int)longMech;
>          if (isLegacy(token, mech)) {
>              System.out.println("Legacy mechanism in configuration");
> 
>              continue;
>          }
> 
>          ...
>      }
> 
> Otherwise, looks good to me.  Just a nit, no more review cycle is needed
> for me.
> 
> Thanks,
> Xuelei
> 
> On 9/18/2019 5:56 PM, Valerie Peng wrote:
>>
>> Can someone help reviewing this fix? AFAIK, only S11.4 have such
>> mechanisms, e.g. RC4 which only does decryption but not encryption.
>> But the checks seems reasonable to apply to all PKCS11 libraries when
>> querying mechanisms.
>> No new regression test needed as this is already caught by running
>> existing regression tests on S11.4.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176837
>> Webrev: http://cr.openjdk.java.net/~valeriep/8176837/webrev.00/
>>
>> Thanks,
>> Valerie



More information about the security-dev mailing list