HL: Library Merge

"There can be only one!"

The original project that has become a family of projects under the highlander banner.

libpkcs11

The three libraries, libpkcs11, pkcs11_softtoken, and pkcs11_kernel compose the PKCS#11 interfaces to the Crypto Framework.  This project would bring the PKCS#11 identity in libpkcs11 and shed the separate providers for crypto access.  The core crypto provided in userland would be a platform-specific library called libsoftcrypto that links into pkcs11, not using the crypto registration process as it would not be plugged in as a provider.  This is very similar to the way libmd connects to pkcs11_softtoken today.

The pluggable crypto functionality would still exist for providers such as smartcards or other providers that provider additional algorithms.

Some potential enhancement are being evaluated at this time:

• Single session, slot, and object tables
• Minimal locking - exploit that PKCS#11 requires a session be used
    only by one thread.
• Polling of kcf for hardware
• Make MT hot where necessary
• Multipart software when too much for hardware
• Combo ops:
  • use both userland software and kernel
  • table of mechs we can simulates

Requires libsoftcrypto

Thoughts brought up

• Sessions:  Currently this is a linked list, we should probably use a hash table or maybe avl trees.
• Threaded:  Many operations may not be able to be threaded, but something that might be able to would be C_FindObjectInit. Needs to be investigated.
• Metaslot:  Possible threading by either firing off operation init routines to both softtoken and hardware providers to get an real result (no delayed init).  If hardware has comeback with a CKR_OK by the time the operation (say C_Encrypt) is called, then we can use hardware; otherwise, use software if CKR_OK.  Possible alternate is to have softtoken do the init always and then do an init_encrypt ioctl to the hardware provider, or copyin the init keysched from softtoken.
• kcf api used internally?  With both libraries combined, we aren´t going use PKCS#11 internally, kcf is an existing api with structures, and perhaps easier.. why not?
• Re-address fastpath.  Fast path was to bypass metaslot when softtoken was the only provider.  Now with softtoken and hardware being in the same library, this would have to be re-examined, redone or thrown out completely
• Metaslot would only support softtoken and hardware providers via kcf.  Other userland libraries would be outside of the supported matrix of metaslot.  There seems to be good support from the ITeam to pursue this path..

cryptoadm changes

Aliases for pkcs11_softtoken/pkcs11_kernel so we don't need the
full path name since it isn't really relevant anymore.

Need to migrate on upgrade if we change pkcs11.conf

What does this give us:

• Better performance
  - pure software will become equivalent to pkcs11~_softtoken without libpkcs11. - use of hardware should be nearly equivalent to direct use of pkcs11~_kernel - Ability to implement hardware offload low/high water mark Better balance between hardware and software rather than assuming hardware is always faster. - less locking from single library * Better functionality - Combo operations - Simpler drivers -> Better adoption * Easier to maintain - Currently some PKCS#11 bugs get fixed in 3 places - Simpler MetaSlot design - single code base for PKCS#11 implementations

Test Impact

• Core of the EF suite should stay the same.
• May need changes the way the modes run.
• Shouldn't need additional tests since changes in the modes
  should be able to cover combo ops.

Performance Goals

• No Regression on any pure software algorithm
• Expect XX% (TBC) improvement due to single library
• XX% (TBC) improvement for pure hardware mechanism

Documentation Impact

Need to document new aliases for cryptoadm(1M), man page update
and docs.

Update libpkcs11(3lib) to contain info from pkcs11_softtoken and
pkcs11_kernel.

Should be little or no impact to developer documentation.