Re: [pkcs11] CK_ULONG considered harmful?

[Michael StJohns <msj@nthpermutation.com>]

On 5/21/2013 3:58 PM, Chris Zimman wrote:
> > Mapping the on-the-wire protocol can be tricky, but people do it every day.  You just need to ensure that you do the translation from the using system representation of ? ?
> > CK_ULONG to an on-the-wire representation to a server representation.   And let's not even talk about how you deal with  pointers in a network encoding!
> > I think that the network representation is out of the purview of this group mostly.
> It's not really a problem of wire mapping etc at all -- explain to me how I'm going to get a value that's stored as 64 bit into a 32 bit client.
AFAIK about the only place this is a real issue is with (session | 
object ) handle representation.  The rest of the uses of CK_ULONG in 
pkcs11 are all values that can be represented without loss in 32 bits. 
(I may have missed a mechanism where this isn't the case, but I would be 
surprised).  It's also *slightly* possible that the CK_SLOT_ID might 
have a value that can't be represented in 32 bits. What that says is 
that you have to have and manage a mapping table between the local 
handle (provided by the PKCS11 driver) and the handle provided by the 
remote device (which may or may not actually be a PKCS11 device directly).

Again, just another day dealing with local vs remote references. Done it 
a lot.


>   
>
> > How about:
> >
> > "Although the internal representation for a CK_ULONG may be 32 bits or longer, by convention, only the least significant 32 bits shall be used to represent PKCS11 data values
> > (with the one exception of the ~0UL value *sigh*).  This permits a loss-less conversion from a CK_ULONG 32 bit value to a CK_ULONG 64 bit value and vice versa."
> > This wouldn't be a change to the headers or anything else, just a description of the convention used for assigning values so that reasonable choices can be made to do network > protocol design (or even VM to VM type calls).
> That's just basically saying CK_ULONG == uint32_t.  Instead of trying to make kludges, let's just admit this was a mistake in the past and move on in the future.
No, it's actually not.  What I'm saying is that we're preserving the 
bi-map between 64 and 32 bits, but that the OS can actually use 
whichever internal representation it wants for efficiency.

Although I started this thread, I'm less and less convinced there's a 
need for any change.  I'm sort of convinced by the arguments about 
calling conventions on a 32 vs a 64 bit system and whether or not you 
need to have a uint32_t  or uint64_t vs a unsigned long given that both 
the client and driver have to be compiled for the same architecture.

I *might* be more concerned if there was evidence that multiple C 
compilers were twiddling with this and doing it differently, but I 
haven't heard anyone speak up and mention that as a possibility.

I *might* also be more concerned if any HSM provider were shipping a 
pkcs11t.h file with a "typedef uint32_t CK_ULONG;" entry (or uint64_t).  
I haven't heard anyone speak up and mention they do that, and I haven't 
found any evidence that that is the case for the 3 or 4 PKCS11 
implementations I have here.

The only place I had some problems here was converting between native 
mode (on a smart card) and a PKCS11 driver.  This was the musclecard2 
build, and it was never designed to deal with 64bit architectures.  It 
wasn't a client side driver issue, but the driver to smart card protocol.

Mike



> --Chris