Hi experts,
Recently we're developing a demo based on TF-M, this demo involves using
SPI module to drive a sensor by sending commands in a secure partition.
And we need to enable SPI receive and send interrupt in this secure
partition and the latency shall be as small as possible. I am wondering
how to implement this secure interrupts. Is there any example code or
instrucstions?
Thanks.
Best Regards,
Poppy Wu
吴偏偏
Macronix Microelectronics (Suzhou) Co.,Ltd
旺宏微电子（苏州）有限公司
http://www.mxic.com.cn
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
Hi TF-Mers,
There are several versions of mem* API set in the system.
At the very beginning, the whole secure firmware was put in the library model, and it is expected to be self-contained -- at least at the source level as the first step. Hence a 'tfm_mem*' API set is created for secure firmware usage. The same reason for involving 'spm_mem*' in the PSA compliance model.
When we designed HAL for SPM, we noticed that SPM HAL actually run in the same domain as SPM, hence we encouraged developers to use 'spm_mem*' in SPM HAL.
This brings a bit of difficulty, especially when the platform sources are shared for multiple targets, while other targets do not have 'spm_mem*' API.
As 'mem*' is actually common enough (as they are fundamental API of libc), hence redefine the name is applicable only a system is highly self-contained. In our case, using 'mem*' API can bring much convenience. Hence I am thinking to let sources other than SPM use 'mem*' API, they are platform, partitions and runtime libraries. For SPM sources (under secure_fw/spm), a source-level 'spm_mem*' is kept, to keep the possibility to make SPM itself really self-contained. Now it is only source-level because 'spm_mem*' is actually forwarded to 'mem*'.
I am creating a patch to change this, and want to know your opinion.
Thanks.
/Ken
Hi,
Is there anyone using environment variables for the "manifest" attribute in out-of-tree manifest lists?
I'm asking because I'm working to support configurable stack_size for Secure Partitions<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15155>.
In the patch the support of environment variables in manifest lists is removed<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15155/1/tool…>.
Because I have to call the CMake command configure_file to replace the stack_size symbols (CMake variables<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15155/1/secu…> surrounded with "@") with their values.
While configure_file does not recognize environment variables.
If you do have environment variables in manifest list, there is an alternative:
Replace the env. variables with CMake variables surrounded with "@" and set the value of the CMake variables in either config files or command line inputs.
Best Regards,
Kevin
Hi all,
I'd like to cancel tech form in May 12 due to empty agenda.
Best regards,
Hu Ziji
From: David Hu via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Thursday, May 5, 2022 2:11 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - May 12
Hi,
(On behalf of Anton)
The next Technical Forum is planned on Thursday, May 12, 15:00-16:00 UTC (West time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Hu Ziji
Hi,
the initial attestation token implementation is aligned with this specification:
https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-05
This spec is still evolving and there is a newer version which changes the key values of the claims in the token:
https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab…<https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html%23t…>
This can cause combability issues between token issuer (device) and token verifier (some remote verification service).
This is an ABI change between token issuer and consumer.
The breaking effect would be manifest in unaccepted IAT tokens by the verifier.
On-device side I see these options to make the transition:
- A build-time option could be introduced which determines which range of key numbers to use. The default value would be the new range. To not let new users pick up the old values accidentally. Existing users can notice the incompatibility issue during the integration test and adjust their build command accordingly. However, the old range would be announced as deprecated in the next TF-M release, then will be removed in the next release after.
- Immediate switch over to the new range, without supporting the old range anymore. On the verification service side, an SW update can handle the transition and might be accepting both ranges for a while. I assume the verification service can be updated more easily than remote devices therefore better to handle the compatibility issue there.
- Keeping the support for both ranges for the long term and letting users choose by build time.
Please share your thoughts on:
- Are you aware that the attestation service is used in deployed devices where this transition can cause incompatibility?
- From the above list which option would you vote to support the transition?
Best regards,
Tamas Ban
Hi,
In one of the past tech forums, we claimed that we don't encourage contribution in common logic in assembly, and one of the patches was abandoned because of this. That patch is designed to improve the memset/memcpy performance.
We override these APIs in general because we want the code can be auditable. Then we provided implementations in C, but it shows these implementation does not provide good performance. We want to apply the toolchain provided versions, and looks GNU tool provides the straightest 'byte-copy' version. And armclang involves unnecessary variants which increase the code size a little (not big).
Hence we provide a version with 'tiny' optimization in assembly and mark this patch an exception to the review guidelines, as these under-layer functions won't get changed frequently. We are also seeking an ideal way to apply toolchain versions.
The patch is here for your review:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13735
Thanks.
/Ken
Hello all,
I wanted to let you know that I made the PR which adds encryption on ITS files using the methodology that we discussed before. The encryption is happening in a transparent way for the user, and I tried to avoid major changes in the ITS filesystem. Please add yourself as a reviewer and provide feedback if you think that this is an interesting use case for you.
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15096
Regards,
Georgios Vasilakis
Hi,
(On behalf of Anton)
The next Technical Forum is planned on Thursday, May 12, 15:00-16:00 UTC (West time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Hu Ziji
Hello,
I am pleased to announce the new v1.6.0 released of TF-M project.
New major features are:
* MCUboot updated to v1.9.0.
* Mbed TLS updated to v3.1.0 (Support all required PSA Crypto APIs).
* Enabled Secure Function (SFN) Model Partition compliance in IPC backend.
* Interrupt support (both SLIH/FLIH) for the SFN backend.
* MM-IOVEC Support for the SFN backend.
* The following Secure Partitions are converted to SFN model:
* Protected Storage
* Internal Trusted Storage
* Initial Attestation
* FF-M v1.1 SFN Model supported in Profile Small.
* HAL Separation of Library Model and IPC/SFN backend.
* FP support for Armv8.1-M Mainline for IPC backend.
* Simplified build output message and configurable output.
* Halting instead of rebooting on panic in debug build type.
* Automated testing of MCUboot BL2.
* A new driver interface for the CC-312 runtime library as specified in the PSA Unified Driver spec [1]_.
* Added reference bootloader stage 1 (BL1) bootloader for certain platforms.
* A new CC312 ROM library for the BL1.
* Updated documentation structure.
The changes tagged by TF-Mv1.6.0 and located in the release/v1.6.x<https://review.trustedfirmware.org/q/project:TF-M%252Ftrusted-firmware-m+br…> branch at the moment.
In short, they will be integrated with the main branch and be available from there.
Thanks everyone for contribution, review and support this milestone.
Anton
Hi,
The next Technical Forum is planned on Thursday, April 28, 7:00-8:00 UTC (East time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi everyone,
We have discussed the design proposal of supporting secure Flash in tf-m
framework via this mailing list before,now the implementation code of this
external trusted secure storage partition has been uploaded to tf-m-extras
repo for review：
https://review.trustedfirmware.org/c/TF-M/tf-m-extras/+/14953
And the binary component of this patch has also been uploaded to
tf-binaries repo：
https://review.trustedfirmware.org/c/tf-binaries/+/14954
For easy understanding please refer to this document first:
https://review.trustedfirmware.org/c/TF-M/tf-m-extras/+/14953/1/partitions/…
Looking forward to your comments and suggestions.
Best Regards,
Poppy Wu
吴偏偏
Macronix Microelectronics (Suzhou) Co.,Ltd
旺宏微电子（苏州）有限公司
http://www.mxic.com.cn
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
Hello,
The branch release/1.6.x<https://git.trustedfirmware.org/TF-M%2Ftrusted-firmware-m.git/log/?h=refs%2…> has been created, indicating the project feature's freeze and beginning the release process. Expecting to place RC1 tag asap, after successful run of the basic tests.
Let me remind that the code is not frozen, and development can be continued on the main branch.
Thanks,
Anton
Hi All,
TF-M Open CI is back to normal now.
Please feel free to use it.
Thanks,
Xinyu
From: Xinyu Zhang via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Monday, April 18, 2022 12:06 PM
To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] TF-M Open CI Down
Hi All,
Sorry to inform you that TF-M Open CI is down for the time being because of Jenkins upgrade.
I'll let you know once it is back to normal.
Apologize for any inconvenience!
Thanks,
Xinyu
Hi All,
Sorry to inform you that TF-M Open CI is down for the time being because of Jenkins upgrade.
I'll let you know once it is back to normal.
Apologize for any inconvenience!
Thanks,
Xinyu
Hi,
The forum is cancelled because of the empty agenda and the assumption that many of us in the west time zone will have a long weekend this week.
Thanks,
Anton
From: Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Wednesday, April 6, 2022 12:43 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - April 14
Hi,
The next Technical Forum is planned on Thursday, April 14, 15:00-16:00 UTC (West time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hello!
My name is Oleg.
I'm working on TF-M Isolation Level 3 testing and I need to develop test cases list for it.
Could you be so kind to provide me the test cases list? May be you know where I can find it by myself?
Also I have test cases list for Isolation Leve 2. Am I right that it can be reused for Isolation Level 3 with some changes?
I will be very appreciate for any help.
Thank you so much,
Oleg Dokanov
Hi,
The next Technical Forum is planned on Thursday, April 14, 15:00-16:00 UTC (West time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi all,
Please be advised that the Mbed TLS GitHub migration is complete. The new home for Mbed TLS is:
https://github.com/Mbed-TLS
We recommend updating your project, checkouts, etc to point at the new repository, but it's not urgent as everything will continue to work for some time via automatic redirection.
Also please note that our project boards, which we use for planning upcoming work via epics, and tracking current activity, have moved. They are now available here:
Epics board: https://github.com/orgs/Mbed-TLS/projects/1
Current activity: https://github.com/orgs/Mbed-TLS/projects/2
Thanks
Dave Rodgman
On 22/03/2022, 14:52, "Dave Rodgman via Mbed-tls-announce" <mbed-tls-announce(a)lists.trustedfirmware.org> wrote:
Hi all,
Please note that in the next couple of weeks, we will migrate Mbed TLS to a new GitHub organisation. Your existing scripts, links etc for accessing Mbed TLS on GitHub should not be affected.
This will change the url from https://github.com/ARMmbed/mbedtls to https://github.com/Mbed-TLS/mbedtls . GitHub will redirect any accesses to the old URL for the foreseeable future, but we would recommend updating your links once the migration is complete.
All of the Mbed TLS repositories will migrate to this new organisation, i.e.:
mbedtls
mbedtls-docs
mbedtls-test
Thanks
Dave Rodgman
--
Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org
To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org
Hi,
The next Technical Forum is planned on Thursday, March 31, 7:00-8:00 UTC (East time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hello,
Quite some time ago there was a proposal to move TF-M into GitHub. The main motivation is: more convenient review process, the Wiki for knowledge sharing and issue tracking facility.
This idea had been discussed multiple times in TSC. The following options were considered:
1. Hybrid: Add TF-M on GitHub with 2 ways synchronization between GitHub and existing Git/Gerrit
2. GitHub only: Move to GitHub completely and drop Gerrit.
3. Mirror: Create a read-only mirror on GitHub. TF-M review process stays in Gerrit but Wiki and issue tracking are on GitHub.
4. Nothing: Stay on Gerrit as good enough solution.
The options are ordered by complexity and cost each has pros and cons. The Mirror option (3) seeing as the best compromise and practically affordable in a short time.
Please share your opinion and comments on the topic with any dependencies or specific requirements to be considered.
Thanks,
Anton
Hi All,
Please find the link to the TrustedFirmware Community Code of Conduct here:
https://developer.trustedfirmware.org/w/collaboration/community_guidelines/…
Trusted Firmware has a very diverse and global developer community. It is
important that we adhere to the code of conduct in all our interactions.
For some of you all this may be new and for others just a gentle reminder.
In either case, if you have any questions, please feel free to reach out to
me directly.
And thanks to you all for your contributions to the TrustedFirmware
community!
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi.
I've been working on making an example on how an application can use the secure interrupts in a secure partition in TF-M.
During this I've encountered an issue where the secure partition will not be scheduled to process the secure interrupt signal in certain conditions.
I've compared it to the current SLIH and FLIH test cases to my observed behaviour and I could see that they did not have this problem.
I've created a test-case that triggers the problem [0].
In the mailing list I can see that this was actually discussed recently [1]
The summary is that secure partitions will not be scheduled to process a secure interrupt signal when the interrupt is interrupting the NSPE.
I could not find that this was documented anyway, but maybe I have overlooked.
In any case I find this behaviour very unexpected and I would like to know if this is indeed a design decision and the behaviour has to be this way?
If I wanted to do some processing in the secure partition context it would now mean that I have to get the NSPE to trigger this through a secure partition call.
This seems like a limitation to me .
I'd like to know what would be the issue with scheduling the partition once it now has the signal asserted.
I've done a quick test with scheduling the partition at this point with [2] and this now works as I expect it to.
I'd be happy to follow up with submitting a change to schedule the partition as done in [2] if that is an acceptable solution.
[0] https://github.com/joerchan/tf-m-tests/commit/d9f0a3a7653b594d0fa797d9e0bca…
[1] https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.…
[2] https://github.com/joerchan/sdk-trusted-firmware-m/commit/e5512c6e8b2bad95c…
Hi,
Just a reminder that the MCUboot version has been upgraded to v1.9.0<https://github.com/mcu-tools/mcuboot/releases/tag/v1.9.0> in TF-M. If you are using the local MCUboot repo, then you need to update it to that version to avoid build error.
Regards,
Sherry Zhang
