Hi Anton,
I'd like to give a presentation about the proposal of External Trusted
Secure Storage,
and the presentation will take about 30 minutes, thanks.
Best Regards,
Poppy Wu
吴偏偏
Macronix Microelectronics (Suzhou) Co.,Ltd
旺宏微电子（苏州）有限公司
http://www.mxic.com.cn
Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org>
2022/06/15 20:31
Please respond to
Anton Komlev <Anton.Komlev(a)arm.com>
To
"tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
cc
nd <nd(a)arm.com>
Subject
[TF-M] Technical Forum call - June 23
Hello,
The next Technical Forum is planned on Thursday, June 23, 7:00-8:00 UTC
(East time zone).
Please reply on this email with your proposals for agenda topics.
Link to the forum:
https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT…
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
--
TF-M mailing list -- tf-m(a)lists.trustedfirmware.org
To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org
============================================================================
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.
=====================================================================
Hi,
TF-M is going to migrate to Mbed TLS PSA configuration scheme which is recommended by Mbed TLS. With this new feature, TF-M is able to:
* more conveniently to align and check TF-M Crypto feature setting against Mbed TLS configuration.
* enable the HW crypto accelerator to use PSA drivers and get rid of Mbed TLS software implementation. Therefore, it can decrease the Crypto SW code size for HW accelerator.
After migrating to Mbed TLS PSA configuration scheme, TF-M ROM size will save about 6.5kB.
The general mbedtls-psa-configuration<https://review.trustedfirmware.org/q/topic:%22mbedtls-psa-configuration%22+…> patches are going to be merged soon. While the HW crypto patch is still under platform owner review until this Friday.
It is welcome that if you have any comments and suggestions : )
Best Regards,
Summer
Hi all,
I'm refining TF-M contribution processes. Hope it can better support you to contribute to TF-M community.
Currently I focus on the following two repos:
* Tf-m-extras: specify the tf-m-extras additional requirements. Enable contributor to specify the maintainers. Patch link<https://review.trustedfirmware.org/c/TF-M/tf-m-extras/+/15430>.
* Trusted firmware-m: simplify the contribution process a bit to align with current development practices. Make it as a general process reference for other TF-M repos. Patch link<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15472>.
Can I ask your to take a look at those changes to the processes? Please let us know if any step can be optimized/clarified further.
Any feedback is welcome.
Best regards,
Hu Ziji
Hello,
TF-M documentation reflects the documents in the main TF-M repository (https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs) only.
There are 5 other repos (tests, tools, extras, CI) with corresponded docs being good to be linked to the main. Looking for ideas / advice on the best way to do that.
The main problem is that Sphinx (the documentation tool) renders files under its configuration directory only, ignoring everything outside of it so reference to external repos is not an easy task. I see several solutions:
1. The main doc points to external files (*.rst) as an external link without rendering it. Like this<https://git.trustedfirmware.org/TF-M/tf-m-tools.git/tree/depend-trace-tool/…>. <-- Simplest way.
2. Create Sphinx doc for each repository, store rendered output in a temporal storage and link the main to generated HTML files.
3. Use intersphinx<https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html> to link across repositories. Again, need rendered docs in each repo and additional preparation.
4. Anything else?
Any thoughts or experience to share?
Thanks in advance,
Anton
Looking at the declaration and body of this function, the first parameter is clearly a partition index (index into g_spm_partition_db.partitions[]), and all the call sites in secure_fw/spm/cmsis_func/spm_func.c use it that way. The three call sites in secure_fw/spm/cmsis_func/main.c, though, all pass a PID instead. This happens to work because g_spm_partition_db.partitions[0].static_data->partition_id == 0 and g_spm_partition_db.partitions[1].static_data->partition_id == 1. I don't see anything that guarantees that that will always be true, though.
There is a static function get_partition_id() in secure_fw/spm/cmsis_func/spm_func.c that maps from PID to partition index - should that be exported and called to address this?
Thanks,
Chris Brand
.
Hi,
Reading https://tf-m-user-guide.trustedfirmware.org/technical_references/design_doc… it mentions the plan to move ns_agent_mailbox to have "a positive valued Partition ID in the manifest" and it also states that "A standard Secure Partition gets errors when calling the Extended API".
Given that it will not possible to use the PID to identify the ns_agent_mailbox, how will the Extended API functions know whether the caller is a standard Secure Partition or not?
There was a patch https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15142 that introduced a flag to identify the ns_agent_tz partition - would this be similar?
Also, is there a plan for which release this functionality is expected to appear?
Thanks,
Chris Brand
