Hi,
We encourage anyone working for an organization deploying Hafnium project and are potentially impacted by security vulnerabilities to go through the Trusted Firmware Security incident handling guidelines and register [1] as a Trusted Stakeholder.
We prefer individuals in each organization to coordinate their registration requests with each other and to provide us with an email alias managed by your organization instead of us managing a long list of individual addresses. We will start sending notifications to Trusted Stakeholders from the start of next week/month.
[1] https://general.docs.trustedfirmware.org/en/latest/security_center/incident…
Thanks,
Madhukar on behalf of Hafnium maintainers
Hi Hafnium Team,
I hope this email finds you well.
I am currently working with TF-A and Hafnium, and I have a quick
question regarding the versioning and tagging practices between the two
projects.
Could you clarify if Hafnium release tags (e.g., v2.14, v2.15) are
always strictly synchronized with TF-A release tags in terms of
compatibility and FF-A feature support?
Additionally, when picking a stable combination for production or
feature integration (especially around SPMD/SPMC interaction), is it
recommended to always pair identical release tags between TF-A and
Hafnium, or are there specific compatibility matrices we should refer
to?
Thank you for your time and guidance.
Best regards,
Mankyum Kim
[cid:cafe_image_0@s-core.co.kr]
[update?userid=mankyum.kim&do=bWFpbElEPTIwMjYwNzIwMDgwMjQxZXBjbXMycDU3Z
Dk0MzdkYTE1ZDdkZGQ0ZDVhMmYwNzZkNjU1YWZhOSZyZWNpcGllbnRBZGRyZXNzPWhhZm5p
dW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__]
Hi everyone,
I am sending this email to all tf.org project mailing lists to ensure all maintainers are aware and on board regarding this matter. If you have any concerns or questions, please reply on tf.org Discord #general channel, where I'll create a thread, as I think it will be much easier than dealing with cross-mailing lists emails.
Background
When a security vulnerability is discovered in one of the trustedfirmware.org projects, it is common to request a "Common Vulnerabilities and Exposures" (CVE) number. This number uniquely references the issue, which can then be searched in the vulnerability databases. One of these databases is NIST's "National Vulnerability Database" (NVD): https://nvd.nist.gov<https://nvd.nist.gov/vuln/detail/CVE-2023-51712>
Entering a specific CVE number in NVD search engine will allow you to easily find the details of a specific issue, for example:
https://nvd.nist.gov/vuln/detail/CVE-2023-51712
However, sometimes one is not looking for a specific CVE number but rather wants to list all known vulnerabilities affecting a particular project. For this, one can use the Common Platform Enumerations (CPE) search engine:
https://nvd.nist.gov/products/cpe/search
CPE is a structured naming scheme that includes information like the vendor name, the project name, the version / tag, and so on.
See https://nvd.nist.gov/products/cpe for more details.
So for example, https://nvd.nist.gov/vuln/detail/CVE-2023-51712 referenced above has the following CPE:
cpe:2.3:o:arm:trusted_firmware-m:*:*:*:*:*:*:*:*
This basically means
*
CPE version 2.3 is in use
*
'o is the type of project, in this case it stands for Operating Systems (which is probably the closest match for low-level code like TF-M)
*
'arm' is the vendor (that is wrong, see below)
*
'trusted_firmware-m' is the project name,
Problem statement
It appears that CPEs used in NVD to reference vulnerabilities in tf.org projects differ a lot across projects. For some projects, there's even multiple of them. Sometimes the vendor is "arm", sometimes it's "linaro", or something else.
Some of the TF-A and MbedTLS maintainers have initiated discussions with NVD to get this simplified and unified, but it would make sense to align other tf.org projects as well.
Proposal
CPE naming rules are that the vendor name should the parent organization of the project. Thus the proposal would be for all tf.org projects to use "trustedfirmware" as the vendor name in their CPE.
For example:
cpe:2.3:o:trustedfirmware:trusted_firmware-m:*:*:*:*:*:*:*:*
cpe:2.3:a:trustedfirmware:mbed_tls:*:*:*:*:*:*:*:*
We're only proposing to change the vendor name here ; each project is then free to choose how they want the project name or the type of software project they want to encode there.
Thanks for reading,
Best regards,
Sandrine Afsa
Hi all,
We will be upgrading Cloudbees CI and clusters hosting review.trustedfirmware.org and ci.trustedfirmware.org on Wednesday, 3rd June 2025 at 16:00 GMT+1.
During this maintenance window, both services will be unavailable for approximately 8 hours.
A follow-up email will be sent once the services are fully restored.
Best regards,
Saheer
[LOGO SMALL]
Saheer Babu
Principal Software Engineer
CESW – Engineering Infrastructure
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
Hello,
I am a TF-A firmware developer currently working on the Arm Neoverse RD-V3-R1 reference design, and I am in the process of porting and validating Hafnium (SPMC, TF-A BL32) on this platform.
On RD-V3-R1, we are using secure_rdv3r1_clang as the Hafnium target platform configuration.
However, I noticed that secure_rdv3r1_clang does not appear in the list of supported Hafnium platforms (or reference build targets) in the upstream repository.
Could you please clarify the following?
Is secure_rdv3r1_clang an officially supported target configuration for Hafnium?
If not, is there a plan to support it upstream in the future, or is there an alternative recommended target for RD-V3-R1 secure builds?
If there is an official/recommended build configuration for RD-V3-R1 in the upstream Hafnium project, I would appreciate any guidance.
Thank you very much for your time and support.
Best regards,
Seongju Yoo
