Fix handling empty AllowedMechanisms attribute

[Jakuje]

As returned by SoftHSM: softhsm/SoftHSMv2#825

Fixes: #323

[Jakuje]

OTOH this could be considered a softhsm bug (or at least oddness) and as a rust-cryptoki, we might want to shield a users from such pkcs11-module-specific issues. But then we would have to filter this out early in get_attributes, which does not sound great either.

[nwalfield]

You already pointed out that at least two attributes can definitely be zero length. It thus seems like a bug in rust-cryptoki that it tries to allocate 0 bytes and expects to get a pointer that can be cast to a raw pointer and passed to std::slice::from_raw_parts:

Behavior is undefined if any of the following conditions are violated:

    data must be non-null, valid for reads for len * size_of::<T>() many bytes, and it must be properly aligned

[wiktor-k]

You already pointed out that at least two attributes can definitely be zero length. It thus seems like a bug in rust-cryptoki that it tries to allocate 0 bytes and expects to get a pointer that can be cast to a raw pointer and passed to std::slice::from_raw_parts:

Behavior is undefined if any of the following conditions are violated:

    data must be non-null, valid for reads for len * size_of::<T>() many bytes, and it must be properly aligned

Validity rules for reads explicitly point out that:

For memory accesses of size zero, every pointer is valid, including the null pointer.

I'm okay with the change here, with a bit of docs around it, since at first sight it looks like a premature optimization 🤔

[nwalfield]

You already pointed out that at least two attributes can definitely be zero length. It thus seems like a bug in rust-cryptoki that it tries to allocate 0 bytes and expects to get a pointer that can be cast to a raw pointer and passed to std::slice::from_raw_parts:

Behavior is undefined if any of the following conditions are violated:

    data must be non-null, valid for reads for len * size_of::<T>() many bytes, and it must be properly aligned

Validity rules for reads explicitly point out that:

For memory accesses of size zero, every pointer is valid, including the null pointer.

I'm okay with the change here, with a bit of docs around it, since at first sight it looks like a premature optimization 🤔

That's not the only relevant thing. From slice::from_raw_parts:

data must be non-null and aligned even for zero-length slices or slices of ZSTs.

And that's the bug that we are seeing.

[neverpanic]

Typo, rest lg2m.

[hug-dev]

Thanks for the fix and the comment ⭐

[Jakuje]

@wiktor-k can you have a look and approve if this looks ok?

[wiktor-k]

I think this looks good 👌 a couple of small suggestions, if you don't mind.

Btw, thanks for the ping, quite a lot on the plate recently 😅

[Jakuje]

oh, no. Something in the ubuntu broke the installation of the 32b arch softhsm ...

[hug-dev]

Is it this line failing? Might be ok to ignore for now...

sudo dpkg --add-architecture i386

[Jakuje]

Is it this line failing? Might be ok to ignore for now...

sudo dpkg --add-architecture i386

Hard to say. Would have to try that locally or to get more information from the CI. I am also curious about the kryoptic failure that was not there in #328, in CI which ran last week.