This event has been updated with a note:
"Session for 27th July 2023."
Changed: description
TF-A Tech Forum
Thursday Jul 27, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Topic:MISRA testing in the OpenCI with BUGSENG's ECLAIR Software
Verification PlatformPresenters:Roberto Bagnara (BUGSENG) and Paul
Sokolovskyy (Linaro)Summary:Overview of MISRA C, BUGSENG's ECLAIR Software
Verification Platformand the challenges and solutions for its deployment in
the OpenCIContinuous Integration System for the TF-A and TF-M
TrustedFirmwareOpensource community projects.We run an open technical forum
call for anyone to participate and it is not restricted to Trusted Firmware
project members. It will operate under the guidance of the TF TSC. Feel
free to forward this invite to colleagues. Invites are via the TF-A mailing
list and also published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
lavinia.battaglia(a)bugseng.com
paul.sokolovsky(a)linaro.org
roberto.bagnara(a)bugseng.com
valentina.loggini(a)bugseng.com
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
This event has been canceled.
TF-A Tech Forum
Thursday Jun 15, 2023 ⋅ 4pm – 5pm
United Kingdom Time
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi Varun,
* for platforms with SPMD_SPM_AT_SEL2=1. These platforms already use EHF for servicing RAS interrupts today.
Can you please have a look at https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16047 ?
and https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16047/6/docs…
The model, by the FF-A specification, is to permit G0 interrupts to trap to EL3 when NWd runs.
A G0 interrupt is routed to a SP through the SPMD/SPMC by the use of EL3-SP direct messages:
https://review.trustedfirmware.org/q/topic:%22el3_direct_msg%22+(status:ope…
When SEL1/0 runs, G0 interrupts are first trapped to SEL2 and forwarded to EL3 by the FFA_EL3_INTR_HANDLE ABI.
I appreciate the legacy capability to let G0 interrupts trap to EL3 while SWd runs is not possible/recommended with this design.
This might indeed break earlier implementations; would it make sense aligning SW stacks to the latest of the FF-A spec recommendations?
I let Raghu chime in if need be.
Regards,
Olivier.
________________________________
From: Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 06 June 2023 13:12
To: TF-A Mailing List <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] EHF and SPMD G0 interrupt handling issues
Hi,
We are in the process of upgrading the downstream TF-A to v2.9 for platforms with SPMD_SPM_AT_SEL2=1. These platforms already use EHF for servicing RAS interrupts today.
I noticed that v2.9 has added G0 interrupt handling support to the SPMD. But I think the SPMD support still needs some work as it does not play nicely with EHF.
I have found the following issues with the implementation.
1. SPMD and EHF both register handlers for G0 interrupts. But the interrupt management framework only allows one handler for INTR_TYPE_EL3.
2. The RAS framework still uses EHF and the SPMD interrupt handler breaks that functionality.
3. The SPMD handler calls into the platform which does not have any means to invoke the RAS interrupt handler.
IMO, we should make SPMD a client of the EHF instead of creating yet another way for interrupt handling. For now, I register SPMD's G0 interrupt handler only if EL3_EXCEPTION_HANDLING=0, as a workaround.
Thoughts?
Hi,
Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
5 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 5 of 5 defect(s)
** CID 385350: Control flow issues (DEADCODE)
/plat/xilinx/zynqmp/zynqmp_sdei.c: 19 in arm_validate_ns_entrypoint()
________________________________________________________________________________________________________
*** CID 385350: Control flow issues (DEADCODE)
/plat/xilinx/zynqmp/zynqmp_sdei.c: 19 in arm_validate_ns_entrypoint()
13
14 #include <plat/common/platform.h>
15 #include <platform_def.h>
16
17 int arm_validate_ns_entrypoint(uintptr_t entrypoint)
18 {
>>> CID 385350: Control flow issues (DEADCODE)
>>> Execution cannot reach the expression "-1" inside this statement: "return (entrypoint >= 42947...".
19 return ((entrypoint >= BL31_BASE) && (entrypoint < BL31_LIMIT)) ? -1 : 0;
20 }
21
22 /* Private event mappings */
23 static sdei_ev_map_t zynqmp_sdei_private[] = {
24 SDEI_DEFINE_EVENT_0(ZYNQMP_SDEI_SGI_PRIVATE),
** CID 385349: (OVERRUN)
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1404 in intel_fcs_ecdsa_hash_sign_finalize()
________________________________________________________________________________________________________
*** CID 385349: (OVERRUN)
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1409 in intel_fcs_ecdsa_hash_sign_finalize()
1403
1404 memcpy((uint8_t *) &payload[i], (uint8_t *) hash_data_addr,
1405 src_size);
1406
1407 i += src_size / MBOX_WORD_BYTE;
1408
>>> CID 385349: (OVERRUN)
>>> Overrunning array "payload" of 17 4-byte elements by passing it to a function which accesses it at element index 134217732 (byte offset 536870931) using argument "i" (which evaluates to 134217733).
1409 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDSA_HASH_SIGN_REQ,
1410 payload, i, CMD_CASUAL, (uint32_t *) dst_addr,
1411 &resp_len);
1412
1413 memset((void *) &fcs_ecdsa_hash_sign_param,
1414 0, sizeof(fcs_crypto_service_data));
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1404 in intel_fcs_ecdsa_hash_sign_finalize()
1398
1399 if ((i + ((src_size) / MBOX_WORD_BYTE)) >
1400 FCS_ECDSA_HASH_SIGN_CMD_MAX_WORD_SIZE) {
1401 return INTEL_SIP_SMC_STATUS_REJECTED;
1402 }
1403
>>> CID 385349: (OVERRUN)
>>> Overrunning buffer pointed to by "(uint8_t *)&payload[i]" of 68 bytes by passing it to a function which accesses it at byte offset 536870931 using argument "src_size" (which evaluates to 536870912). [Note: The source code implementation of the function has been overridden by a builtin model.]
1404 memcpy((uint8_t *) &payload[i], (uint8_t *) hash_data_addr,
1405 src_size);
1406
1407 i += src_size / MBOX_WORD_BYTE;
1408
1409 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDSA_HASH_SIGN_REQ,
** CID 385348: (OVERRUN)
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 2144 in intel_fcs_ecdh_request_finalize()
________________________________________________________________________________________________________
*** CID 385348: (OVERRUN)
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 2144 in intel_fcs_ecdh_request_finalize()
2138
2139 if ((i + ((src_size) / MBOX_WORD_BYTE)) >
2140 FCS_ECDH_REQUEST_CMD_MAX_WORD_SIZE) {
2141 return INTEL_SIP_SMC_STATUS_REJECTED;
2142 }
2143
>>> CID 385348: (OVERRUN)
>>> Overrunning buffer pointed to by "(uint8_t *)&payload[i]" of 116 bytes by passing it to a function which accesses it at byte offset 536870931 using argument "src_size" (which evaluates to 536870912). [Note: The source code implementation of the function has been overridden by a builtin model.]
2144 memcpy((uint8_t *) &payload[i], (uint8_t *) pubkey, src_size);
2145 i += src_size / MBOX_WORD_BYTE;
2146
2147 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDH_REQUEST,
2148 payload, i, CMD_CASUAL, (uint32_t *) dst_addr,
2149 &resp_len);
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 2147 in intel_fcs_ecdh_request_finalize()
2141 return INTEL_SIP_SMC_STATUS_REJECTED;
2142 }
2143
2144 memcpy((uint8_t *) &payload[i], (uint8_t *) pubkey, src_size);
2145 i += src_size / MBOX_WORD_BYTE;
2146
>>> CID 385348: (OVERRUN)
>>> Overrunning array "payload" of 29 4-byte elements by passing it to a function which accesses it at element index 134217732 (byte offset 536870931) using argument "i" (which evaluates to 134217733).
2147 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDH_REQUEST,
2148 payload, i, CMD_CASUAL, (uint32_t *) dst_addr,
2149 &resp_len);
2150
2151 memset((void *)&fcs_ecdh_request_param, 0,
2152 sizeof(fcs_crypto_service_data));
** CID 385347: Control flow issues (NO_EFFECT)
/plat/xilinx/zynqmp/zynqmp_sdei.c: 19 in arm_validate_ns_entrypoint()
________________________________________________________________________________________________________
*** CID 385347: Control flow issues (NO_EFFECT)
/plat/xilinx/zynqmp/zynqmp_sdei.c: 19 in arm_validate_ns_entrypoint()
13
14 #include <plat/common/platform.h>
15 #include <platform_def.h>
16
17 int arm_validate_ns_entrypoint(uintptr_t entrypoint)
18 {
>>> CID 385347: Control flow issues (NO_EFFECT)
>>> This less-than-zero comparison of an unsigned value is never true. "entrypoint < 0UL".
19 return ((entrypoint >= BL31_BASE) && (entrypoint < BL31_LIMIT)) ? -1 : 0;
20 }
21
22 /* Private event mappings */
23 static sdei_ev_map_t zynqmp_sdei_private[] = {
24 SDEI_DEFINE_EVENT_0(ZYNQMP_SDEI_SGI_PRIVATE),
** CID 385346: (OVERRUN)
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1505 in intel_fcs_ecdsa_hash_sig_verify_finalize()
________________________________________________________________________________________________________
*** CID 385346: (OVERRUN)
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1510 in intel_fcs_ecdsa_hash_sig_verify_finalize()
1504
1505 memcpy((uint8_t *) &payload[i],
1506 (uint8_t *) hash_sig_pubkey_addr, src_size);
1507
1508 i += (src_size / MBOX_WORD_BYTE);
1509
>>> CID 385346: (OVERRUN)
>>> Overrunning array "payload" of 52 4-byte elements by passing it to a function which accesses it at element index 134217732 (byte offset 536870931) using argument "i" (which evaluates to 134217733).
1510 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDSA_HASH_SIG_VERIFY,
1511 payload, i, CMD_CASUAL, (uint32_t *) dst_addr,
1512 &resp_len);
1513
1514 memset((void *)&fcs_ecdsa_hash_sig_verify_param,
1515 0, sizeof(fcs_crypto_service_data));
/plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1505 in intel_fcs_ecdsa_hash_sig_verify_finalize()
1499
1500 if ((i + ((src_size) / MBOX_WORD_BYTE)) >
1501 FCS_ECDSA_HASH_SIG_VERIFY_CMD_MAX_WORD_SIZE) {
1502 return INTEL_SIP_SMC_STATUS_REJECTED;
1503 }
1504
>>> CID 385346: (OVERRUN)
>>> Overrunning buffer pointed to by "(uint8_t *)&payload[i]" of 208 bytes by passing it to a function which accesses it at byte offset 536870931 using argument "src_size" (which evaluates to 536870912). [Note: The source code implementation of the function has been overridden by a builtin model.]
1505 memcpy((uint8_t *) &payload[i],
1506 (uint8_t *) hash_sig_pubkey_addr, src_size);
1507
1508 i += (src_size / MBOX_WORD_BYTE);
1509
1510 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDSA_HASH_SIG_VERIFY,
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
Hi,
We are in the process of upgrading the downstream TF-A to v2.9 for platforms with SPMD_SPM_AT_SEL2=1. These platforms already use EHF for servicing RAS interrupts today.
I noticed that v2.9 has added G0 interrupt handling support to the SPMD. But I think the SPMD support still needs some work as it does not play nicely with EHF.
I have found the following issues with the implementation.
1. SPMD and EHF both register handlers for G0 interrupts. But the interrupt management framework only allows one handler for INTR_TYPE_EL3.
2. The RAS framework still uses EHF and the SPMD interrupt handler breaks that functionality.
3. The SPMD handler calls into the platform which does not have any means to invoke the RAS interrupt handler.
IMO, we should make SPMD a client of the EHF instead of creating yet another way for interrupt handling. For now, I register SPMD's G0 interrupt handler only if EL3_EXCEPTION_HANDLING=0, as a workaround.
Thoughts?
I am working on qemu_sbsa platform. We are now adding a way to share
data from QEMU via TF-A to EDK2. Standard Arm way - using Secure Monitor
Calls.
I checked how other platforms do it and wrote a patch [1]. It got
reviews, went through CI and all is fine except one thing:
New source files have been identified in your patch..
plat/qemu/qemu_sbsa/sbsa_sip_svc.c
1. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/20871
I have read TF-A documentation linked to CI report. This new file is
covered already by PLAT=qemu_sbsa build because it is not optional. How
to make CI pass?
Same problem is with second patch [2] where I added another new source file.
2. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/20953
This event has been updated with a note:
"Update for Techforum tomorrow...."
Changed: description
TF-A Tech Forum
Thursday Jun 1, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Topic: SVE Enablement in RMM for Realms. Presenter: Arunachalam
GanapathyOverview: This discussion will cover the design and implementation
details on how SVE and FP/AdvSIMD state of Non secure world and Realms are
managed by RMM.=====================We run an open technical forum call for
anyone to participate and it is not restricted to Trusted Firmware project
members. It will operate under the guidance of the TF TSC. Feel free to
forward this invite to colleagues. Invites are via the TF-A mailing list
and also published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
tf-rmm(a)lists.trustedfirmware.org
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi All,
We are pleased to announce the formal release of Trusted Firmware-A version 2.9 bundle of project deliverables.
This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium and TF-A OpenCI Scripts/Jobs 2.9 releases involving the tagging of multiple repositories. Aligned but not yet part of the release is Trusted Firmware-A Realm Management Monitor v0.3.0.
These went live on 23rd May 2023.
I would like to thank all of the contributors for their excellent work and achievements since the last release.
Thanks Joanna
Notable Features of the Version 2.9 Release are as follows:
TF-A/EL3 Root World
* New Features:
* Support for PSCI OS initiated mode
* Architecture feature support for FEAT_TCR2, FEAT_GCS, FEAT_HCX, FEAT_SME2, FEAT_PIE/POR, FEAT_MPAM.
* System registers access trap handler
* Introduction to dynamic detection of features
* Refactoring:
* Context management
* RAS extension exception handling and crash reporting.
* Distinguish between BL2 as TF-A entry point or BL2 running at EL3 exception level.
* General Support
* CPU Support for Chaberton and Blackhawk for TC2023
* Eighteen (18) Errata Mitigations for Cortex X2/X3/A710/A510/A78/A78C and Neoverse N2/V1 family CPU’S
* Errata Management Firmware Interface implementation supported for version 1.0 of the public specification
TF-A Boot BL1/BL2
* New Feature/Support
* Support for Trusted Boot rooted into RSS RoT on TC2022 platform.
* Support for PSA attestation scheme with Measured Boot rooted into RSS on TC2022 platform
* Migration to mbedTLS 3.x as the default cryptography library retaining backwards compatibility with mbedTLS 2.x
* Improvements and hardening of Arm CCA boot and attestation support.
* Hardening efforts in the X.509 certificate parser, including a security fix (TFV-10 CVE-2022-47630)
Hafnium/SEL2 SPM
* FF-A v1.2 ALP0 Specification Early Adoption Support
* Implemented ppartition info get ABI using GP registers.
* Group0 secure interrupt handling delegation.
* Improved console log ABI.
* FF-A v1.1 REL0 Specification Support
* Interrupt handling (S-EL0 partition signalling, added action to Other-S-Int, allow a physical interrupt to be routed to a specified PE).
* Memory sharing (structures updates supporting FF-A backwards compatibility, share/lend/donate memory to multiple borrowers, normal/secure fragmented memory sharing).
* Power management (events relayed to the SPMC and removed limitations).
* Indirect messaging (buffer synchronization and ownership transfer rules).
* General Support
* SPMC manifest to declare non-secure and secure system memory address ranges.
* Hardened SP manifest memory regions boot time validation.
* CI migration to LLVM/clang 15.0.6
* Removal of non-VHE build and test configurations.
* Added EL3 SPMC test configurations using the Hafnium's CI infrastructure.
TF-A Tests
* New Test Support
* Errata Management Firmware Interface testing
* FF-A v1.1 feature testing
* Realm Management Extension feature testing
* New Architecture Specific feature testing related to v8.8
* 1 new platform port (RD-N2-Cfg3)
TF-RMM/REL2
* New Feature/Support
* Added support to create Realms which can make use of SVE, if present in hardware.
* Refactor and improved the Stage 1 translation table library lib/xlat API to better fit RMM usage.
* Add PMU support for Realms as described by RMM v1.0 Beta0 specification.
* Support getting DRAM info from the Boot manifest dynamically at runtime.
* RMM can now support the 2nd DDR bank on FVP
* Define a unit test framework using CppUTest for RMM.
* Added unit tests for granule, slot-buffer and Stage 1 translation table lib xlat.
* Improvements to fake-host and unit tests framework.
* Build improvements in RMM
Platform Support
* 1 new platform added, the Allwinner T507 SoC
* 26 platforms updated from 14 providers
* 17 different driver updates
OpenCI
* First release done solely relying on Trustedfirmware.org OpenCI
Patch Statistics Across all Repositories
* 1403 Patches merged since v2.8 November 2022 release
Please refer to the TF-A [1], Hafnium [2] and TF-A Tests [3] changelogs for the complete summary of changes from the previous release.
TF-A [4], TF-A Test [5], Hafnium [6], TF-A OpenCI Scripts [7] and TF-A OpenCI Jobs [8] repositories are available along with the compatible TF-RMM repository [9] and changelog [10].
[1] https://trustedfirmware-a.readthedocs.io/en/v2.9/change-log.html#id1
[2] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d…
[3] https://trustedfirmware-a-tests.readthedocs.io/en/v2.9/change-log.html#vers…
[4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.9
[5] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.9
[6] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.9
[7] https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.9
[8] https://git.trustedfirmware.org/ci/tf-a-job-configs.git/tag/?h=v2.9
[9] https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tag/?h=tf-rmm-v0.3.0
[10] https://tf-rmm.readthedocs.io/en/tf-rmm-v0.3.0/about/change-log.html#v0-3-0
Hi,
I am pleased to announce that Yann Gautier has now become one of the
maintainers for TF-A. This decision is based on Yann's continued efforts
and involvement in the project over the years.
A patch is under review to reflect this in TF-A documentation:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21060
Best regards,
Sandrine (on behalf of all TF-A maintainers)