Re: [pkcs11] CK_ULONG considered harmful?

[Valerie Anne Fenwick <valerie.fenwick@oracle.com>]

On 05/17/13 12:49 PM, Michael StJohns wrote:
> On 5/17/2013 2:40 PM, Robert Relyea wrote:
> > On 05/16/2013 10:07 AM, 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:
> >
> > So in practice this has meant that CK_ULONG is the length of the unsigned long on the
> > native platform, but needs to be at least 32 bits wide (That is some theoretical 16
> > bit platform needs to have CK_ULONG be able to hold a 32 bit value).  Since the client
> > and the driver are on the same platform (PKCS #11 is a linking, not wire protocol),
> > they should always agree on the actual length.
>
> This is where I think there's a problem.
>
> The header files define this as
>
> typedef unsigned long int CK_ULONG;
>
> But as someone else noted a while back, the header file used by the client may not
> actually be the header file used by the pkcs11 driver implementation.

That's true, but seems very risky to change type definitions like
that.

> Let's say that the client used:
>
> typedef uint32_t CK_ULONG;
>
> and the driver used
>
> typedef uint64_t CK_ULONG;
>
> Both would be in compliance with the PKCS11 spec (int at least 32 bits long), but there
> might be issues.
>
> Another possibility is the driver uses  "typedef uint32_t CK_ULONG" and the client uses
> "typedef unsigned long int CK_ULONG" - what happens on the 64 bit OS?

This seems like a good argument for us to go with more explicit types
in 3.* of the standard.  For now, I haven't heard of any problems in this
area and we've been delivering 64-bit (& 32 bit) PKCS11 libraries for nearly
10 years.

> I don't know what the current implementations do - part of the reason why I asked the
> question.

We seemed to have taken the sample header files largely unmodified,
so we have: typedef unsigned long int CK_ULONG;

Is anyone else having actual issues with this?

Valerie
--
Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva
Solaris Cryptographic Technologies, Manager, Oracle Corporation
Now appearing in "9 to 5" the Musical! June 29-July 27, 2013
      West Valley Light Opera: http://www.wvlo.org/