Hi Anton,
I'd like to share about the current design and draft implementation of TF-M Profile 1.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Tuesday, February 25, 2020 1:11 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M Technical Forum call - March 5
Dear All,
The next Technical Forum is planned on Thursday, March 5 at 7:00-8:00 UTC.
Please reply on this email with your proposals for agenda topics.
Best regards,
Anton Komlev
A kind reminder.
Your feedback is valuable all the time with no deadline defined.
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: 07 February 2020 13:13
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Call for a feedback on TF-M adaptation experience
Dear All,
As I mentioned on yesterday's call, there is a concern on user experience related to TF-M use.
To In order to understand and potentially improve it I am looking for a voice of partners who adopted TF-M project.
Please share your experience and thoughts on parts which are good or might be done better to simplify TF-M integration with your project.
You feedback will be very appreciated in any form - as a response to this mail or as a direct mail to me (anton.komlev(a)arm.com<mailto:anton.komlev@arm.com>) if it's more comfortable for you.
Thank you in advance,
Anton
Hi Everyone
The below mentioned patches have been merged to TF-M master. The Open CI is also updated to pull in the right version of mbed-crypto (3.0.1) and it should now show results as expected. You may to have rebase your existing patches currently in review if you need to run CI tests.
Best Regards
Soby Mathew
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby
> Mathew via TF-M
> Sent: 18 February 2020 11:38
> To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
> Cc: nd <nd(a)arm.com>
> Subject: [TF-M] Update Crypto, SST and Attestation services to the latest
> versions
>
> Hi Everyone,
> This is a heads up that there are patches in review which update the Crypto,
> SST and Attestation services to latest versions of their respective specifications :
>
> 1. Crypto-service migration to Mbed Crypto 3.0.1
>
> The patches is available here :
> https://review.trustedfirmware.org/q/topic:%22crypto_update%22+(status:ope
> n%20OR%20status:merged)
>
> This migrates the crypto service to the latest implementation of PSA
> specification as implemented by mbed-crypto.
>
> 2. SST: Implement PSA Protected Storage 1.0
>
> https://review.trustedfirmware.org/q/topic:%22sst-1.0-
> update%22+(status:open%20OR%20status:merged)
>
> 3. Initial Attestation: Align interface to PSA API 1.0
>
> https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?h=feature-
> psa-dev-api-update&id=b8d88ce6fb7c8e7301f32ab7f6b36dd796692f98
>
> and
>
> https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?h=feature-
> psa-dev-api-update&id=12c02d16958c9dbd57a6bebe6f29b7a207355831
>
> These patches are expected to be reviewed and merged back to the master in
> the next couple of weeks.
>
> Best Regards
> Soby Mathew
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Dear All,
The next Technical Forum is planned on Thursday, March 5 at 7:00-8:00 UTC.
Please reply on this email with your proposals for agenda topics.
Best regards,
Anton Komlev
Hi all,
As Anton already announced during last TF-M Tech Forums, we have recently started a deep review initiative for the TF-M project, with main focus to improve User Experience and reduce Onboarding Effort. The team is currently focusing on the following topics:
* Repository and Housekeeping
* Development Environment
* Build System
* Source tree structure and Abstraction Layers
* Coding Rules
* Documentation
* Continuous Integration
* Testing
We are fully aware of the vast area the topics above cover but, focusing on the basic principles mentioned above, we intend to conclude to implementable solutions.
It is therefore of significant importance that your individual or team's onboarding experience is shared with us and this mailing list. Please share any feedback based on your experience using and/or enhancing TF-M.
Regards,
Kostas
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi TF-Mers!
Sincere apologies for the short notice, but at the next TF-M Tech Forum (in a few hours from now!), I will do a short presentation on a TF-M Fuzzing Tool that I’ve been working on for 2-3 months.
Currently, it’s just a prototype, and I’ve only tested SST functionality so far, but we’re hoping we can get it out into the open-source arena soon, and get a little more brain power into improving its capabilities.
(Apologies also that it’ll be at 1AM my time, out here in Austin, so please bear with me if I sound a little groggy! 😊)
Hope you can join us!
-- Gary Morrison
gary.morrison(a)arm.com
Principal SW Engineer
Arm, Inc.
Austin, TX. USA
Hello all,
I will be presenting about the use of "SFN" section for handling object placement in the Secure Side and how this may hide dragons.
Regards,
Minos Galanakis
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 11 February 2020 12:04
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M Technical Forum call - February 20
Dear All,
The next Open Technical Forum is planned on Thursday, February 20 at 7:00-8:00 UTC.
Please reply on this email with your proposals for agenda topics.
Best regards,
Anton Komlev
Hi all,
Thanks a lot for the reviews and support for dual-cpu multiple NS PSA client calls feature in TF-M. The patches were merged.
Another patch set, which adds test cases for dual-cpu multiple NS PSA client calls, have also been reviewed several rounds in last 2 months, together with feature patches.
I’d like to merge the test case patches *by this Thursday* if no further comment.
Please help review https://review.trustedfirmware.org/q/topic:%22dualcpu-test-framework%22+(st… if you have interest.
Any suggestion or comment is welcome.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: Wednesday, February 12, 2020 9:47 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Dual-cpu multiple NS PSA client calls feature
Hi all,
I’d like to submit the patches to enable multiple NS PSA client calls feature on dual-cpu system *by this week*, if no more comments.
The patches have been reviewed for several rounds in last two months. Thanks a lot for all your reviews, comments and validation.
The patch set can support NS side to start multiple outstanding PSA client calls concurrently, on dual-cpu system. The feature is enabled and verified on Cypress PSoC 64 platform.
If you are interested, please take a look at https://review.trustedfirmware.org/q/topic:%22dualcpu-multi-client-call%22+….
The overall design is discussed in design documents https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/design_doc… and https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/design_doc…
Comments and suggestions are still and always welcome. 😊
Thank you.
Best regards,
Hu Ziji
Hi,
There is something out of fashion in the first version SPRTL document, and the content is not well-formatted in a not ideal place. I updated parts of the document:
- Re-format the document.
- Fixes the descriptions for C runtime API, now we are re-using the headers, types and parts of toolchain library if possible.
- Important change: Define a new 'SP Scratch' area and needs SPM cooperation to let the SPRTL can retrieve SP specific metadata.
The new SP scratch area is used for resolving the context-based runtime API cannot retrieve the SP metadata problem since SPRTL is just a code. With this change, the SPRTL has a way to retrieve the SP metadata and then context-based runtime API is much easier in implementation.
The patch is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3457
And the issue: https://developer.trustedfirmware.org/T484
Thanks.
/Ken
