Re: [pkcs11]: CKM_PKCS5_PBKD2_PARAMS struct: password length

[Andrey Jivsov <Andrey_Jivsov@symantec.com>]

I describe a solution that I think Valerie alluded to that would work for all platforms as far as covering the difference between

Well ... which is it?   It should be either:
         (1)     CK_ULONG ulPasswordLen;
or
         (2)     CK_ULONG_PTR pulPasswordLen;

On all operating systems the first page of the process's address space is protected, so that the addresses in the range of 0 - 512 are always illegal and cannot be valid pointers. Notice that a password length fits into this range. This can be used to distinguish between these cases.

Let's say we are, the library, are trying to identify which interpretation for the value P the caller is using: the (1) or (2).

In terms of C language, when the P is cast to the numeric value of type size_t (that is guaranteed to accommodate a pointer void *) whether P is a ULONG or ULONG_PTR, denoted here as (size_t)P, it follows that

   if (size_t)P < 512  => client uses case (1)
   else => client uses case (2).

Most compilers contain a special symbol that identifies the beginning of the address space of the process, i.e. "this" or "my" process address space. For example, the tests above may be able to use __bss_start on GCC. In general, we need to use the symbol that corresponds to the process that loads the library (and not the one corresponding to the PKCS#11 library).

Thus, I believe that it's technically possible to write a PKCS#11 library that will inter-operate with a client, whether it's doing (1) or (2).