-
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
entropy: Add PSA rng as the entropy provider for the nrf54h20 #17200
base: main
Are you sure you want to change the base?
Conversation
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. |
CI InformationTo view the history of this post, clich the 'edited' button above Inputs:Sources:sdk-nrf: PR head: 1df584d4a041d2c22ca95c176e316068220ac9d1 more detailssdk-nrf:
zephyr:
Github labels
List of changed files detected by CI (25)
Outputs:ToolchainVersion: f51bdba1d9 Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped;
|
387c99f
to
1a1154a
Compare
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. |
114059e
to
6ed58b2
Compare
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.
Again in this PR you have a commit that is later reverted (nrf_security: Enabled by default for nRF54H20
)?
subsys/nrf_security/CMakeLists.txt
Outdated
@@ -102,8 +102,29 @@ endif() | |||
|
|||
set(CONFIG_MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG True) | |||
|
|||
if(CONFIG_PSA_SSF_CRYPTO_CLIENT AND NOT CONFIG_NRF_SECURITY) |
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.
So CONFIG_PSA_SSF_CRYPTO_CLIENT
is independent from CONFIG_NRF_SECURITY
but still using some of its CMake logic? I'm wondering if this can potentially cause some issues...
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.
The thing is that right now SSF is enabled with NRF_SECURITY. So that setup works currently. I didn't want to change the existing setup in this PR. What I did is to allow enabling it even when NRF_SECURITY is not used. This is useful for applications which just needs RNG for example and I didn't want to force enabling NRF_SECURITY for these yet.
This should not be the final solution to this, this is basically the starting point to allow widely usage of RNG from Cracen. The next step on this would be that we refactor nrf_security to allow building with the SSF client with minimal configuration/code overhead.
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.
So if we allow enabling it even when NRF_SECURITY
is not enabled, wouldn't it make sense to move the logic away from it? 🤔
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.
I was considering this, but since I believe that soon we will refactor nrf_security to have minimal impact for this build configuration I decided to not separate them. That's because if nrf_security becomes more minimal we will make this configuration a part of nrf_security again.
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 are lots of complex additions in this PR that seem to be tailored towards a special case without PSA crypto which is the default enabled and default supported in nRF54H20 devices
b8fb7cd
to
7e9300c
Compare
60aa10e
to
a5fff26
Compare
a5fff26
to
d126eb1
Compare
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.
The complexities mentioned can be resolved at a later point with some reverts
It is good enough to go in
d126eb1
to
a9119e6
Compare
0b9e4cd
to
8fb5f36
Compare
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.
I'm just not sold on having logic pertaining to PSA_SSF_CRYPTO_CLIENT
intermingled with NRF_SECURITY
even though it's now made independent. They should rather be properly separated.
${ZEPHYR_OBERON_PSA_CRYPTO_MODULE_DIR}/library | ||
# Mbed TLS (mbedcrypto) PSA headers | ||
${ARM_MBEDTLS_PATH}/include | ||
${ARM_MBEDTLS_PATH}/library |
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 those two /library
paths actually needed?
not blocking nor endorsing those changes
cf97475
to
08b8386
Compare
Make all PSA drivers depend on the OBERON_PSA_CORE since we cannot use the drivers without it. Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
Brings Zephyr changes which automatically enable the PSA crypto as the entropy generator for Zephyr. Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
Add configuration to allow enabling the SSF PSA client when nrf_security is not enabled. This is particularly useful for the applications that only want to use the PSA rng and no other crypto. Enabling nrf_security in these applications will result to an increased application footprint and configuration complexity without any reason. This configuration provides the PSA implementation from the secure domain through the SSF client and it has no configurability yet. So there is no need to enforce NRF_SECURITY with this configuration. Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
Add overlay to reduce the footprint of the matter_bridge application. Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
Remove prng dts node since this is removed from the nrf54h20 board file. Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
The changes to enable PSA RNG on 54H20 made sample.suit.smp_transfer.recovery overflow ROM on recovery_hci_ipc. Slightly increase the size of the cpurad_recovery_partition so that everything fits. Signed-off-by: Tomi Fontanilles <tomi.fontanilles@nordicsemi.no>
Remove the call to the ssf_psa_crypto_init since the psa_crypto is initialiazed in SDFW and it doesn't need to get initialized from the application. Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
Disable the IPC and bellboard nodes since these tests don't use communication between domains. Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
In a comment, tHe -> The Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
Initialize the ssf_client earlier during the boot process during post kernel. This is needed for the "nRF IEEE 802.15.4" protocol. (CONFIG_NRF_802154_SER_RADIO) This protocol requires entropy to be present and ssf_client is required to get entropy. Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
08b8386
to
1df584d
Compare
@nrfconnect/ncs-co-build-system Please check your relevant parts. |
config PSA_SSF_CRYPTO_CLIENT | ||
bool | ||
prompt "PSA crypto provided through SDFW Service Framework (SSF)" | ||
default y | ||
depends on SSF_CLIENT && SSF_PSA_CRYPTO_SERVICE_ENABLED |
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.
Just an observation: since the SSF PSA crypto client exists solely as a backend for this API, we could consider integrating it more closely in the future
} | ||
|
||
return rsp.psa_crypto_rsp_status; | ||
return PSA_SUCCESS; |
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.
Should we remove the server part of this API? We could keep it as a no-op there as well.
@@ -21,7 +21,10 @@ if(NOT SYSBUILD) | |||
endif() | |||
endif() | |||
|
|||
add_subdirectory_ifdef(CONFIG_NRF_SECURITY nrf_security) | |||
if(CONFIG_NRF_SECURITY OR CONFIG_PSA_SSF_CRYPTO_CLIENT) | |||
add_subdirectory(nrf_security) |
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.
2 space indent
) | ||
|
||
zephyr_sources(${CMAKE_CURRENT_LIST_DIR}/src/ssf_secdom/ssf_crypto.c) | ||
|
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.
@@ -88,6 +106,9 @@ else() | |||
nrf_security_debug("Building for pure Zephyr") | |||
endif() | |||
|
|||
# This check is needed for the cases that CONFIG_PSA_SSF_CRYPTO_CLIENT | |||
# is enabled but the CONFIG_NRF_SECURITY is not enabled | |||
if(CONFIG_NRF_SECURITY) | |||
set(CONFIG_MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG True) |
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.
indent section
No description provided.