-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not Review: Move CRACEN mutexes to threading_alt.c #18140
Conversation
CI InformationTo view the history of this post, clich the 'edited' button above Inputs:Sources:sdk-nrf: PR head: 71dd95feb7450e89892ad688e90c3ff4a8d10400 more detailssdk-nrf:
oberon-psa-crypto:
Github labels
List of changed files detected by CI (17)
Outputs:ToolchainVersion: add720b6d9 Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped;
|
d8c120c
to
92f399b
Compare
__ASSERT(mbedtls_mutex_lock(&cracen_mutex) == 0, | ||
"cracen_mutex not initialized (lock)"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Separate asserts from the actual action, so that the action is still performed even when asserts are disabled.
e.g.:
__ASSERT(mbedtls_mutex_lock(&cracen_mutex) == 0, | |
"cracen_mutex not initialized (lock)"); | |
const int lock_ret = mbedtls_mutex_lock(&cracen_mutex); | |
__ASSERT(lock_ret == 0, "cracen_mutex not initialized (lock)"); |
__ASSERT(mbedtls_mutex_unlock(&cracen_mutex) == 0, | ||
"cracen_mutex not initialized (unlock)"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are asserts on unlock actually needed? Because your assert message suggests that no (they both only fail if the mutex is not initialized). If yes, update the assert message.
@@ -24,7 +24,7 @@ | |||
|
|||
static int users; | |||
|
|||
NRF_SECURITY_MUTEX_DEFINE(cracen_mutex); | |||
extern mbedtls_threading_mutex_t cracen_mutex; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could those be declared in a header file instead?
@@ -24,13 +24,16 @@ static uint32_t prng_pool[PRNG_POOL_SIZE]; | |||
static uint32_t prng_pool_remaining; | |||
|
|||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Too many newlines in here.
@@ -111,15 +112,19 @@ void sx_pk_wrreg(struct sx_regs *regs, uint32_t addr, uint32_t v) | |||
printk("sx_pk_wrreg(addr=0x%x, sum=0x%x, val=0x%x);\r\n", addr, (uint32_t)p, v); | |||
#endif | |||
|
|||
wmb(); /* comment for compliance */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems weird to me. wmb()
and rmb()
are defined as inline functions. What did compliance say here exactly?
-This commit ensures that the check if we are calling from ISR and/or kernel is used for CRACEN (which doesn't allow mutex-interaction). -This commit checks for failures to lock with asserts -Change cracen to use mbedtls_mutex_lock/unlock -Change cracen mutexs init to happen in threading_alt.c through the post-kernel SYS_INIT. Signed-off-by: Frank Audun Kvamtrø <[email protected]>
-Add memory barrier wmb() and rmb() around writes and reads for pk module (IKG) for cracen. Signed-off-by: Frank Audun Kvamtrø <[email protected]>
-This commit moves checks to ensure we aren't in pre_kernel/ISR into its own function to ensure that this can be compiled in TF-M which will be the case for CRACEN enabled devices. -Adding static function is_pre_kernel_or_isr which is checks if TF-M and MultiThreading is enabled Signed-off-by: Frank Audun Kvamtrø <[email protected]>
-This commit adds PSA_CRYPTO_THREAD_SAFE as a configuration that filters thread-safety enablement for PSA crypto APIs (front-end). -This commit adds a version of oberon-psa-crypto which supports PSA_CRYPTO_THREAD_SAFE (by updating the manifest) -This commit adds the Kconfig MBEDTLS_PSA_CRYPTO_DISABLE_THREAD_SAFETY which is used to ensure PSA_CRYPTO_THREAD_SAFE can be disabled if there is a wish to not enable thread-safety for the PSA crypto front-end APIs (separated from thread-safety for legacy Mbed TLS APIs and HW accelerated drivers. -This update includes a manifest-update to ensure that this change is bisectable. -Enable Mbed TLS threading APIs in nrf_security regardless if MBEDTLS_THREADING_C is enabled so they can be shared with cracen. -Add external prototypes for mbedtls_mutex_xxxx APIs that is used regardless if threading is actually enabled Note: This commit is done to try to resolve an ABI compliance issue with pre-compiled OpenThread libraries. Signed-off-by: Frank Audun Kvamtrø <[email protected]>
92f399b
to
71dd95f
Compare
The following west manifest projects have been modified in this Pull Request:
Note: This message is automatically posted and updated by the Manifest GitHub Action. |
You can find the documentation preview for this PR at this link. It will be updated about 10 minutes after the documentation build succeeds. Note: This comment is automatically posted by the Documentation Publishing GitHub Action. |
This pull request has been marked as stale because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 7 days. Note, that you can always re-open a closed pull request at any time. |
This PR changes CRACEN to use Mbed TLS threading primitives instead of directly calling nrf_security_mutex APIs.
This PR is not ready for review and is only used to run tests for some complex ABI compliance issues with OpenThread