Re: [pkcs11] CK_ULONG considered harmful?

[Darren J Moffat <Darren.Moffat@Oracle.COM>]

On 05/16/13 18:07, Michael StJohns wrote:
> In the current version of the spec, the definition for CK_ULONG and
> CK_LONG are "integers at least 32 bits wide".
>
> Given this spec is at least in part an interface spec, there can be an
> issue where the client uses a CK_ULONG of 32 bits and the driver uses a
> CK_ULONG of 64 bits (for example) or vice versa.  The text in the
> section says:

Then you have a broken "driver" or user/kernel boundary if your 
operating system supports 32 bit userland on a 64 bit kernel.

> > It follows that many of the data and pointer types will vary somewhat
> > from one
> > environment to another (e.g., a CK_ULONG will sometimes be 32 bits,
> > and sometimes
> > perhaps 64 bits). However, these details should not affect an
> > application, assuming it is
> > compiled with Cryptoki header files consistent with the Cryptoki
> > library to which the
> > application is linked.
>
> But that means that it is difficult to build client code built for
> adaptation (e.g. something like java bridge to JCE and NSS for Mozilla)
> that is library agnostic.

We already have a Java JCE to PKCS#11 bridge that supports both the 
Solaris native libpkcs11 and the Mozilla NSS and it did not have this 
problem. That JCE to PKCS#11 bridge exists for Solaris, Linux and 
Windows and has been present since JDK 1.5 and is on by default for all 
JDKs delivered with Solaris since 2005 when we released Solaris 10.

32 bit Java makes JNI calls to the 32 bit PKCS#11 library
64 bit Java makes JNI calls to the 64 bit PKCS#11 library

> Proposal:
>
> 1) Option 1 - Leave it as it is


Option 1 is what we effectively do in Solaris.  The Solaris 64 bit 
support is LP64 which means that a CK_ULONG is 64 bit in a process 
started from an ELF64 binary and 32 bit in an ELF32 baesd process.  That 
is part of our ABI.

We already deal just fine with both 32 bit and 64 bit consumers of 
PKCS#11 in userspace talking to a 64 bit kernel using data passed 
through the PKCS#11 interface with these types out to our 64 bit only 
drivers.  Also when we first implemented this we had both 32 and 64 bit 
kernel drivers.

At one point I even had a prototype PKCS#11 library that used an IPC 
mechanism to pass all the real work to a daemon and the library had both 
32 and 64 bit instances but the daemon was always 64 bit.  Even there I 
didn't have an issue with CK_ULONG.

Changing this is not an option for us if would break the ABI.

What I would much rather see is for the PKCS#11 to stop inventing its 
own type names and use the much more standard ones like:
	uint32_t, int32_t, uin64_t etc.

> 2) "Clarify" the language and force things to 32 bits.
> Change the base definitions  (page 11, section 2 of the 2.40 draft) to:
>
> typedef  uint32_t CK_ULONG;
> typedef int_32_t CK_LONG;
> typedef uint8_t CK_BYTE;
>
> and update the text accordingly.
>
> 3) Fix things for new items:
>
> Add the following definitions:
>
> typedef uint32_t CK_ULONG32;
> typedef int32_t CK_LONG32;
> typedef uint8_t CK_BYTE8;
>
> And use these values for all future definitions and mechanisms.  (I
> mostly don't like this idea because of having CK_ULONG32 and CK_ULONG,
> provided for completeness).
>
> 4) Option 2 or 3 above, but we provide a migration path:
>
> Add a C_GetAlternateFunctionList:
>
> CK_DEFINE_FUNCTION (CK_RV, C_GetAlternateFunctionList) (
>     CK_FUNCTION_LIST_PTR_PTR ppFunctionList,
>     CK_UTF8CHAR_PTR pListName
>   );
>
> Some drivers already do something like this to let you get the FIPs vs
> the non-FIPS version of the routines.
>
> If you did C_GetAlternateFunctionList (&pk, "ULONG32"), you'd get a set
> of routines where the internals for CK_ULONG were all guaranteed to use
> 32 bits, similarly for "ULONG64".
>
> There would be some additional #ifdefs in the header file so that the
> user could do the right thing.
>
> Mike
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

--
Darren J Moffat