When statistic counters would overflow, keep them at the maximum possible
value. Wrapping to zero is the worst possible outcome for an auditing tool,
it silently under-reports activity.
If a counter saturated, then the pkcsstatd display indicates this with
"[saturated]" instead of the counter value.
While at it also make the reset operation to operate in an per counter
atomic way. Otherwise counter increments might get lost while a reset is
performed.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Uids are typically unsigned ints (uid_t), but the code handles them as
signed int, possibly dropping the upper half values.
Also correct the statistics SHM file iterating matching logic.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Limit the number of slot to NUMBER_SLOTS_MANAGED when calculating the
size of the statistics shared memory segment.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add defines for CKM_ECDH_X_AES_KEY_WRAP and CKM_ECDH_COF_AES_KEY_WRAP to
pkcs11types.h. Also add these mechanisms to policy and statistics code.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Make the mechanism CKM_IBM_ML_KEM_WITH_ECDH and its mechanism
parameter CK_IBM_ML_KEM_WITH_ECDH_PARAMS known to common code,
policy, statics, etc.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Change all Dilithium and Kyber related functions to be named as ML-DSA
and ML-KEM respectively, but ensure that they can be used for Dilithium
and ML-DSA, as well as Kyber and ML-KEM respectively.
While at it, refactor some code places to unify Dilithium/ML-DSA and
Kyber/ML-KEM functions.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The commit adds support for BLS 12 381 curve as part of CKM_IBM_ECDSA_OTHER
with CKM_IBM_BLS submechanism for EP11 token.
Signed-off-by: Vishnudatha Kanjur <kanjur@ibm.com>
Add defines for mechanism CKM_ECDH_AES_KEY_WRAP to the header file, the
mechanism table, as well as the policy and statistics code.
Field ulAESKeyBits of the CK_ECDH_AES_KEY_WRAP_PARAMS mechanism parameter
may not be set when performing unwrap. For unwrap, the size of the
temporary AES key is a result of unwrapping, and may not be known
by the caller. Field ulAESKeyBits should be set to zero if unknown.
In such cases the policy check can not check if the size of the
temporary AES key is according to the used policy.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add defines for mechanism CKM_RSA_AES_KEY_WRAP to the header file, the
mechanism table, as well as the policy and statistics code.
Field ulAESKeyBits of the CK_RSA_AES_KEY_WRAP_PARAMS mechanism parameter
may not be set when performing unwrap. For unwrap, the size of the
temporary AES key is a result of unwrapping, and may not be known
by the caller. Field ulAESKeyBits should be set to zero if unknown.
In such cases the policy check can not check if the size of the
temporary AES key is according to the used policy.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Policy and statistics code has a need to check certain fields of the mechanism
parameter structures. Check for correct mechanism parameter length and pointer
before attempting to access the mechanism parameter fields. This avoids
seg-faults in case an application passes an invalid mechanism parameter.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Ensure that the new SHA3 mechanisms, KDFs and MGFs are supported by all
common code utility functions, as well as policy and statistics code.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When the mechanism table size changes, because new mechanisms are added,
the size of the statistics shared memory segment also changes. This is
detected and the statistics are supposed to be cleared.
Fix the clearing by memsetting the whole statistics area, not just the
first few bytes.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add support for the CKM_IBM_BTC_DERIVE mechanism with the C_DeriveKey
function. Dependent on the BTC type in the mechanism parameter, a
private EC key or a public EC key is derived.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Support mechanism CKM_IBM_ECDSA_OTHER for sign and verify calls.
Adjust the mechanism parameter from the external format to the
EP11 format.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reported by coverty scan:
Error: CLANG_WARNING:
opencryptoki-3.18.0/usr/lib/api/statistics.c:71:17: warning[core.NullDereference]:
Access to field 'hashAlg' results in a dereference of a null pointer
(loaded from field 'pParameter')
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
There is no need to keep the shared memory file descriptor open after
the call to mmap(). So just close it right after the call to mmap().
This will not invalidate the memory mapping.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When running within a pid and/or user namespace, make sure to register
the process in pkcsslotd's shared memory segment using the pid from the
root namespace (the one pkcsslotd is running in), and not the applications
namespace. The application pid may be different to its pid in the root
namespace, and may especially be not unique within the root name space.
Since the pid is used as unique identifier in pkcsslotd's shared memory
segment we must use the applications pid in the root namespace.
Also use the uid from root namespace to create the shared memory segment
for user statistics. The uid in the applications namesapce may be different
to its uid in the root namespace, and may especially be not unique within
the root name space, and thus could cause that statistics of other users are
updated instead of the current user's one.
Trace files are still named using the pid of the applications namespace.
At the time the trace file is opened, the pid from the root namespace is
not yet know. There is a is a slight chance that two processes running in
different namespaces use the same pid, and thus use the same trace file.
In this case existing trace files may get overwritten or tracing is
disabled for a process. Re-opening the trace file once the process's pid
from the root namespace is known does not make much sense, since the
initial part of the trace has been written to the 'wrong' trace file
already at that time.
Since the initial data sent via socket is changed anyway, fix the following
issue right away:
Closes: https://github.com/opencryptoki/opencryptoki/issues/469
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Also count implicit mechanism usage, such as mechanisms referenced
from within mechanism params, i.e. RSA-PSS or RSA-OAEP hash mechanisms
or mask generation functions (MGFs), and key derivation functions (KDFs)
for ECDH key derivation.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
