Hi,
I’d like to give you a heads-up that build split feature branch will be merged back to main branch very soon this week.
Trusted-firmware-m build split branch: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/?h=feature…
Tf-m-tests build split branch: https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/?h=feature-build-s…
Build split feature improves how NS side integrate with TF-M SPE and therefore build commands are changed for building regression tests and PSA arch tests.
Could you please refer to https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/23898 for updated commands/configuration to integrate NS side and port platforms after build split?
If anything is broken after build split, please let us know. It would be also appreciated if you could contribute to build split. 😊
Any feedback or comment is welcome.
Best regards,
Hu Ziji
I have a few questions regarding RSS and Secure Enclave to see what's required and considered for SoC design to leverage RSS and why we nee to use RSS & TF-M
1. What is the difference between RSS and Secure Enclave?
- Is RSS the same as Secure Enclave?
- Or is it referring to any subsystem providing runtime crypto service regardless of whether it's a Secure Enclave or not?
Question below is assuming RSS is a Secure Enclave......
2. What enables TF-M to operate as a Secure Enclave?
- To operate as a Secure Enclave, HW support is mandatory?
a) If so, we must use a Secure Enclave IP such as cryptoisland(CI-300P-C)?
b) Or can we construct a Secure Enclave with some other IPs(LCM, KMU, CryptoCell) metioned RSS doc? (by using TF-M without secure enclave IP)
It feels vague whether this can be called a Secure Enclave...
https://tf-m-user-guide.trustedfirmware.org/platform/arm/rss/rss_key_manage…
- If HW support is not mandatory, I wonder how TF-M can operate as a Secure Enclave.
- The article below seems to say that TF-M can provide Secure Enclave functionality without HW support. or I may misunderstand.
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/tfm/technical_re…
Hi,
Reading through https://tf-m-user-guide.trustedfirmware.org/integration_guide/non-secure_cl… I'm wondering why so much of the work is done in the secure world. Ultimately, the secure world relies on the non-secure world to tell it the client_id, directly or indirectly. Is there a good reason for the NCSE part to reside in the secure world, rather than the non-secure?
Particularly as the document states that the non-secure RTOS may have a built-in "Secure Context Manager", there may well be redundancy between that and NCSE that could be eliminated if the NCSE was in the NSPE. And the less code there is in the secure world, the less scope for vulnerabilities.
If client_ids themselves were passed from the NS to the S world, it would probably be very easy to use that same interface on the NS core in a dual core system, too.
Chris
Hi,
Seems like following code
$<$<BOOL:TFM_PARTITION_PLATFORM>:${CMAKE_CURRENT_SOURCE_DIR}/services/src/tfm_platform_system.c>
In platform/ext/target/arm/corstone1000/CMakeLists.txt is wrong because it uses TFM_PARTITION_PLATFORM but should use ${ TFM_PARTITION_PLATFORM }
If so then maybe platform maintainers can fix this.
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Is 11.2-2022.02 the recommended compiler version?
I saw TF-M v1.8 states:
" GNU Arm compiler version *10-2020-q4-major* has an issue in CMSE
support. The bug is reported in `here <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99157>`__.
Select other GNU Arm compiler versions instead.
GNU Arm compiler version greater and equal than *11.3.Rel1* has a linker issue in syscall.
Select other GNU Arm compiler versions instead.
"
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
Hi,
When is it appropriate to use "__tz_c_veneer" vs. "__tfm_nspm_secure_gateway_attributes__"? The only difference appears to be placing it in "SFN" section.
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
Hello,
I am trying to build TF-M v1.8 with a custom tfm_mbedcrypto_config_profile_medium.h . I mainly do not want to use a platform specific calloc /free calls, instead use standard free() and calloc(). If I disable MBEDTLS_PLATFORM_MEMORY and MBEDTLS_PLATFORM_C in tfm_mbedcrypto_config_profile_medium.h and attempt to build TF-M, I get the following error:
/arm-none-eabi/lib/thumb/v8-m.main+fp/hard/libnosys.a(sbrk.o): in function `_sbrk':
/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/libgloss/libnosys/sbrk.c:21: undefined reference to `end'
I'm able to build mbedtls package with both MBEDTLS_PLATFORM_MEMORY and MBEDTLS_PLATFORM_C disabled without any errors, the undefined reference error is only seen when building TF-M.
Any thoughts on how to resolve this?
Regards,
Archanaa
Hi all,
Seems like dependency on generated files is broken.
Steps to reproduce:
1. Build any platform at any mode
2. Change any .template file
3.
Expected result:
1. New file is generated from the updated .template file
Actual result:
1. Generated files step is skipped.
My best guess will be that 1ce59292a47b1316e5d8b4d28bcaf9d8e2bdc0a5 broke it.
Could this be fixed?
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hello,
Some time ago we planned to rename our master branch to main in all 6 repositories. There are multiple ways of doing that and I want to discuss with the community the best way suitable for all.
I can see the following options:
1. rename master->main and use the main from one day.
2. Create the main for contribution with main->master sync. Make master R/O and delete it in 3 months.
3. Keep contributing to the master but syncing master->main.
4. Other way?
I suggest option 2 but looking for better alternatives if any.
Thanks,
Anton
Hi everyone,
The mailbox ns agent update document has the latest update to solidarize the API, here is the link for your review:
Docs: Mailbox non-secure vectors processing (Ie4ec599c) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/22282>
The agent-specific API should be good enough for now to handle different mailbox implementation cases, such as memory-based or non-memory-based.
* Non-secure provided vectors can be referenced directly to avoid extra copy.
* For non-memory-based schemes, the vectors have to be collected locally in NS Agent.
We are also updating the code to validate the new API, may touch those platforms that are mailbox-related, please take care of the patches as well.
SPM: Update the agent API to follow the design (I38e67578) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/22608/2>
BR
/Ken
