-
Notifications
You must be signed in to change notification settings - Fork 317
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
Nrf security cleanups #575
Nrf security cleanups #575
Conversation
set(MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER False) | ||
|
||
# Add a library to propagate configurations and paths to TF-M | ||
add_custom_target(nrf_security_target) |
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 don't know all the details on the reasoning behind the nrf_security_target, but I am curious how (and if) this can be removed.
Also curious how this will run in the dual execution of the nrf_security build (once in NSPE with zephyr build system, once inside TFM/SPE build without zephyr build system)
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 assume this can be cleaned up as @SebastianBoe proposes 👍
A bit of history.
The reason for this was because originally we could not pass TF-M CMake options directly to TF-M build, but only through Kconfig.
Notice this code is from March 11 (PR: #426, March 9):
ab66d4a
and the TFM_CMAKE_OPTIONS came in place in May 7:
zephyrproject-rtos/zephyr#34868
In the Kconfig indirection initial code, it was passed like this:
sdk-nrfxlib/nrf_security/Kconfig
Lines 1665 to 1667 in ab66d4a
config TFM_EXTRA_CMAKE_ARGS | |
string | |
default "-DMBEDCRYPTO_PATH=${ZEPHYR_NRFXLIB_MODULE_DIR}/nrf_security -DNRF_SECURITY_SETTINGS=$<TARGET_PROPERTY:nrf_security_target,CMAKE_ARGS>" |
thus the reason for nrf_security_target
.
So I think this can and should be cleaned up.
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.
maybe part of the description I just provided above would be useful in the commit message as to why this code was looking like this, and why it can now be cleaned up.
Can help the next one going through commit history / blame to understand the history behind this cleanup.
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.
Excellent to be able to remove complex generator expressions and additional targets!
Looking forward to trying to clean the code up more and make it more readable!
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.
commit message re-written
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.
Thanks for putting this together.
Careful on the docs though 😉
Prerequisites | ||
############# |
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 don't think this should be deleted.
Maybe rephrased if the reason behind the guide is not clear, but the reason for this guide is to make it clear how nRF Security can be used when west
is not used / installed.
For example, Zephyr has this guide on how to specify Zephyr modules when not using west
:
https://docs.zephyrproject.org/latest/guides/modules.html#without-west
But the arm Mbed TLS repo is not a Zephyr module, thus if a user is not using west, then it's insufficient to add the arm Mbed TLS repo to the list of Zephyr module, cause it will not be processed as a module (it's missing zephyr/module.yml
).
Therefore it's importent to inform the reader about setting ARM_MBEDTLS_PATH
in this case.
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.
Changed to retain the docs on ARM_MBEDTLS_PATH.
set(MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER False) | ||
|
||
# Add a library to propagate configurations and paths to TF-M | ||
add_custom_target(nrf_security_target) |
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 assume this can be cleaned up as @SebastianBoe proposes 👍
A bit of history.
The reason for this was because originally we could not pass TF-M CMake options directly to TF-M build, but only through Kconfig.
Notice this code is from March 11 (PR: #426, March 9):
ab66d4a
and the TFM_CMAKE_OPTIONS came in place in May 7:
zephyrproject-rtos/zephyr#34868
In the Kconfig indirection initial code, it was passed like this:
sdk-nrfxlib/nrf_security/Kconfig
Lines 1665 to 1667 in ab66d4a
config TFM_EXTRA_CMAKE_ARGS | |
string | |
default "-DMBEDCRYPTO_PATH=${ZEPHYR_NRFXLIB_MODULE_DIR}/nrf_security -DNRF_SECURITY_SETTINGS=$<TARGET_PROPERTY:nrf_security_target,CMAKE_ARGS>" |
thus the reason for nrf_security_target
.
So I think this can and should be cleaned up.
902b7b7
to
ed59c3c
Compare
@tejlmand : All feedback has been addressed. Please re-assess review. |
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.
Thanks for putting this together 👍
A small comment to consider.
************* | ||
|
||
Mbed TLS is required and usually provided by west, but it can also be | ||
manually configured with the CMake variable ``ARM_MBEDTLS_PATH``. |
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 specify that the ARM_MBEDTLS_PATH
should point to the top-level folder of the arm Mbed TLS repository ?
Or is that obvious.
@frkv thoughts ?
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.
That is obvious IMHO.
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 should be obvious, agreeing with @SebastianBoe
Don't hide the psa configs in a file. This abstraction is unnecessary. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Re-use the shared code between the two macros kconfig_mbedtls_config and kconfig_mbedtls_config_val. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
ed59c3c
to
70a923a
Compare
@frkv : Can we have a +1 ? |
Delete nrf_security_target as it became redundant after TFM_CMAKE_OPTIONS was introduced. Also, put the short clause in the if-else first for readability. And move the common code out of the if-else. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Remove documentation of what error messages mean and inline the remaining content as it is not enough information to deserve a full chapter now. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
70a923a
to
df0d494
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.
LGTM
Merged without manifest PR to save time. |
This PR slightly broke documentation structure. Kindly please do not merge doc-required PRs without an approval from a tech writer. Follow-up task: https://projecttools.nordicsemi.no/jira/browse/NCSDK-12851 |
@greg-fer : Noted. Sorry. |
Misc. cleanups done to understand nrf_security build scripts.
See commit messages for details.