Re: [pkcs11]: CKM_PKCS5_PBKD2_PARAMS struct: password length

[Andrey Jivsov <Andrey_Jivsov@symantec.com>]

On 04/17/2013 03:03 PM, Tim Hudson wrote:
> On 18/04/2013 7:40 AM, Andrey Jivsov wrote:
> > 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.
>
> That is an incorrect assumption. On most operating systems that is true
> - but it is not true on all. It may be true for a sufficiently wide
> range for it to be a reasonable strategy for implementations (producers)
> that wish to implement that approach but a consumer of PKCS11 has no
> idea as to whether or not this behaviour is supported. All three
> behaviours are in implementations which are deployed.

The definition of NULL in the C99 language standard defines NULL to be 
equal the numeric value 0.

The access to 0+small_value is a common incident as a result of access 
to a field in a structure through a pointer that is NULL.

It would be odd to design an operating system in a way that allows

   struct S{
       int a;
       int b;
   };
   struct S *ps = NULL;
   ps->b = 1;     // <== is not an access violation

> It needs to be fixed as there is no reasonable work around.

But this is not the exact issue here. We don't depend on the "trap". All 
we need is that the address of ps->b, the invalid reference, is in the 
range 0...512. AFAIK, there is no concrete operating system where my 
method cannot be tweaked to work due to NULL == 0.

I am not arguing whether the issue needs to be fixed. There is a concern 
with the lifecycle of already deployed implementations, though. The fix 
I proposed can be implemented ASAP in the next "patch"; I can't see how 
it can hurt. However, it makes the documentation bug less severe.

> > 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).
>
> On many operating systems an implementation can work around the issue
> and support clients doing (1) or (2) but not on all.
>
> Tim.
>
>
> ---------------------------------------------------------------------
> 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