June 2023 - TF-A - lists.trustedfirmware.org

Need a mechanism to easily define platform-independent SMC FIDs

by Julius Werner

Hi, I would like to restart a discussion that we already had a few years ago on a thread called "SMC to intentionally trigger a panic in TF-A" (https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…) but that petered out without any real resolution (and resulted in me ultimately not implementing the feature I was hoping to add). Basically, we are repeatedly stumbling over the problem that we have a use case for some platform-independent SMC API that we want to implement in TF-A, but don't have an appropriate SMC FID range to put it. My request from a few years ago was about implementing a call to intentionally trigger a panic in TF-A for test-automation purposes. Today we came up with a use case where a Trusted OS wants to query BL31 about the location of a shared log buffer: https://review.trustedfirmware.org/20478 . Currently, the available SMC ranges are Arm, CPU, SiP, OEM, Standard, Hypervisor, TA and TOS. The SiP, OEM and TOS ranges are all specific to a single silicon vendor, OEM or trusted OS implementation, so they are not good targets to implement APIs that would make sense to be shared among multiple of these. In theory, the Standard range would probably be the right target to implement calls that are independently useful for multiple platforms / OSes... but as far as I understand, adding a new call to that range requires petitioning Arm to update the SMC calling convention itself, which is a ridiculously high bar to implement a small utility API. In practice, the only choice we have for implementing these kinds of calls is to let every OEM, SiP or TOS assign its own (different) FID for it and then write separate SMC handlers for each in TF-A that all end up calling the same underlying function... which creates a lot of unnecessary code duplication and identifier soup (especially in the case of SMCs for the non-secure OS which would then be implemented by a platform-independent Linux driver that needs a big mapping table to decide which FID to use on which platform for the same API). I think it would be very useful if there was another range of easily allocatable FIDs that developers could just add to with a simple TF-A CL without having to go through a huge specification update process. There are still 41 OENs unused in the Arm SMCCC, and I don't think any new ones were added in the 10 years that the specification existed... so we are really not going to run out of them any time soon. If we could get even one of those OENs for this purpose, we would have 64K FIDs to use up for our small, simple platform-independent API needs, which should last us a long while. We could maybe call it the "Secure Monitor range" and say the FIDs are specific to a certain implementation of Secure Monitor (e.g. TF-A). Then there could just be a header file in the TF-A sources that serves as the authoritative FID assignment table for TF-A, and anyone with a sufficiently useful idea (subject to TF-A maintainer review) for a platform-independent API like this could add it there by just uploading a patch. I recently argued for a similar "simple tag allocation" concept on https://github.com/FirmwareHandoff/firmware_handoff and it found support there, so I hope I'll be able to convince you that it would be useful for SMC FIDs as well?

1 day, 1 hour

3
3
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jun 29, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

10 months

1
0
0 0

Fwd: [Tf-openci-triage] FYI; Cambridge Lab Down

by Don Harbin

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

10 months, 1 week

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Jul 27, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

10 months, 1 week

1
0
0 0

Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Joanna Farley

Currently no topic for this coming week for 15th June. If no topics by Wed 14th I will cancel. Please do reach out to me if there is a topic you would like to present about this week. Joanna From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 15 June 2023 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) Regular bi weekly Trustedfirmware.org TF-A TechForum. I host this and its where we go to our community and present/discuss things live in public. Past sessions listed here https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ Mailing list here if you want to subscribe. https://lists.trustedfirmware.org/mailman/listinfo/tf-a Project page here: https://www.trustedfirmware.org/projects/tf-a/ Abhishek never attended any of these. Cancelled if there is no topic to present. From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 18 June 2020 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. ________________________________ From: Trusted Firmware Public Meetings Sent: Sunday, June 14, 2020 5:21:25 PM (UTC) Coordinated Universal Time To: Trusted Firmware Public Meetings; tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) When: Occurs on Thursday every other week from 4:00 PM to 5:00 PM effective 6/18/2020. Europe/London Where: You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One 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-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

10 months, 2 weeks

1
1
0 0

Canceled event: TF-A Tech Forum @ Thu Jun 15, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

10 months, 2 weeks

1
0
0 0

Re: EHF and SPMD G0 interrupt handling issues

by Olivier Deprez

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?

10 months, 2 weeks

3
9
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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…

10 months, 3 weeks

1
0
0 0

EHF and SPMD G0 interrupt handling issues

by Varun Wadekar

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?

10 months, 3 weeks

1
0
0 0

[CI] New source files have been identified in your patch..

by Marcin Juszkiewicz

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

10 months, 4 weeks

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

TF-A June 2023