- TF-A - lists.trustedfirmware.org

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. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 424609: Parse warnings (PW.PARAM_SET_BUT_NOT_USED) /plat/nuvoton/npcm845x/npcm845x_bl31_setup.c: 132 in () ________________________________________________________________________________________________________ *** CID 424609: Parse warnings (PW.PARAM_SET_BUT_NOT_USED) /plat/nuvoton/npcm845x/npcm845x_bl31_setup.c: 132 in () 126 * in BL2 & EL3 in BL1) before they are lost (potentially). This needs to be 127 * done before the MMU is initialized so that the memory layout can be used 128 * while creating page tables. BL2 has flushed this information to memory, 129 * so we are guaranteed to pick up good data. 130 *****************************************************************************/ 131 void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, >>> CID 424609: Parse warnings (PW.PARAM_SET_BUT_NOT_USED) >>> parameter "arg2" was set but never used 132 u_register_t arg2, u_register_t arg3) 133 { 134 arg0 = arg1 = arg2 = arg3 = 0; 135 #if RESET_TO_BL31 136 void *from_bl2 = (void *)arg0; 137 void *plat_params_from_bl2 = (void *)arg3; ** CID 424608: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/arm/mhu/mhu_v3_x.c: 75 in mhu_v3_x_driver_init() ________________________________________________________________________________________________________ *** CID 424608: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/arm/mhu/mhu_v3_x.c: 75 in mhu_v3_x_driver_init() 69 /* Unsupported MHU version */ 70 return MHU_V_3_X_ERR_UNSUPPORTED_VERSION; 71 } 72 73 /* Read the MHU Architecture Minor Revision */ 74 dev->subversion = >>> CID 424608: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(aidr & (15U /* 0xfU << 0U */)) >> (15U /* 0xfU << 0U */)" is 0 regardless of the values of its operands. This occurs as the operand of assignment. 75 ((aidr & MHU_ARCH_MINOR_REV_MASK) >> MHU_ARCH_MINOR_REV_MASK); 76 77 /* Return error if the MHU minor revision is not 0 */ 78 if (dev->subversion != MHU_MINOR_REV_3_0) { 79 /* Unsupported subversion */ 80 return MHU_V_3_X_ERR_UNSUPPORTED_VERSION; ** CID 424607: Parse warnings (PW.PARAM_SET_BUT_NOT_USED) /plat/nuvoton/npcm845x/npcm845x_bl31_setup.c: 131 in () ________________________________________________________________________________________________________ *** CID 424607: Parse warnings (PW.PARAM_SET_BUT_NOT_USED) /plat/nuvoton/npcm845x/npcm845x_bl31_setup.c: 131 in () 125 * Here is an opportunity to copy parameters passed by the calling EL (S-EL1 126 * in BL2 & EL3 in BL1) before they are lost (potentially). This needs to be 127 * done before the MMU is initialized so that the memory layout can be used 128 * while creating page tables. BL2 has flushed this information to memory, 129 * so we are guaranteed to pick up good data. 130 *****************************************************************************/ >>> CID 424607: Parse warnings (PW.PARAM_SET_BUT_NOT_USED) >>> parameter "arg1" was set but never used 131 void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, 132 u_register_t arg2, u_register_t arg3) 133 { 134 arg0 = arg1 = arg2 = arg3 = 0; 135 #if RESET_TO_BL31 136 void *from_bl2 = (void *)arg0; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 year, 1 month

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Mar 21, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling this instance as no topic planned. Regards, Olivier. " TF-A Tech Forum Thursday Mar 21, 2024 ⋅ 5pm – 6pm Central European Time - Paris 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://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09 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-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

1 year, 1 month

1
0
0 0

Question about RME-DA in TF-A/TF-RMM/FVP

by Chenxu Wang

Hi all, I find that Arm has considered "device for realms" and purposed RME-DA since last year. This is not only a concept but also includes some SMMU hardware extensions (e.g., Realm Page MMIO and DPT). Unfortunately, I only find few contents related to RME-DA in the latest FVP user guide, and nothing in TF-A/TF-RMM. Thus, can I ask 1. Does current FVP simulate the RME-DA? 2. Will TF-A/TF-RMM supports RME-DA recently? Sincerely, WANG Chenxu

1 year, 1 month

2
1
0 0

Compatibility support for SPM_MM and SPMD

by baopeng (A)

Hi Olivier Deprez, We use the SPM_MM framework mainly for read/write control of security variables. We do not want to modify the original application code at this time. At the same time we want to add support for the new SPMD framework based code. ________________________________ Hi Baopeng, By "code based on the SPM_MM framework" I assume you refer to a secure service running in a S-EL0 partition based on the MM protocol? If you can share this information, what kind of service is this implementing? RAS handling, secure variables, TPM back end, other? What kind of interface is needed to access the service? asynchronous with interrupts? synchronous with SMC from normal world? Another question is why do you need to collocate the SPMD if the MM implementation is already achieving the scenarios you need? Ideally you'd want to migrate this service to run on top of: * the EL3 FF-A SPMC https://trustedfirmware-a.readthedocs.io/en/latest/components/el3-spmc.html * or if the HW/chipset implements it, the S-EL2 FF-A SPMC https://hafnium.readthedocs.io/en/latest/secure-partition-manager/index.htm… Knowing the kind of S-EL0 service would help narrowing the effort for a migration. FF-A (https://developer.arm.com/documentation/den0077/latest/) is a modern evolution of MM (https://developer.arm.com/documentation/den0060/latest) and any functionality achieved by the MM protocol can be handled by FF-A. For example the MM_COMMUNICATE interface can be easily swapped by the FFA_MSG_SEND_DIRECT_REQ interface. Regards, Olivier. ________________________________ From: baopeng (A) via TF-A tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Sent: 21 February 2024 07:10 To: tf-a(a)lists.trustedfirmware.org tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] Re: Request for help Hi Olivier Deprez, We have developed code based on the SPM_MM framework and do not want to reconstruct the code. However, we want to adapt the code to the SPMD framework. What should we do? ________________________________ Hi Baopeng, SPM_MM is the legacy implementation for a secure partition manager relying on the MM protocol. This implementation gets deprecated in favor of FF-A based implementations (what you refer to as SPMD + SPMC). Both implementations aren't compatible and it is discouraged to attempt co-locating both. It may be more palatable and future proof to transition all your SW stack to be compliant to FF-A standard. We may help you better if you tell a bit more about the reason for mixing both implementations in the same build. Regards, Olivier. ________________________________ From: baopeng (A) baopeng1@huawei.commailto:baopeng1@huawei.com Sent: 20 February 2024 02:19 To: tf-a-owner(a)lists.trustedfirmware.org tf-a-owner@lists.trustedfirmware.orgmailto:tf-a-owner@lists.trustedfirmware.org Subject: Request for help Dear Sir/ Madam, we need to support the simultaneous loading of SPMD and SPM_MM due to project reasons. However, we notice that the makefile of SPM_MM of ATF does not support the simultaneous loading of SPMD and SPM_MM by default. I would like to ask what is the main reason for making the current restrictions?

1 year, 2 months

2
2
0 0

Updated invitation with note: TF-A Tech Forum @ Every 2 weeks from 9am to 10am on Thursday (MST) (tf-a@lists.trustedfirmware.org)

by Don Harbin

This event has been updated with a note: "Updating invite link" Changed: description TF-A Tech Forum Every 2 weeks from 9am to 10am on Thursday Mountain Standard Time - Phoenix 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://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09 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-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests tf-a(a)lists.trustedfirmware.org marek.bykowski(a)gmail.com okash.khawaja(a)gmail.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

1 year, 2 months

2
2
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. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 415256: Memory - corruptions (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 415256: Memory - corruptions (ARRAY_VS_SINGLETON) /qcbor/src/qcbor_decode.c: 3725 in QCBORDecode_ExitBoundedMapOrArray() 3719 that is being exited. If there is no cached value, 3720 from previous map search, then do a dummy search. 3721 */ 3722 if(pMe->uMapEndOffsetCache == QCBOR_MAP_OFFSET_CACHE_INVALID) { 3723 QCBORItem Dummy; 3724 Dummy.uLabelType = QCBOR_TYPE_NONE; >>> CID 415256: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Passing "&Dummy" to function "MapSearch" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 3725 uErr = MapSearch(pMe, &Dummy, NULL, NULL, NULL); 3726 if(uErr != QCBOR_SUCCESS) { 3727 goto Done; 3728 } 3729 } 3730 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 year, 2 months

1
0
0 0

ENABLE_LTO feature usage.

by Kummari, Prasad

Hi , We want to include ENABLE_LTO option in platform build. Can you please recommend if this can be passed only on the build command line, or it can be included in the platform makefile (platform.mk) also. Regards, Prasad.

1 year, 2 months

4
10
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. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 415033: Memory - corruptions (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 471 in amu_context_save() ________________________________________________________________________________________________________ *** CID 415033: Memory - corruptions (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 471 in amu_context_save() 465 for (i = 0U; i < amcgcr_el0_cg0nc; i++) { 466 ctx->group0_cnts[i] = amu_group0_cnt_read(i); 467 } 468 469 #if ENABLE_AMU_AUXILIARY_COUNTERS 470 for (i = 0U; i < amcgcr_el0_cg1nc; i++) { >>> CID 415033: Memory - corruptions (OVERRUN) >>> Overrunning array "ctx->group1_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 471 ctx->group1_cnts[i] = amu_group1_cnt_read(i); 472 } 473 #endif 474 475 /* 476 * Save virtual offsets for counters that offer them. ** CID 415032: Memory - illegal accesses (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 548 in amu_context_restore() ________________________________________________________________________________________________________ *** CID 415032: Memory - illegal accesses (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 548 in amu_context_restore() 542 for (i = 0U; i < amcgcr_el0_cg0nc; i++) { 543 amu_group0_cnt_write(i, ctx->group0_cnts[i]); 544 } 545 546 #if ENABLE_AMU_AUXILIARY_COUNTERS 547 for (i = 0U; i < amcgcr_el0_cg1nc; i++) { >>> CID 415032: Memory - illegal accesses (OVERRUN) >>> Overrunning array "ctx->group1_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 548 amu_group1_cnt_write(i, ctx->group1_cnts[i]); 549 } 550 #endif 551 552 /* 553 * Restore virtual offsets for counters that offer them. ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 year, 2 months

1
0
0 0

mbedtls and PQC algorithms support

by shripad.nunjundarao＠broadcom.com

Hi, Is there a plan for mbedtls to add support for PQC algorithms (Dilithium/Khyber)? regards, /Shripad

1 year, 2 months

2
1
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. 27 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 20 of 27 defect(s) ** CID 415001: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1922 in upwr_pwm_boot_start() ________________________________________________________________________________________________________ *** CID 415001: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1922 in upwr_pwm_boot_start() 1916 } 1917 1918 if (api_state != UPWR_API_READY) { 1919 return -3; 1920 } 1921 >>> CID 415001: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1922 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 1923 return -1; 1924 } 1925 1926 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, (upwr_callb)bootcallb); 1927 ** CID 415000: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2195 in upwr_pwm_power_on() ________________________________________________________________________________________________________ *** CID 415000: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2195 in upwr_pwm_power_on() 2189 size_t stsize = 0U; 2190 2191 if (api_state != UPWR_API_READY) { 2192 return -3; 2193 } 2194 >>> CID 415000: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2195 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2196 return -1; 2197 } 2198 2199 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2200 ** CID 414999: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2290 in upwr_pwm_power_off() ________________________________________________________________________________________________________ *** CID 414999: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2290 in upwr_pwm_power_off() 2284 size_t stsize = 0; 2285 2286 if (api_state != UPWR_API_READY) { 2287 return -3; 2288 } 2289 >>> CID 414999: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2290 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2291 return -1; 2292 } 2293 2294 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2295 ** CID 414998: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/imx/imx8ulp/scmi/scmi_pd.c: 243 in plat_scmi_pd_psw() ________________________________________________________________________________________________________ *** CID 414998: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /plat/imx/imx8ulp/scmi/scmi_pd.c: 243 in plat_scmi_pd_psw() 237 return 0; 238 } 239 240 on = (state == POWER_STATE_ON) ? true : false; 241 242 if ((imx8ulp_psw[psw_parent].flags & ALWAYS_ON) == 0U) { >>> CID 414998: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "1 << imx8ulp_psw[psw_parent].reg" with type "int" (32 bits, signed) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 243 swt = 1 << imx8ulp_psw[psw_parent].reg; 244 if (imx8ulp_psw[psw_parent].count == 0U) { 245 if (on == false) { 246 WARN("off PSW[%d] that already in off state\n", psw_parent); 247 ret = -EACCES; 248 } else { ** CID 414997: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1869 in upwr_pwm_dom_power_on() ________________________________________________________________________________________________________ *** CID 414997: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1869 in upwr_pwm_dom_power_on() 1863 } 1864 1865 if (api_state != UPWR_API_READY) { 1866 return -3; 1867 } 1868 >>> CID 414997: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1869 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 1870 return -1; 1871 } 1872 1873 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, (upwr_callb)pwroncallb); 1874 ** CID 414996: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2117 in upwr_pwm_freq_setup() ________________________________________________________________________________________________________ *** CID 414996: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2117 in upwr_pwm_freq_setup() 2111 upwr_pwm_freq_msg txmsg = {0}; 2112 2113 if (api_state != UPWR_API_READY) { 2114 return -3; 2115 } 2116 >>> CID 414996: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2117 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2118 return -1; 2119 } 2120 2121 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2122 ** CID 414995: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2372 in upwr_pwm_mem_retain() ________________________________________________________________________________________________________ *** CID 414995: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2372 in upwr_pwm_mem_retain() 2366 unsigned long ptrval = 0UL; /* needed for X86, ARM64 */ 2367 2368 if (api_state != UPWR_API_READY) { 2369 return -3; 2370 } 2371 >>> CID 414995: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2372 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2373 return -1; 2374 } 2375 2376 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2377 ** CID 414994: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2547 in upwr_pwm_pmode_config() ________________________________________________________________________________________________________ *** CID 414994: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2547 in upwr_pwm_pmode_config() 2541 unsigned long ptrval = 0UL; /* needed for X86, ARM64 */ 2542 2543 if (api_state != UPWR_API_READY) { 2544 return -3; 2545 } 2546 >>> CID 414994: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2547 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2548 return -1; 2549 } 2550 2551 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2552 ** CID 414993: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1812 in upwr_dlm_process_monitor() ________________________________________________________________________________________________________ *** CID 414993: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1812 in upwr_dlm_process_monitor() 1806 upwr_pmon_msg txmsg = {0}; 1807 1808 if (api_state != UPWR_API_READY) { 1809 return -3; 1810 } 1811 >>> CID 414993: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (4U /* 1U << 2U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1812 if (UPWR_SG_BUSY(UPWR_SG_DELAYM)) { 1813 return -1; 1814 } 1815 1816 UPWR_USR_CALLB(UPWR_SG_DELAYM, callb); 1817 ** CID 414992: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1973 in upwr_pwm_param() ________________________________________________________________________________________________________ *** CID 414992: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1973 in upwr_pwm_param() 1967 upwr_pwm_param_msg txmsg = {0}; 1968 1969 if (api_state != UPWR_API_READY) { 1970 return -3; 1971 } 1972 >>> CID 414992: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1973 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 1974 return -1; 1975 } 1976 1977 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 1978 ** CID 414991: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1511 in upwr_vtm_vmeter_measure() ________________________________________________________________________________________________________ *** CID 414991: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1511 in upwr_vtm_vmeter_measure() 1505 upwr_volt_vmeter_meas_msg txmsg = {0}; 1506 1507 if (api_state != UPWR_API_READY) { 1508 return -3; 1509 } 1510 >>> CID 414991: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (8U /* 1U << 3U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1511 if (UPWR_SG_BUSY(UPWR_SG_VOLTM)) { 1512 return -1; 1513 } 1514 1515 UPWR_USR_CALLB(UPWR_SG_VOLTM, callb); 1516 ** CID 414990: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2775 in upwr_dgn_mode() ________________________________________________________________________________________________________ *** CID 414990: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2775 in upwr_dgn_mode() 2769 * -3 if called in an invalid API state 2770 */ 2771 int upwr_dgn_mode(upwr_dgn_mode_t mode, const upwr_callb callb) 2772 { 2773 upwr_dgn_mode_msg txmsg = {0}; 2774 >>> CID 414990: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (64U /* 1U << 6U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2775 if (UPWR_SG_BUSY(UPWR_SG_DIAG)) { 2776 return -1; 2777 } 2778 2779 UPWR_USR_CALLB(UPWR_SG_DIAG, callb); 2780 ** CID 414989: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1692 in upwr_dlm_get_delay_margin() ________________________________________________________________________________________________________ *** CID 414989: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1692 in upwr_dlm_get_delay_margin() 1686 upwr_dmeter_get_delay_margin_msg txmsg = {0}; 1687 1688 if (api_state != UPWR_API_READY) { 1689 return -3; 1690 } 1691 >>> CID 414989: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (4U /* 1U << 2U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1692 if (UPWR_SG_BUSY(UPWR_SG_DELAYM)) { 1693 return -1; 1694 } 1695 1696 UPWR_USR_CALLB(UPWR_SG_DELAYM, callb); 1697 ** CID 414988: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1632 in upwr_tpm_get_temperature() ________________________________________________________________________________________________________ *** CID 414988: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1632 in upwr_tpm_get_temperature() 1626 upwr_temp_get_cur_temp_msg txmsg = {0}; 1627 1628 if (api_state != UPWR_API_READY) { 1629 return -3; 1630 } 1631 >>> CID 414988: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (32U /* 1U << 5U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1632 if (UPWR_SG_BUSY(UPWR_SG_TEMPM)) { 1633 return -1; 1634 } 1635 1636 UPWR_USR_CALLB(UPWR_SG_TEMPM, callb); 1637 ** CID 415014: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1317 in upwr_vtm_chng_pmic_voltage() ________________________________________________________________________________________________________ *** CID 415014: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1317 in upwr_vtm_chng_pmic_voltage() 1311 upwr_volt_pmic_set_volt_msg txmsg = {0}; 1312 1313 if (api_state != UPWR_API_READY) { 1314 return -3; 1315 } 1316 >>> CID 415014: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (8U /* 1U << 3U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1317 if (UPWR_SG_BUSY(UPWR_SG_VOLTM)) { 1318 return -1; 1319 } 1320 1321 UPWR_USR_CALLB(UPWR_SG_VOLTM, callb); 1322 ** CID 415013: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2727 in upwr_pwm_chng_mem_bias() ________________________________________________________________________________________________________ *** CID 415013: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2727 in upwr_pwm_chng_mem_bias() 2721 upwr_pwm_mem_bias_msg txmsg = {0}; 2722 2723 if (api_state != UPWR_API_READY) { 2724 return -3; 2725 } 2726 >>> CID 415013: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2727 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2728 return -1; 2729 } 2730 2731 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2732 ** CID 415012: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2674 in upwr_pwm_chng_dom_bias() ________________________________________________________________________________________________________ *** CID 415012: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2674 in upwr_pwm_chng_dom_bias() 2668 upwr_pwm_dom_bias_msg txmsg = {0}; 2669 2670 if (api_state != UPWR_API_READY) { 2671 return -3; 2672 } 2673 >>> CID 415012: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2674 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2675 return -1; 2676 } 2677 2678 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2679 ** CID 415011: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1559 in upwr_vtm_pmic_config() ________________________________________________________________________________________________________ *** CID 415011: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1559 in upwr_vtm_pmic_config() 1553 unsigned long ptrval = 0UL; /* needed for X86, ARM64 */ 1554 1555 if (api_state != UPWR_API_READY) { 1556 return -3; 1557 } 1558 >>> CID 415011: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (8U /* 1U << 3U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1559 if (UPWR_SG_BUSY(UPWR_SG_VOLTM)) { 1560 return -1; 1561 } 1562 1563 UPWR_USR_CALLB(UPWR_SG_VOLTM, callb); 1564 ** CID 415010: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2616 in upwr_pwm_reg_config() ________________________________________________________________________________________________________ *** CID 415010: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 2616 in upwr_pwm_reg_config() 2610 unsigned long ptrval = 0UL; /* needed for X86, ARM64 */ 2611 2612 if (api_state != UPWR_API_READY) { 2613 return -3; 2614 } 2615 >>> CID 415010: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (2U /* 1U << 1U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 2616 if (UPWR_SG_BUSY(UPWR_SG_PWRMGMT)) { 2617 return -1; 2618 } 2619 2620 UPWR_USR_CALLB(UPWR_SG_PWRMGMT, callb); 2621 ** CID 415009: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1443 in upwr_vtm_power_measure() ________________________________________________________________________________________________________ *** CID 415009: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/imx/imx8ulp/upower/upower_api.c: 1443 in upwr_vtm_power_measure() 1437 upwr_volt_pmeter_meas_msg txmsg = {0}; 1438 1439 if (api_state != UPWR_API_READY) { 1440 return -3; 1441 } 1442 >>> CID 415009: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(sg_busy & (8U /* 1U << 3U */)) == 1U" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 1443 if (UPWR_SG_BUSY(UPWR_SG_VOLTM)) { 1444 return -1; 1445 } 1446 1447 UPWR_USR_CALLB(UPWR_SG_VOLTM, callb); 1448 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 year, 2 months

1
0
0 0

All if...else if constructs shall be terminated with an else statement.

by Nithin G

Hello, In the file lib/xlat_tables/xlat_tables_common.c and other associated files, there are instances where if...else if constructs lack an else statement, resulting in violations during the Coverity MISRA-C analysis for the ZynqMP platform. Addressing this issue added empty else statement to resolve the issue but it is related to core translational table logic function. Is it possible to address this issue? Please provide your suggestions. Regards, Nithin G

1 year, 2 months

4
12
0 0

TF-A Node.js migration to v20

by Chris Kay

Hi folks, If you don’t use any of the JavaScript-based tooling from the TF-A repository then you can safely ignore this. I’ve just updated TF-A’s Node.js dependencies, including the minimum version of Node.js required to use the JavaScript-based hooks and tooling from the repository (previously v16, now v20). If you use these and you find that they have started throwing errors, make sure that you are rebased on the latest version of the integration branch, and then run: npm ci If you need to commit changes while the tools are erroring, you can commit with the `-n` flag to skip the commit hooks: git commit -n <usual commit flags…> Please let me know if you run into any issues. Cheers, Chris

1 year, 2 months

1
0
0 0

Compatibility support for SPM_MM and SPMD

by baopeng (A)

Hi Olivier Deprez, One more question, the SPM_MM code will not be removed from the main repository, right? ________________________________ Hi Olivier Deprez, We use the SPM_MM framework mainly for read/write control of security variables. We do not want to modify the original application code at this time. At the same time we want to add support for the new SPMD framework based code. ________________________________ Hi Baopeng, By "code based on the SPM_MM framework" I assume you refer to a secure service running in a S-EL0 partition based on the MM protocol? If you can share this information, what kind of service is this implementing? RAS handling, secure variables, TPM back end, other? What kind of interface is needed to access the service? asynchronous with interrupts? synchronous with SMC from normal world? Another question is why do you need to collocate the SPMD if the MM implementation is already achieving the scenarios you need? Ideally you'd want to migrate this service to run on top of: * the EL3 FF-A SPMC https://trustedfirmware-a.readthedocs.io/en/latest/components/el3-spmc.html * or if the HW/chipset implements it, the S-EL2 FF-A SPMC https://hafnium.readthedocs.io/en/latest/secure-partition-manager/index.html...<https://hafnium.readthedocs.io/en/latest/secure-partition-manager/index.htm…> Knowing the kind of S-EL0 service would help narrowing the effort for a migration. FF-A (https://developer.arm.com/documentation/den0077/latest/) is a modern evolution of MM (https://developer.arm.com/documentation/den0060/latest) and any functionality achieved by the MM protocol can be handled by FF-A. For example the MM_COMMUNICATE interface can be easily swapped by the FFA_MSG_SEND_DIRECT_REQ interface. Regards, Olivier. ________________________________ From: baopeng (A) via TF-A tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Sent: 21 February 2024 07:10 To: tf-a(a)lists.trustedfirmware.org tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: Request for help Hi Olivier Deprez, We have developed code based on the SPM_MM framework and do not want to reconstruct the code. However, we want to adapt the code to the SPMD framework. What should we do? ________________________________ Hi Baopeng, SPM_MM is the legacy implementation for a secure partition manager relying on the MM protocol. This implementation gets deprecated in favor of FF-A based implementations (what you refer to as SPMD + SPMC). Both implementations aren't compatible and it is discouraged to attempt co-locating both. It may be more palatable and future proof to transition all your SW stack to be compliant to FF-A standard. We may help you better if you tell a bit more about the reason for mixing both implementations in the same build. Regards, Olivier. ________________________________ From: baopeng (A) baopeng1@huawei.commailto:baopeng1@huawei.com Sent: 20 February 2024 02:19 To: tf-a-owner(a)lists.trustedfirmware.org tf-a-owner@lists.trustedfirmware.orgmailto:tf-a-owner@lists.trustedfirmware.org Subject: Request for help Dear Sir/ Madam, we need to support the simultaneous loading of SPMD and SPM_MM due to project reasons. However, we notice that the makefile of SPM_MM of ATF does not support the simultaneous loading of SPMD and SPM_MM by default. I would like to ask what is the main reason for making the current restrictions?

1 year, 2 months

2
1
0 0

Updated invitation: TF-A Tech Forum @ Every 2 weeks from 9am to 10am on Thursday (MST) (tf-a@lists.trustedfirmware.org)

by Don Harbin

This event has been updated Changed: description TF-A Tech Forum Every 2 weeks from 9am to 10am on Thursday Mountain Standard Time - Phoenix 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://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09 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-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests tf-a(a)lists.trustedfirmware.org marek.bykowski(a)gmail.com okash.khawaja(a)gmail.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

1 year, 2 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Every 2 weeks from 8am to 9am on Thursday (MST) (tf-a@lists.trustedfirmware.org)

by Don Harbin

This event has been updated TF-A Tech Forum Every 2 weeks from 8am to 9am on Thursday Mountain Standard Time - Phoenix 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 tf-a(a)lists.trustedfirmware.org marek.bykowski(a)gmail.com okash.khawaja(a)gmail.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

1 year, 2 months

1
0
0 0

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

by Bipin Ravi

Hi all, Please use this link for the Tech Forum https://armltd.zoom.us/j/97580924908?pwd=VkVXL2pxemJJYVhieUovRmF4QTU3UT09&f… Bipin -----Original Appointment----- From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com> Sent: Thursday, July 16, 2020 11:22 AM To: Trusted Firmware Public Meetings; Bipin Ravi; John Powell; 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: Thursday, February 22, 2024 4:00 PM-5:00 PM Europe/London. Where: Forwarding as it seems you guys still have the old one in your calendars. You have to accept this one and delete the old one. Don't blame me blame Linaro as its their invite and they said they sent it to everybody on the TF-A ML.... Will send you the link to the zoom recording once it comes through to me as it takes a few days to get the webpages up dated. Joanna From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com<mailto:linaro.org_havjv2figrh5egaiurb229pd8c@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<mailto:tf-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<mailto:tf-a@lists.trustedfirmware.org> Who * Bill Fletcher- creator * tf-a(a)lists.trustedfirmware.org<mailto:tf-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<mailto:tf-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<mailto:tf-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<mailto:tf-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<mailto:tf-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<mailto:tf-a@lists.trustedfirmware.org> Who * Bill Fletcher- creator * tf-a(a)lists.trustedfirmware.org<mailto:tf-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<mailto:tf-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<mailto:tf-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>.

1 year, 2 months

1
0
0 0

TF-A Tech Forum - Feb 22nd 4.00pm BST

by Olivier Deprez

Hi, In the TF-A Tech Forum today Feb, 22nd 4.00pm BST, Harrison Mutai and Manish Pandey will present the Firmware hand-off framework: The presentation will address the firmware handoff framework’s objectives, key concepts, progress on FVP platform support, and plans for wider adoption across other firmware components and Arm platforms. Regards, Olivier. TF-A Tech Forum Thursday Feb 22, 2024 ⋅ 5pm – 6pm Central European Time - Paris 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 tf-a(a)lists.trustedfirmware.org marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com

1 year, 2 months

1
0
0 0

Re: Request for help

by baopeng (A)

Hi Olivier Deprez, We have developed code based on the SPM_MM framework and do not want to reconstruct the code. However, we want to adapt the code to the SPMD framework. What should we do? ________________________________ Hi Baopeng, SPM_MM is the legacy implementation for a secure partition manager relying on the MM protocol. This implementation gets deprecated in favor of FF-A based implementations (what you refer to as SPMD + SPMC). Both implementations aren't compatible and it is discouraged to attempt co-locating both. It may be more palatable and future proof to transition all your SW stack to be compliant to FF-A standard. We may help you better if you tell a bit more about the reason for mixing both implementations in the same build. Regards, Olivier. ________________________________ From: baopeng (A) baopeng1(a)huawei.com<mailto:baopeng1@huawei.com> Sent: 20 February 2024 02:19 To: tf-a-owner(a)lists.trustedfirmware.org tf-a-owner(a)lists.trustedfirmware.org<mailto:tf-a-owner@lists.trustedfirmware.org> Subject: Request for help Dear Sir/ Madam, we need to support the simultaneous loading of SPMD and SPM_MM due to project reasons. However, we notice that the makefile of SPM_MM of ATF does not support the simultaneous loading of SPMD and SPM_MM by default. I would like to ask what is the main reason for making the current restrictions?

1 year, 2 months

2
1
0 0

Purpose of ENABLE_PIE in TF-A without ASLR

by Igor Zhbanov

Hello, I'm trying to understand the purpose of ENABLE_PIE build flag. IIUC, it makes the BL* executables position-independent. But I could not find any ASLR or some other addresses randomization support. Therefore, could you please clarify, what is the point of building position-independent parts, if (most of the time?) they will be loaded at the fixed addresses? Thank you.

1 year, 2 months

2
1
0 0

Re: Request for help

by Olivier Deprez

Hi Baopeng, SPM_MM is the legacy implementation for a secure partition manager relying on the MM protocol. This implementation gets deprecated in favor of FF-A based implementations (what you refer to as SPMD + SPMC). Both implementations aren't compatible and it is discouraged to attempt co-locating both. It may be more palatable and future proof to transition all your SW stack to be compliant to FF-A standard. We may help you better if you tell a bit more about the reason for mixing both implementations in the same build. Regards, Olivier. ________________________________ From: baopeng (A) <baopeng1(a)huawei.com> Sent: 20 February 2024 02:19 To: tf-a-owner(a)lists.trustedfirmware.org <tf-a-owner(a)lists.trustedfirmware.org> Subject: Request for help Dear Sir/ Madam, we need to support the simultaneous loading of SPMD and SPM_MM due to project reasons. However, we notice that the makefile of SPM_MM of ATF does not support the simultaneous loading of SPMD and SPM_MM by default. I would like to ask what is the main reason for making the current restrictions?

1 year, 2 months

1
0
0 0

Trusted Firmware-A LTS v2.10.2 Release Announcement

by Varun Wadekar

Hello, We are happy to announce the first release for the LTS v2.10 program. The code is available on the lts-v2.10 branch (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/log/?h=lts-v2.10) and the latest tag is lts-v2.10.2. This release consists of two minor releases due to last minute defect fixes in lts-v2.10.1. The changelog for both the minor releases is pasted below for quick reference and the complete documentation is now available at https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.2/change-log.html. ========================================================= Trusted Firmware-A LTS version 2.10.1 contains the following patches. 402b9a9c0 fix(cpus): workaround for Cortex-X3 erratum 2779509 [1] 25cf2844b fix(cpus): workaround for Neoverse V1 erratum 2348377 [2] 6becda5d1 fix(cpus): workaround for Cortex-A78C erratum 2743232 [3] d36d16751 fix(cpus): workaround for Neoverse V2 erratum 2662553 [4] 9cec5496d feat(security): add support for SLS mitigation [5] f9405375a fix(errata): check for SCU before accessing DSU [6] b7591e16f fix(rk3328): apply ERRATA_A53_1530924 erratum [7] f98185e1e fix(cpus): workaround for Neoverse V2 erratum 2618597 [8] b98d0b2ed docs: fix errata in RMM-EL3 Communication Interface documentation [9] bdedd844c fix(sgi): apply workarounds for N2 CPU erratum [10] e27b8ecc7 fix(cpus): workaround for Cortex-A710 erratum 2778471 [11] b312fa066 fix(cpus): workaround for Cortex-X2 erratum 2778471 [12] 4a9ed7a29 fix(cpus): workaround for Cortex-A520 erratum 2630792 [13] 0685a91fd fix(errata): add Cortex-A520 definitions [14] 8d45e30a7 fix(cpus): workaround for Cortex-A520 erratum 2858100 [15] 4f5ce871f feat(versal): enable errata management feature [16] 88a8cd0e5 fix(cpus): workaround for Cortex X3 erratum 2743088 [17] 744f07ae7 fix(cpus): workaround for Cortex-X3 erratum 2302506 [18] 7c227dc44 fix(cpus): workaround for Cortex-X3 erratum 2266875 [19] 0e5e99476 fix(cpus): workaround for Cortex-A78C erratum 2683027 [20] 35d133415 docs(security): security advisory for CVE-2023-49100 [21] 84fcd0429 fix(cpus): workaround for Cortex X3 erratum 2641945 [22] 5c972dfdf feat(spmd): initialize SCR_EL3.EEL2 bit at RESET [23] 2624951d2 fix(cpus): workaround for Cortex-A715 erratum 2561034 [24] [1] https://review.trustedfirmware.org/q/Id92dbae6f1f313b133ffaa018fbf9c078da55… [2] https://review.trustedfirmware.org/q/Ica402494f78811c85e56a262e1f60b0991516… [3] https://review.trustedfirmware.org/q/Ic62579c2dd69b7a8cbbeaa936f45b2cc94364… [4] https://review.trustedfirmware.org/q/I3bc43e7299c17db8a6771a547515ffb2a172f… [5] https://review.trustedfirmware.org/q/I59f5963c22431571f5aebe7e0c5642b32362f… [6] https://review.trustedfirmware.org/q/I38cee6085d6e49ba23de95b3de08bc98798ab… [7] https://review.trustedfirmware.org/q/Ib4130fd9d4cd16b12322f44e91196607fcb6b… [8] https://review.trustedfirmware.org/q/I23a81275d1e40cae39e6897093d6cdd3e11c0… [9] https://review.trustedfirmware.org/q/I6d6b7ff084cc731470e873cfdf37beeec0d36… [10] https://review.trustedfirmware.org/q/Ib0240f56813a913309e5a6a1902e2990979e9… [11] https://review.trustedfirmware.org/q/Id3bb4a2673e41ff237682e46784d37752daf2… [12] https://review.trustedfirmware.org/q/Ia95f0e276482283bf50e06c58c2bc5faab3f6… [13] https://review.trustedfirmware.org/q/Idb6f32f680ee1378a57c2d2f809ea847fffe5… [14] https://review.trustedfirmware.org/q/I45153a1aa2d6dace38650268a32106f5201f4… [15] https://review.trustedfirmware.org/q/I5a07163f919352583b03328abd5659bf7b268… [16] https://review.trustedfirmware.org/q/I54cda23d699abc0782f44172c28933f5cbb01… [17] https://review.trustedfirmware.org/q/I2c8577e3ca0781af8b1c3912e577d3bd77f92… [18] https://review.trustedfirmware.org/q/I048b830867915b88afa36582c6da05734a56d… [19] https://review.trustedfirmware.org/q/I9c610777e222f57f520d223bb03fc5ad05af1… [20] https://review.trustedfirmware.org/q/I2bf9e675f48b62b4cd203100f7df40f4846aa… [21] https://review.trustedfirmware.org/q/I13fa93a65e5017dae6c837e88cd80bda72d4c… [22] https://review.trustedfirmware.org/q/Ia6d6ac8a66936c63b8aa8d7698b937f42ba8f… [23] https://review.trustedfirmware.org/q/If8b2bdbb19bc65391a33dd34cc9824a0203ae… [24] https://review.trustedfirmware.org/q/I377f250a2994b6ced3ac7d93f947af6ceb690… Trusted Firmware-A LTS version 2.10.2 contains the following patches. 822bfa39c fix(build): move comment for VERSION_PATCH [1] 7bccacdde fix(build): properly manage versions in .versionrc.js [2] e8e5c7759 fix(build): update versions [3] [1] https://review.trustedfirmware.org/q/I4008ccbccd512edf33f67c645b38937ad1af9… [2] https://review.trustedfirmware.org/q/I612338fd2896f3fe614f23d14f56d58d43318… [3] https://review.trustedfirmware.org/q/Ia80bd4b28fbb7402f4ae139512fcd176bad05… Thanks, TF-A LTS team

1 year, 3 months

1
0
0 0

Trusted Firmware-A LTS v2.8.16 Release Announcement

by Varun Wadekar

Hello, Trusted Firmware-A LTS version 2.8.16 is now available. This release contains the following patches. e80174ea9 fix(cpus): workaround for Cortex X3 erratum 2641945 [1] a3cd44292 fix(cpus): workaround for Cortex-A715 erratum 2561034 [2] [1] https://review.trustedfirmware.org/q/Ia6d6ac8a66936c63b8aa8d7698b937f42ba8f… [2] https://review.trustedfirmware.org/q/I377f250a2994b6ced3ac7d93f947af6ceb690… Thanks, TF-A LTS team

1 year, 3 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Feb 8, 2024 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling as no topic planned. Regards, Olivier." TF-A Tech Forum Thursday Feb 8, 2024 ⋅ 5pm – 6pm Central European Time - Paris 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

1 year, 3 months

1
0
0 0

MMIO with pre/post indexing instructions

by ff

Hi, I am using hypervisors to allow execution of EL3 code directly and had to deal with MMIO caused by instructions that have post-indexing parameters. Xen community had to deal with this in 2022: https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg113335.html This does not cause any trouble and have implemented ways to deal with this expeditiously. Yet, I wonder if it is desirable to from a synchronisation perspective? Cheers FF Compiling TFA 2.10 for PLAT=a80x0_mcbin The following line https://elixir.bootlin.com/arm-trusted-firmware/v2.10.0/source/drivers/marv… Is compiled as: win_reg = mmio_read_32(AMB_WIN_CR_OFFSET(win_id)); 4026d9c: f9470260 ldr x0, [x19, #3584] 4026da0: 9100e002 add x2, x0, #0x38 4026da4: b9400001 ldr w1, [x0] win_reg &= ~WIN_ENABLE_BIT; 4026da8: 121f7821 and w1, w1, #0xfffffffe *(volatile uint32_t*)addr = value; // post-indexing 4026dac: b8008401 str w1, [x0], #8 #gcc --version gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. #objdump --version GNU objdump (GNU Binutils for Ubuntu) 2.36.1 Copyright (C) 2021 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. #I can’t get access to latests compiler and binutils versions to overcome # « ../.. array subscript 0 is outside array bounds of ‘volatile void[0] » # « ../.. has a LOAD segment with RWX permissions » # so I don’t know if this behaviour is changed when using this latests toolchain

1 year, 3 months

2
5
0 0

Handling of normal world interrupts with BL31 PSCI handler

by caleb.ethridge＠analog.com

Hello, If normal world interrupts are received while invoking TF-A's PSCI reset handler, we have observed that the reset can be aborted. In TF-A's PSCI reset handler, a call out to OP-TEE is made before performing the platform-specific reset: https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/p… https://github.com/ARM-software/arm-trusted-firmware/blob/master/services/s… When OP-TEE is entered, it is possible to receive foreign (normal world) interrupts, which invokes the procedure described here: https://optee.readthedocs.io/en/3.16.0/architecture/core.html#deliver-non-s… When the SMC call is aborted as described above, this results in the reboot failing. Linux does not retry the PSCI reset (https://github.com/torvalds/linux/blob/master/drivers/firmware/psci/psci.c#…). This makes sense because it is not expecting the SMC call to fail (it expected to make an uninterruptable SMC call into the secure monitor, not a call into OP-TEE). If OP-TEE itself is setup to handle PSCI reset calls, it also handles them in (uninterruptable) SMC context: https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/psci.c#L140 https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/sm_a32.S#L96 Based on this, we see two possible solutions: a) Masking the non-secure interrupts in BL31 while we are doing a reset b) Removing the call to OPTEE in the reset handler so that we never leave the SMC context Which option do you suggest? Or are we missing an important detail here? Thanks, Caleb

1 year, 3 months

6
11
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A