-
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
tfm: Move TF-M attestation data to provisioned OTP region #17522
base: main
Are you sure you want to change the base?
tfm: Move TF-M attestation data to provisioned OTP region #17522
Conversation
CI InformationTo view the history of this post, clich the 'edited' button above Inputs:Sources:sdk-nrf: PR head: 9e47ba20692227086d1d95b67a3274ea2f7514cb more detailssdk-nrf:
Github labels
List of changed files detected by CI (14)
Outputs:ToolchainVersion: f51bdba1d9 Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped;
|
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. |
5f309ff
to
956c258
Compare
include/bl_storage.h
Outdated
#if CONFIG_BUILD_WITH_TFM | ||
|
||
static uint32_t get_monotonic_counter_collection_size(const struct counter_collection *collection) | ||
{ | ||
/* Add only the constant part of the counter_collection. */ |
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.
Why are these functions introduced inside header file? These are not marked as inline. Also, as these are static, it means that multiple implementations might end up in the flash. One for each .c file that uses these.
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 functions are inside header file as they are used both in MCUboot and in application (TF-M). This is how it was previously achieved and I did not change this (yet). Having the functions inside bl_storage.c would mean that the bl_storage.c would be split with functions / headers that are available in MCUboot and functions / headers that are available in TF-M.
I guess we are already kind of doing the same in header file, so if you think that moving this split to bl_storage.c would be an improvement, I can give it a go.
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.
Functions moved to bl_storage.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.
Otherwise looks OK, but I don't understand why the implementation is inside header file and not in bl_storage.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.
Overall this looks good!
Some comments but I don't see anything seriously wrong with this.
Next time if you can please split such a change to more commits so that it is a bit more easy to follow.
I will give a second look to this before I approve.
@@ -0,0 +1,38 @@ | |||
# Copyright (c) 2024 Nordic Semiconductor |
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.
Doesn't that seem a bit out of place here?
I think that placing this in the same file with the rest of the TFM configurations makes it more logical to me:
sdk-nrf/modules/trusted-firmware-m/Kconfig
Line 473 in 9190d3a
I am not an expert on sysbuild but is the the only way to have this information to be visible by all the images in the build?
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 provisioning is done for the MCUboot, so it does not see the Kconfigs of the application. It might be possible to change this to include Kconfigs of the application, but whether this makes sense would need input from @nordicjm.
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.
sysbuild files go in sysbuild, this is the correct folder
@@ -336,6 +458,124 @@ NRFX_STATIC_INLINE int update_life_cycle_state(enum lcs next_lcs) | |||
return -EINVALIDLCS; | |||
} | |||
|
|||
#if CONFIG_BUILD_WITH_TFM |
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 is be defined in the TFM build I think.
12eebf3
to
db6ad7e
Compare
Memory footprint analysis revealed the following potential issuessample.matter.template.release[nrf7002dk/nrf5340/cpuapp]: High ROM usage: 811902[B] - link (cc: @kkasperczyk-no @ArekBalysNordic @markaj-nordic) Note: This message is automatically posted and updated by the CI (latest/sdk-nrf/PR-17522/10) |
Tried running: With my commit and without my commits. There was no difference, except saving 14 bytes with b0n, so I think that the space warning is due to other commits on main branch. I did have to disable the following: |
Add bl_storage.c to TF-M to reduce complexity on bl_storage.h. Signed-off-by: Markus Lassila <[email protected]>
Optional fields to TF-M attestation were previously stored in tfm_otp_nv_counters region, which we were not able to provision. This moves the psa_certification_reference to the provisioned OTP-region and adds support for accessing the variable data in bl_storage.h. Verification service URL and profile may change with device upgrades, for this reason they are added as Kconfigs. Note that we still need to keep the tfm_otp_nv_counters region when TFM_PARTITION_PROTECTED_STORAGE and TFM_PS_ROLLBACK_PROTECTION are enabled. TF-M will increase monotonic counters every time new data is written and given the limited size of our OTP-region it would not support many updates. NCSDK-17932 Signed-off-by: Markus Lassila <[email protected]>
db6ad7e
to
9e47ba2
Compare
Optional fields to TF-M attestation were previously stored in tfm_otp_nv_counters region, which we were not able to provision. This moves the psa_certification_reference to the provisioned OTP-region and adds support for accessing the variable data in
bl_storage.h.
Verification service URL and profile may change with device upgrades, for this reason they are added as Kconfigs.
Note that we still need to keep the tfm_otp_nv_counters region when TFM_PARTITION_PROTECTED_STORAGE and TFM_PS_ROLLBACK_PROTECTION are enabled. TF-M will increase monotonic counters every time new data is written and given the limited size of our OTP-region it would not support many updates.
NCSDK-17932
The PR is still lacking the following:
However, I would like to get feedback at this point as I am unsure whether the direction I have taken this is on line what we are intending to do in regards to bl_storage and T-FM. I am hoping to get comments for this at least from @frkv and @Vge0rge.