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
Hi,
The next Technical Forum is planned on Thursday, March 17, 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
