Hi All,
In preparation to the Firmware-A v2.12 bundle release the following TF-A/TF-A-tests/Hafnium/RMM/CI project tags were applied:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a/+/refs/tags/v2.12-r…https://git.trustedfirmware.org/tf-a-tests/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/ci/tf-a-ci-scripts/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/ci/tf-a-job-configs/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/hafnium/hafnium.git/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/ci/hafnium-ci-scripts.git/+/refs/tags/v2.12…https://git.trustedfirmware.org/ci/hafnium-job-configs.git/+/refs/tags/v2.1…https://git.trustedfirmware.org/TF-RMM/tf-rmm/+/refs/tags/tf-rmm-v0.6.0-rc0
Trees are frozen still accepting security or bug fixes until the release close down happening end next week (hopefully!).
For partners, it will help if tests are run against those trees on downstream platforms and spot any issue hit before the final tagging.
--
Thanks,
Govindraj R
________________________________
From: Govindraj Raja via TF-A-Tests <tf-a-tests(a)lists.trustedfirmware.org>
Sent: Monday, October 14, 2024 20:18
To: Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org>; tf-a-tests(a)lists.trustedfirmware.org <tf-a-tests(a)lists.trustedfirmware.org>
Cc: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; tf-rmm(a)lists.trustedfirmware.org <tf-rmm(a)lists.trustedfirmware.org>; trusted-services(a)lists.trustedfirmware.org <trusted-services(a)lists.trustedfirmware.org>
Subject: [Tf-a-tests] Firmware-A v2.12 release code freeze notification
Hi All,
The next release of the Firmware-A bundle of projects tagged v2.12 has an expected code freeze date of Nov, 8th 2024.
Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…).
Closing out the release takes around 6-10 working days after the code freeze.
v2.12 release preparation tasks start from now.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
--
Thanks,
Govindraj R
--
TF-A-Tests mailing list -- tf-a-tests(a)lists.trustedfirmware.org
To unsubscribe send an email to tf-a-tests-leave(a)lists.trustedfirmware.org
+ other MLs
________________________________
From: Olivier Deprez
Sent: 30 October 2024 11:41
To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: TF-A Tech Forum regular call
Dear TF-A ML members,
As mentioned in https://www.trustedfirmware.org/meetings/tf-a-technical-forum/, trustedfirmware.org hosts regular technical calls on Thursdays. It mentions TF-A although in practise a number of Cortex-A projects beyond TF-A were discussed (refer to prior recordings on this page).
Unfortunately this slot hasn't been very active recently.
By this email I'm kindly emphasizing this forum is open to the community (and beyond trustedfirmware.org members) and you are welcome to propose topics. Presentations/slides are not strictly necessary, and we can also host informal discussions or session of questions. If you think of a topic, please reach to me and I'll be happy to accommodate.
Thanks for your contributions in advance!
Regards,
Olivier.
Hi All,
This is a follow-up email to the OP-TEE 4.4.0 release, highlighting the updates to the SPMC and related components.
Short summary of the introduced changes:
- Branch Target Identification (BTI) and Pointer Authentication (PAC) support added for S-EL0 Secure Partitions
- FF-A VM availability message forwarding support added to S-EL0 Secure Partitions
- Improved FF-A compliance
For more details on how to get, build and test the SPMC, please see [1].
Regards,
Imre
[1]: https://github.com/Trusted-Services/trusted-services/wiki/OP-TEE-SPMC-v4.4-…
Hi All,
The next release of the Firmware-A bundle of projects tagged v2.12 has an expected code freeze date of Nov, 8th 2024.
Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…).
Closing out the release takes around 6-10 working days after the code freeze.
v2.12 release preparation tasks start from now.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
--
Thanks,
Govindraj R
Hey, I have some issues understanding a few things related to
https://www.trustedfirmware.org/, specifically:
-
https://trustedfirmware-a.readthedocs.io/en/latest/components/firmware-upda…
PSA Firmware Update (PSA FWU)
-
https://trusted-services.readthedocs.io/en/latest/services/fwu/index.html
Firmware Update Service
I’ve asked on other mailing lists, but unfortunately, no one responded.
I’m writing this in the context of ARMv8 architecture machines, where
(roughly) we have the following stack running:
- payload understandable by the vendor's bootROM
- TF-A BL2
- TF-A BL31 as EL3 runtime services
- OP-TEE as BL32
- u-boot as BL33
- Linux
I will refer to BL31 and BL32 as firmware.
In the PSA Firmware Update specification, the entire procedure is
described, outlining how it should work, e.g., the update process is
initiated by the Update Client running in REE (e.g., some process on
Linux), and it describes how metadata should be handled, rollback, etc.
Assuming that my storage is eMMC, where all these things are stored,
divided into partitions (let's skip offsets and other details):
- bootROM payload
- bl2
- fip-a (required by bl2 with PSAFWUSUPPORT)
- fip-b (required by bl2 with PSAFWUSUPPORT)
- metadata-a (required by bl2 with PSAFWUSUPPORT)
- metadata-b (required by bl2 with PSAFWUSUPPORT)
- boot (e.g., with fitimage)
- rootfs-a
- rootfs-b
- data
As I was reviewing the specification, it seemed that the firmware update
should be conducted in the secure world, which (in my opinion) would mean
that, for example, fip-x and metadata-x are updated somehow from the secure
world, let’s say by a TA running in OP-TEE. However:
- OP-TEE doesn't have drivers for eMMC (simply put - for example, to
store data securely, OP-TEE communicates with Linux to write data to eMMC).
- When I started googling and asking around (e.g., on Reddit), people
told me that it's not the case at all, and typically some process runs on
Linux, like RAUC or SWUPDATE, and it just writes whatever is needed to
fip-x and metadata-x - so the whole update takes place in the so-called REE.
And now my question is - I assume that this specification and trusted
services (particularly the FWU service) that I linked were designed for a
reason - so my question is, what is the use case? Could this be more
applicable to "small MCUs" rather than microprocessors (even though the
specification I linked concerns Cortex-A)? Or is this used on servers?
Perhaps the nature of embedded systems is such that we don't use it and
just take RAUC or some other SWUPDATE and write what is needed, and the
fact that the system is trustworthy is ensured by the chain-of-trust?
Best regard
Patryk
Hi All,
The next release of the Firmware-A bundle of projects tagged v2.11 has an expected code freeze date of May, 10th 2024.
Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…).
Closing out the release takes around 6-10 working days after the code freeze.
v2.11 release preparation tasks start from now.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
Thanks & Regards,
Olivier.
Hi all,
[ TS newbie alert ]
My goal is to build a new trusted service that provides a
stripped-down DPE (DICE protection engine) interface.
My initial target is a Linux PC deployment. (In a subsequent
iteration, I plan to get it run on OP-TEE.)
I have gone through all the project documentation and also a
presentation that Julian made at a previous Linaro Connect.
I think I have a quite clear understanding of the overall architecture
and how blocks have been organised.
One thing I couldn't find, which would help greatly with coding, is a
"how to build your trusted service from scratch".
Is there any such document - even if in embryonic form - somewhere?
If not, any suggestions for moving my first steps through the TS
codebase would be much appreciated :-)
Thanks in advance, cheers!
