- TF-A - lists.trustedfirmware.org

Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE

by Olivier Deprez

Hi Raghu, On the toolchain question you would normally use CROSS_COMPILE=aarch64-none-elf- as recommended here: https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/initial-… However this does not seem to be the root cause of the problem you report. I reproduce the build issue, however it's not yet clear to me if this platform_normal_stacks variable should be rather placed in a specific section (.data?), rather than embedded in the code. Tbc. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Alexei Fedorov via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 30 July 2020 14:53 To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Is it a copy/paste typo? CTX_INCLUDE_EL2)REGS Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 30 July 2020 02:44 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE When I compile TF-A code on the integration branch with the ENABLE_PIE=1 option for FVP, I get a linker error “./build/fvp/debug/bl31/platform_mp_stack.o: relocation R_AARCH64_ABS32 against `a local symbol' can not be used when making a shared object". It appears to be related to line 62(.word platform_normal_stack) of plat/common/aarch64/platform_mp_stack.S that was introduced by https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4301 . It looks like the linker is having trouble resolving this symbol for which I cant find a use for. If I remove line 62 or set ENABLE_PIE=0, the below command line to compile succeeds. What is the use of line 62 in the file? Seems like it may have some use in other configurations that are not obvious. Or is the issue due to the toolchain I’m using? See gcc version below. Command line I’m using: make CROSS_COMPILE=aarch64-none-linux-gnu- TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 DEBUG=1 LOG_LEVEL=40 MBEDTLS_DIR=../mbed-tls PLAT=fvp ARM_ROTPK_LOCATION=regs CTX_INCLUDE_PAUTH_REGS=1 CTX_INCLUDE_EL2)REGS=1 ARM_ARCH_MINOR=5 ENABLE_PIE=1 BRANCH_PROTECTION=1 FVP_HW_CONFIG_DTS=fdts/fvp-base-gicv3-psci-1t.dts BL33=<path_to_bl33> all fip Compiler version: aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025 Thanks Raghu

6 years

2
1
0 0

Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE

by Alexei Fedorov

Is it a copy/paste typo? CTX_INCLUDE_EL2)REGS Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 30 July 2020 02:44 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE When I compile TF-A code on the integration branch with the ENABLE_PIE=1 option for FVP, I get a linker error “./build/fvp/debug/bl31/platform_mp_stack.o: relocation R_AARCH64_ABS32 against `a local symbol' can not be used when making a shared object". It appears to be related to line 62(.word platform_normal_stack) of plat/common/aarch64/platform_mp_stack.S that was introduced by https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4301 . It looks like the linker is having trouble resolving this symbol for which I cant find a use for. If I remove line 62 or set ENABLE_PIE=0, the below command line to compile succeeds. What is the use of line 62 in the file? Seems like it may have some use in other configurations that are not obvious. Or is the issue due to the toolchain I’m using? See gcc version below. Command line I’m using: make CROSS_COMPILE=aarch64-none-linux-gnu- TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 DEBUG=1 LOG_LEVEL=40 MBEDTLS_DIR=../mbed-tls PLAT=fvp ARM_ROTPK_LOCATION=regs CTX_INCLUDE_PAUTH_REGS=1 CTX_INCLUDE_EL2)REGS=1 ARM_ARCH_MINOR=5 ENABLE_PIE=1 BRANCH_PROTECTION=1 FVP_HW_CONFIG_DTS=fdts/fvp-base-gicv3-psci-1t.dts BL33=<path_to_bl33> all fip Compiler version: aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025 Thanks Raghu

6 years

1
0
0 0

Linker error on integration branch for FVP with ENABLE_PIE

by raghu.ncstate＠icloud.com

When I compile TF-A code on the integration branch with the ENABLE_PIE=1 option for FVP, I get a linker error "./build/fvp/debug/bl31/platform_mp_stack.o: relocation R_AARCH64_ABS32 against `a local symbol' can not be used when making a shared object". It appears to be related to line 62(.word platform_normal_stack) of plat/common/aarch64/platform_mp_stack.S that was introduced by https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4301 . It looks like the linker is having trouble resolving this symbol for which I cant find a use for. If I remove line 62 or set ENABLE_PIE=0, the below command line to compile succeeds. What is the use of line 62 in the file? Seems like it may have some use in other configurations that are not obvious. Or is the issue due to the toolchain I'm using? See gcc version below. Command line I'm using: make CROSS_COMPILE=aarch64-none-linux-gnu- TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 DEBUG=1 LOG_LEVEL=40 MBEDTLS_DIR=../mbed-tls PLAT=fvp ARM_ROTPK_LOCATION=regs CTX_INCLUDE_PAUTH_REGS=1 CTX_INCLUDE_EL2)REGS=1 ARM_ARCH_MINOR=5 ENABLE_PIE=1 BRANCH_PROTECTION=1 FVP_HW_CONFIG_DTS=fdts/fvp-base-gicv3-psci-1t.dts BL33=<path_to_bl33> all fip Compiler version: aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025 Thanks Raghu

6 years

1
0
0 0

Re: [TF-A] cactus and ivy on Tegra194

by Olivier Deprez

Hi Varun, Please consider Ivy (and Quark) payloads are remnant from older SPCI specs and must be considered deprecated. We did not clean this in deep to remove the related test code but AFAIK it's just not used anywhere in the test suites (although it may still be built). We may have a plan to upgrade this later when working on S-EL0 partitions on top of Hafnium, but that's not an immediate priority. Considering Cactus, that's the bare-metal S-EL1 payload you can use in place of a real TOS on top of Hafnium. The intent is to test FF-A ABIs unitarily at secure virtual FF-A instance. TFTF at EL2 exercises the ABI at non-secure physical FF-A instance to communicate with the secure endpoint. See below the build commands we use for FVP. Hopefully this should help porting to your platform. Notice it needs as well building the SPMC (aka Hafnium in the secure side), which only supports FVP at this moment (and Rpi, qemu...) It's not described here but I can guide you through this as well. I think you can just use a dummy BL32 payload for now, at least to test the build/integration. If TFTF and TF-A reside in the same top level dir: TFTF: this builds TFTF and cactus secure partitions make CROSS_COMPILE=aarch64-none-elf- PLAT=fvp TESTS=spm -j8 TF-A: this uses TFTF, and assembles two cactus secure partitions within the FIP make \ CROSS_COMPILE=aarch64-none-elf- \ SPD=spmd \ CTX_INCLUDE_EL2_REGS=1 \ ARM_ARCH_MINOR=4 \ BL33=../tf-a-tests/build/fvp/debug/tftf.bin \ BL32=<path-to-secure-hafnium-bin>/hafnium.bin \ SP_LAYOUT_FILE=../tf-a-tests/build/fvp/debug/sp_layout.json \ PLAT=fvp \ all fip The tool last FIP tool entries are the two cactus instances: B4B5671E-4A90-4FE1-B81F-FB13DAE1DACB: offset=0x47DA3, size=0xC168, cmdline="--blob" D1582309-F023-47B9-827C-4464F5578FC8: offset=0x53F0B, size=0xC168, cmdline="--blob" Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 27 July 2020 06:46 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] cactus and ivy on Tegra194 Hello, In order to test the SPM dispatcher from TF-A, we plan to enable ‘cactus’ and ‘ivy’ on Tegra194 platforms. I was able to muscle my way through all the compilation issues, but the final payload generation part is not that clear. Can someone please help me with the steps to generate the final FIP package with all the payloads – TF-A, Cactus, Ivy? Thanks.

6 years

2
3
0 0

TF-A Tech Forum Agenda @ Thr 30th July 2020 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 30th July 2020 16:00 – 17:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Agenda: * Detailed Investigation for support for TRNG (True Random Number Generator) * Presented by Jimmy Brisson * Initial Investigation for support for GIC600AE * Presented by Jimmy Brisson * Optional TF-A Mailing List Topic Discussions If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. Thanks Joanna

6 years

1
0
0 0

Re: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by Sandrine Bailleux

Hello Joanna, Varun, Regarding the idea of looping in Coverity Scan Online in the patch submission process, that is not possible because this free service from Synopsys only allows for a dozen of analyses to be requested per week per open-source project. If we were to request analyses for every patch submission, we would hit the limit very quickly. That is the reason why this is setup to run on the integration branch once per work week day at the moment. I appreciate this is not ideal (as pointed out by both of you) as we get defects reports after patches have been merged but I can't see another way out of this. Regards, Sandrine On 7/27/20 9:08 AM, Joanna Farley via TF-A wrote: > Hi Varun, > > At this time not that I know of which is why we have the solution we have. I'm sure with enough investment of effort something can be done. If we were going to do that though I would personally prefer investigating integrating this tighter into the patch review tooling and report there before patch submitting but there too lies challenges interfacing to the online Coverity server offered as a free service to opensource projects. > > Cheers > > Joanna > > > On 22/07/2020, 18:09, "TF-A on behalf of Varun Wadekar via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > > Hi, > > Is there a way to create a ticket and assign Coverity flagged issues to the code owner automatically? > > -Varun > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of scan-admin--- via TF-A > Sent: Wednesday, July 22, 2020 8:17 AM > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware > > External email: Use caution opening links or attachments > > > 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 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) > /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() > > > ________________________________________________________________________________________________________ > *** CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) > /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() > 267 size_t n; > 268 > 269 ASSERT_SYM_PTR_ALIGN(out); > 270 > 271 for (n = 0U; n < nb_elt; n++) { > 272 out[2 * n] = (uint32_t)rates[n]; > >>> CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) > >>> "(uint64_t)rates[n] >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. > 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); > 274 } > 275 } > 276 > 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) > 278 { > > ** CID 360934: Integer handling issues (BAD_SHIFT) > /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() > > > ________________________________________________________________________________________________________ > *** CID 360934: Integer handling issues (BAD_SHIFT) > /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() > 267 size_t n; > 268 > 269 ASSERT_SYM_PTR_ALIGN(out); > 270 > 271 for (n = 0U; n < nb_elt; n++) { > 272 out[2 * n] = (uint32_t)rates[n]; > >>> CID 360934: Integer handling issues (BAD_SHIFT) > >>> In expression "(uint64_t)rates[n] >> 32", right shifting "rates[n]" by more than 31 bits always yields zero. The shift amount is 32. > 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); > 274 } > 275 } > 276 > 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) > 278 { > > ** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) > /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() > > > ________________________________________________________________________________________________________ > *** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) > /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() > 185 return; > 186 } > 187 > 188 rate = plat_scmi_clock_get_rate(msg->agent_id, clock_id); > 189 > 190 return_values.rate[0] = (uint32_t)rate; > >>> CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) > >>> "(uint64_t)rate >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. > 191 return_values.rate[1] = (uint32_t)((uint64_t)rate >> 32); > 192 > 193 scmi_write_response(msg, &return_values, sizeof(return_values)); > 194 } > 195 > 196 static void scmi_clock_rate_set(struct scmi_msg *msg) > > > ________________________________________________________________________________________________________ > To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P… > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

6 years

2
2
0 0

Re: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by Joanna Farley

Hi Varun, At this time not that I know of which is why we have the solution we have. I'm sure with enough investment of effort something can be done. If we were going to do that though I would personally prefer investigating integrating this tighter into the patch review tooling and report there before patch submitting but there too lies challenges interfacing to the online Coverity server offered as a free service to opensource projects. Cheers Joanna On 22/07/2020, 18:09, "TF-A on behalf of Varun Wadekar via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi, Is there a way to create a ticket and assign Coverity flagged issues to the code owner automatically? -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of scan-admin--- via TF-A Sent: Wednesday, July 22, 2020 8:17 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware External email: Use caution opening links or attachments 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 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() ________________________________________________________________________________________________________ *** CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() 267 size_t n; 268 269 ASSERT_SYM_PTR_ALIGN(out); 270 271 for (n = 0U; n < nb_elt; n++) { 272 out[2 * n] = (uint32_t)rates[n]; >>> CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(uint64_t)rates[n] >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); 274 } 275 } 276 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) 278 { ** CID 360934: Integer handling issues (BAD_SHIFT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() ________________________________________________________________________________________________________ *** CID 360934: Integer handling issues (BAD_SHIFT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() 267 size_t n; 268 269 ASSERT_SYM_PTR_ALIGN(out); 270 271 for (n = 0U; n < nb_elt; n++) { 272 out[2 * n] = (uint32_t)rates[n]; >>> CID 360934: Integer handling issues (BAD_SHIFT) >>> In expression "(uint64_t)rates[n] >> 32", right shifting "rates[n]" by more than 31 bits always yields zero. The shift amount is 32. 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); 274 } 275 } 276 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) 278 { ** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() ________________________________________________________________________________________________________ *** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() 185 return; 186 } 187 188 rate = plat_scmi_clock_get_rate(msg->agent_id, clock_id); 189 190 return_values.rate[0] = (uint32_t)rate; >>> CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(uint64_t)rate >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. 191 return_values.rate[1] = (uint32_t)((uint64_t)rate >> 32); 192 193 scmi_write_response(msg, &return_values, sizeof(return_values)); 194 } 195 196 static void scmi_clock_rate_set(struct scmi_msg *msg) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P… -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years

1
0
0 0

cactus and ivy on Tegra194

by Varun Wadekar

Hello, In order to test the SPM dispatcher from TF-A, we plan to enable 'cactus' and 'ivy' on Tegra194 platforms. I was able to muscle my way through all the compilation issues, but the final payload generation part is not that clear. Can someone please help me with the steps to generate the final FIP package with all the payloads - TF-A, Cactus, Ivy? Thanks.

6 years

1
0
0 0

Re: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by Joanna Farley

Hi Varun, I agree things are less than ideal at the moment. We take advantage as an open source project to use the Synopsys online Coverity service and this points to the master branch (actually currently the mirror on github) which means these coverity tests are ran on changes after they have been submitted. Less than ideal I know but better than not being ran at all. Really we would like these to be ran as part of the OpenCI as part of patch reviews but we are not there yet. Not sure if the Synopsys online Coverity service can be setup to support this via Gerrit reviews or if this will have to be done after patch submittals. If it has to be done after then some clever CI scripting would need to be done to identify where the offending change came from. Would welcome other ideas to make this experience better, but for now this is better than nothing. Cheers Joanna On 22/07/2020, 18:09, "TF-A on behalf of Varun Wadekar via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi, Is there a way to create a ticket and assign Coverity flagged issues to the code owner automatically? -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of scan-admin--- via TF-A Sent: Wednesday, July 22, 2020 8:17 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware External email: Use caution opening links or attachments 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 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() ________________________________________________________________________________________________________ *** CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() 267 size_t n; 268 269 ASSERT_SYM_PTR_ALIGN(out); 270 271 for (n = 0U; n < nb_elt; n++) { 272 out[2 * n] = (uint32_t)rates[n]; >>> CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(uint64_t)rates[n] >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); 274 } 275 } 276 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) 278 { ** CID 360934: Integer handling issues (BAD_SHIFT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() ________________________________________________________________________________________________________ *** CID 360934: Integer handling issues (BAD_SHIFT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() 267 size_t n; 268 269 ASSERT_SYM_PTR_ALIGN(out); 270 271 for (n = 0U; n < nb_elt; n++) { 272 out[2 * n] = (uint32_t)rates[n]; >>> CID 360934: Integer handling issues (BAD_SHIFT) >>> In expression "(uint64_t)rates[n] >> 32", right shifting "rates[n]" by more than 31 bits always yields zero. The shift amount is 32. 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); 274 } 275 } 276 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) 278 { ** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() ________________________________________________________________________________________________________ *** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() 185 return; 186 } 187 188 rate = plat_scmi_clock_get_rate(msg->agent_id, clock_id); 189 190 return_values.rate[0] = (uint32_t)rate; >>> CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(uint64_t)rate >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. 191 return_values.rate[1] = (uint32_t)((uint64_t)rate >> 32); 192 193 scmi_write_response(msg, &return_values, sizeof(return_values)); 194 } 195 196 static void scmi_clock_rate_set(struct scmi_msg *msg) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P… -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years

2
3
0 0

Re: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by Varun Wadekar

Hi, Is there a way to create a ticket and assign Coverity flagged issues to the code owner automatically? -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of scan-admin--- via TF-A Sent: Wednesday, July 22, 2020 8:17 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware External email: Use caution opening links or attachments 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 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() ________________________________________________________________________________________________________ *** CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() 267 size_t n; 268 269 ASSERT_SYM_PTR_ALIGN(out); 270 271 for (n = 0U; n < nb_elt; n++) { 272 out[2 * n] = (uint32_t)rates[n]; >>> CID 360935: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(uint64_t)rates[n] >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); 274 } 275 } 276 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) 278 { ** CID 360934: Integer handling issues (BAD_SHIFT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() ________________________________________________________________________________________________________ *** CID 360934: Integer handling issues (BAD_SHIFT) /drivers/st/scmi-msg/clock.c: 273 in write_rate_desc_array_in_buffer() 267 size_t n; 268 269 ASSERT_SYM_PTR_ALIGN(out); 270 271 for (n = 0U; n < nb_elt; n++) { 272 out[2 * n] = (uint32_t)rates[n]; >>> CID 360934: Integer handling issues (BAD_SHIFT) >>> In expression "(uint64_t)rates[n] >> 32", right shifting "rates[n]" by more than 31 bits always yields zero. The shift amount is 32. 273 out[2 * n + 1] = (uint32_t)((uint64_t)rates[n] >> 32); 274 } 275 } 276 277 static void scmi_clock_describe_rates(struct scmi_msg *msg) 278 { ** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() ________________________________________________________________________________________________________ *** CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/scmi-msg/clock.c: 191 in scmi_clock_rate_get() 185 return; 186 } 187 188 rate = plat_scmi_clock_get_rate(msg->agent_id, clock_id); 189 190 return_values.rate[0] = (uint32_t)rate; >>> CID 360933: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(uint64_t)rate >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. 191 return_values.rate[1] = (uint32_t)((uint64_t)rate >> 32); 192 193 scmi_write_response(msg, &return_values, sizeof(return_values)); 194 } 195 196 static void scmi_clock_rate_set(struct scmi_msg *msg) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P… -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A