- Hafnium - lists.trustedfirmware.org

by Jack Suann

Hi everyone, As you may be aware, at Qualcomm we've been looking into various enhancements we'd like to make to Hafnium; one recent area we've identified for improvement is the fatal error handling which currently just spins on panic / abort. To start with, we're looking at making abort() stop other CPUs and DMA, as well as introduce a platform hook to allow for platform-specific handling before propagating the error to the SPMD via FFA_ABORT; please let us know if this sound reasonable and if you have any other suggestions for improving this abort handling. Beyond this we are also interested in improving the fatal error handling in the secure world more broadly. In particular, when a fatal event is received by TF-A then we want to give the SPMC and its SPs the opportunity to run so they can perform their own error handling before reset. Is there a suitable framework for supporting this kind of error / reset handling? One existing mechanism for this is SDEI, though on the TF Discord it was mentioned that this has been deprecated (at least for hardware events) in favor of more recent extensions such as FEAT_NMI; would these newer extensions be suitable for software events as well? How can event handling be supported on platforms that lack these newer extensions? Also, what would be the impact of this kind of event handling on the FF-A specification? Thanks in advance for your support on this issue. Regards, Jack Suann

1 week, 6 days

4
4
0 0

Hafnium Trusted Stakeholder registration

by Madhukar Pappireddy

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

2 months, 2 weeks

1
0
0 0

Inquiry regarding TF-A and Hafnium version tagging alignment

by 김만겸

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__]

2 months, 2 weeks

2
1
1 0

Hafnium LTS v2.14.1 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Hafnium LTS version 2.14.1 is now available. This release contains the following patches: c72f566e ci(commitlint): enforce scopes for commits [1] d44a004f ci(commitlint): restrict commit scopes to approved list [2] 883f21d8 docs(process): move coding and commit style into process [3] fd72e9de docs(security): add security handling guidance [4] 29d723a5 fix(security): add workaround for CVE-2025-10263 [5] [1] https://review.trustedfirmware.org/q/Ie0c5c94c1b015f2a376530b75e790c23e6641… [2] https://review.trustedfirmware.org/q/Ie776245bd8f3786d8a01256428c86882b040f… [3] https://review.trustedfirmware.org/q/I2c9138ca37f1a452f570becfbb686615308e4… [4] https://review.trustedfirmware.org/q/I164100236750cfbde46ae9898e53e201c7b17… [5] https://review.trustedfirmware.org/q/Ic09ffaf5f16d9e90a2da591acf0899b652962… Thanks, Hafnium LTS team

2 months, 2 weeks

1
0
0 0

Test email #8

by svc_openci_enginfra＠arm.com

This is test email #8 sent from Jenkins

2 months, 3 weeks

1
0
0 0

Hafnium LTS v2.14.1 Release Announcement

by Varun Wadekar

Hello, Hafnium LTS version 2.14.1 is now available. This release contains the following patches: 29d723a5 fix(security): add workaround for CVE-2025-10263 [1] fd72e9de docs(security): add security handling guidance [2] 883f21d8 docs(process): move coding and commit style into process [3] d44a004f ci(commitlint): restrict commit scopes to approved list [4] c72f566e ci(commitlint): enforce scopes for commits [5] [1] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/29d723… [2] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/fd72e9… [3] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/883f21… [4] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/d44a00… [5] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/c72f56… Thanks, Hafnium LTS team

3 months

1
0
0 0

Proposal to unify tf.org vulnerability referencing in NVD

by Sandrine Bailleux

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

3 months, 3 weeks

1
1
0 0

CI infrastructure scheduled maintenance: 4th June Sep 2026

by Saheer Babu

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

4 months

1
2
0 0

Firmware-A v2.12 release code freeze notification

by Govindraj Raja

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

4 months, 1 week

2
4
0 0

Firmware-A v2.15 release code freeze notification

by harrison.mutai＠arm.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

5 months, 1 week

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

Hafnium