[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] CK_ULONG considered harmful?
On 5/21/2013 3:58 PM, Chris Zimman wrote:
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).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.
Again, just another day dealing with local vs remote references. Done it a lot.
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.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.
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]