-
Notifications
You must be signed in to change notification settings - Fork 83
Description
This creates a separate issue out of the latter part of this comment and the one that follows.
When bindings are generated from the C headers in cryptoki-sys
, they do so using whatever structure alignment and packing is assumed for the target platform unless packing is made explicit in the headers for bindgen
to read. Currently, packing is only specified for Windows and left implied everywhere else.
You can confirm that forcing a 1-byte alignment for structs on other platforms that it does indeed produce bindings that differ in terms of size and field offsets, and is not the implicit default.
Meanwhile, the PKCS#11 standard (both 2.x and 3.x, Section 2.1) are very clear that
Cryptoki structures are packed to occupy as little space as is possible. Cryptoki structures SHALL be packed with 1-byte alignment.
This would seem to imply that packing be explicit for all target bindings. But when this is done, several problems arise:
- Rust assumes a >1-byte minimum alignment for struct members, which makes referencing anything beyond the 0th item undefined behavior. Each such instance of this (hundreds in the auto-generated tests) produces a valid, unsuppressible compiler warning. This is a known issue for bindgen that doesn't appear to be nearing a solution any time soon.
- Tests written for this crate using SoftHSM seg fault. Whether this is at the rust level (dereferencing unaligned addresses) or at the C level (mismatch with struct packing internal to SoftHSM) is unclear. The latter doesn't seem like it should be the case, but the fact that tests are currently passing would seem to be an endorsement of implicit, non-compact alignment.
So, something is incorrect here, but what exactly that is needs to be investigated. Even if it turns out the way the bindings are currently generated is correct, that fact should still be documented conspicuously to avoid further misconception.