Hi All,
It has happened in the past that developers have posted patches for review, but have been unable to respond to the comments on those patches for a long time and hence, maintainers pitched in and abandoned the patches in such cases.
I created a patch [1] to make this official because the coding-review guidelines didn't mention it today. I would appreciate your help in reviewing this patch. Please let us know if you disagree about this approach. If you'd like, we can discuss this upcoming tech-forum.
[1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21848
Thanks,
Manish Badarkhe
This event has been canceled with a note:
"No topic this week. Cancelling. Please, if anybody has topics to present
in other future TF-A Techforums please do reach out to me."
TF-A Tech Forum
Thursday Jun 29, 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
FYI to all TF dev teams leveraging Open CI.
Best regards,
Don
---------- Forwarded message ---------
From: Glen Valante via Tf-openci-triage <
tf-openci-triage(a)lists.trustedfirmware.org>
Date: Fri, 23 Jun 2023 at 08:41
Subject: [Tf-openci-triage] FYI; Cambridge Lab Down
To: tf-openci-triage(a)lists.trustedfirmware.org <
tf-openci-triage(a)lists.trustedfirmware.org>
Hello All;
FYI; the Cambridge lab took a serious power hit and is down. They are
scrambling to get things back up, but it may take all weekend.
Expect LAVA failures and other strange results.
Thanks;
-g
--
[image: Linaro] <http://www.linaro.org>
Glen Valante | *Director Program & Project Management*
T: +1.508.517.3461 <1617-320-5000>
glen.valante(a)linaro.org | Skype: gvalante <callto:gvalante>
--
Tf-openci-triage mailing list -- tf-openci-triage(a)lists.trustedfirmware.org
To unsubscribe send an email to
tf-openci-triage-leave(a)lists.trustedfirmware.org
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?