-
Notifications
You must be signed in to change notification settings - Fork 3k
TF-M sources integration to Mbed-OS #9653
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
Conversation
@mikisch81, thank you for your changes. |
@mikisch81, thank you for your changes. |
1 similar comment
@mikisch81, thank you for your changes. |
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 splitting. Looks good to me 👍
Please add release notes section, following https://os.mbed.com/docs/mbed-os/v5.11/contributing/workflow.html#functionality-change |
@mikisch81 Good news!
Those two PRs are now merged in to Mbed OS, so rebasing this PR will make them disappear from this PR! Please do so to make review of this PR a bit cleaner. |
Rebased this PR on top of |
Latest update removes the workaround we did in crypto partition and adds another patch to TF-M sources which fix an internal TF-M issue. |
@0xc0170 Added release notes |
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 tools/tfm
folder looks very similar to the existing tools/spm
code in terms of the json
and py
files. Are there plans to merge these in a coming PR? Lots of the code appears to be duplicated.
@@ -3,8 +3,8 @@ | |||
"type": "APPLICATION-ROT", | |||
"priority": "NORMAL", | |||
"id": "0x0000000A", | |||
"entry_point": "pits_entry", | |||
"stack_size": "0x400", | |||
"entry_point": "its_entry", |
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.
Was this rename intentional?
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.
yes, ITS is the correct name
@@ -0,0 +1,196 @@ | |||
{ |
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 file is identical to the file found here: https://github.com/ARMmbed/mbed-os/tree/master/tools/spm
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.
it's basically is a duplicate with minor changes, we'll remove the unneeded duplicates
tools/tfm/__init__.py
Outdated
@@ -0,0 +1,23 @@ | |||
# Copyright (c) 2017-2018 ARM Limited |
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 file is identical: https://github.com/ARMmbed/mbed-os/blob/master/tools/spm/__init__.py
tools/tfm/generate_partition_code.py
Outdated
@@ -0,0 +1,689 @@ | |||
#!/usr/bin/python |
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 file shares most of the same codes as this one: https://github.com/ARMmbed/mbed-os/blob/master/tools/spm/generate_partition_code.py
There are a decent amount of changes though.
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.
Eventually everything under tools/spm
will be removed when TFM will support dual-core, it will be easier to remove if it does not share stuff with tools/tfm
.
@@ -0,0 +1,37 @@ | |||
/* Copyright (c) 2017-2019 ARM Limited |
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.
General question: any reason for going with .inc
instead of .h
? Mbed OS generally sticks with .h
I believe.
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.
+1
The only other file that uses a .inc
suffix in Mbed OS is features/FEATURE_BLE/targets/TARGET_CORDIO_LL/thirdparty/uecc/asm_arm.inc
, and even that's third party.
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.
These are the partition header files used by TF-M.
TF-M actually generated these files according to their secure partitions manifests.
But because we use our own partitions we need to generate those headers ourselves.
So in order not to change TF-M imported code we keep the same suffix.
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 in order not to change TF-M imported code we keep the same suffix.
Good enough for me!
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.
Actually, I'm not even sure if our build system picks up .inc
files. Looking here: https://github.com/ARMmbed/mbed-os/blob/master/tools/resources/__init__.py#L413-L432
Seems like it won't be brought in as an include directory, does that sound right @theotherjimmy ?
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.
@mikisch81 I believe that's working because there are other .h
files present in the directory, so it is being picked up as an include path. If you removed all of the other .h
files and just had .inc
files, I don't believe the build system would keep that directory as an include 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.
One of the generated files is an .h
file, so you are probably right, but all these files are generated together and shouldn't move or change afterwards.
We can ask TFM why the inc extension instead of regular .h
.
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.
@bridadan We really need to avoid changing imported TF-M code, the only exceptions should be blocking issues (like bugs or porting 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.
If this is a TF-M imported thing then I understand. We should get an issue filed to add .inc
to our list of header file types in our 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.
PR up for this issue: #9715
@@ -22,4 +22,5 @@ TESTS/mbed_hal/trng/pithy | |||
targets | |||
components/802.15.4_RF | |||
components/wifi | |||
components/TARGET_PSA/TARGET_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.
@ARMmbed/mbed-os-maintainers Heads up, another large block of code that's about to be ignored by astyle
Might need to talk with techleads about why components seems to be special in regards to code styling.
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.
Everything under TARGET_TFM
is imported from an external source, so it should be ignored by astyle as I see 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.
LGTM
@bridadan |
I understand @mikisch81. Definitely want to keep compatibility with what was delivered in 5.11. In the future are the tfm and spm tools expected to merge? Or will they always stay separate for versioning reasons? Looking at the main |
@bridadan as soon as TFM will have dual-core support we will do a new import and regenerate the needed files again. There is no versioning constraint here |
I am working on consolidating |
- ITS - Crypto - Platform
- Avoid compiling user_setup_stackheap for TF-M secure targets - Align sbrk for TF-M
Rebased PR on top of master |
@0xc0170 Done |
I'll run CI. @SenRamakri / @donatieng final review call |
CI started meanwhile |
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.
Approved based on email discussions. Musca related items will be coming in #9221
Test run: SUCCESSSummary: 12 of 12 test jobs passed |
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 have minor comments/questions and would be good if you can answer them, but they are not blockers, so approved.
#include "secure_fw/core/tfm_secure_api.h" | ||
|
||
#define SPM_INVALID_PARTITION_IDX (~0U) | ||
|
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.
Does these enums require Doxygen comments?
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 file is also imported.
#define TFM_PARTITION_TYPE_APP "APPLICATION-ROT" | ||
#define TFM_PARTITION_TYPE_PSA "PSA-ROT" | ||
|
||
#define TFM_STACK_SIZE 1024 |
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 TFM_STACK_SIZE be configurable, driven from config files? On what basis we are hardcoding this to 1024?
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.
Actually each partitions' stack size is configured in their manifest, this is one of our patches to TFM code, see commit fc78640, so TFM_STACK_SIZE
is not used anymore.
tfm_spm_partition_set_state(idx, SPM_PARTITION_STATE_IDLE); | ||
} else { | ||
tfm_spm_partition_err_handler(part, TFM_INIT_FAILURE, res); | ||
fail_cnt++; |
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.
Minor thing, but can't we just break here(right after fail_cnt++) instead of looping again? Or is it really required to call err_handler for each error?
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 file is imported from TFM repository (same as cmsis code), we added patches but they are mainly fixes for issues which were raised during the Musca port.
*/ | ||
#define TFM_CLIENT_ID_IS_NS(client_id) ((client_id)<0) | ||
|
||
/* FixMe: sort out DEBUG compile option and limit return value options |
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.
FixMe?? Should this be fixed?
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 file is also imported.
Final review responses look alright. Merging. |
Description
This PR introduces TF-M sources into Mbed-OS according to ISGDEVPREQ-1027.
TF-M sources were imported into mbed-os tree using the same Importer script as CMSIS, afterwards a series of patches were applied which fix some issues and align the code to work with Mbed-OS.
The TF-M sources were imported from the feature-ipc branch of the TF-M repository, hash 45e5276bc04036654693cbf335829aa15a64ed5f.
Commit 34433bc added a manifest json file which lists the files/folder needed to import and a list of SHAs to apply afterwards.
We did not import TF-M partitions (Crypto, Attestation, etc..) as we are re-using the existing partitions in Mbed-OS (Internal-storage, PSA-Crypto and Platform), commit 42d8f2b adds an auto-generation tool which generated in
commit c855263 all the partitions' header files needed by TF-M core.
Pull request type
Release notes
The PSA program offers a reference implementation (TF-M) aimed at facilitating the deployment of PSA among RTOS vendors. TF-M is an OS-agnostic project, it presents generic methods to achieve PSA secure partitioning and offer PSA secure services like attestation, secure storage, or crypto. Integrating TF-M allows Mbed OS to achieve PSA compatibility.
Mbed OS has imported the TF-M core to be used by its' own secure services.
Currently only v8m targets can run TF-M, for porting TF-M to be used by a target please refer TF-M integration guide.
Reviewers
@gaborkertesz @ashok-rao @deepikabhavnani @ARMmbed/mbed-os-psa @ARMmbed/mbed-os-tools