- 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. 5 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 14 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 366362: Control flow issues (DEADCODE) /plat/rockchip/rk3399/drivers/dram/dfs.c: 123 in get_dram_drv_odt_val() ________________________________________________________________________________________________________ *** CID 366362: Control flow issues (DEADCODE) /plat/rockchip/rk3399/drivers/dram/dfs.c: 123 in get_dram_drv_odt_val() 117 tmp = ((mr1_val >> 2) & 1) | ((mr1_val >> 5) & 1) | 118 ((mr1_val >> 7) & 1); 119 if (tmp == 0) 120 drv_config->dram_side_dq_odt = 0; 121 else if (tmp == 1) 122 drv_config->dram_side_dq_odt = 60; >>> CID 366362: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "if (tmp == 3U) drv_config...". 123 else if (tmp == 3) 124 drv_config->dram_side_dq_odt = 40; 125 else 126 drv_config->dram_side_dq_odt = 120; 127 break; 128 case LPDDR3: ** CID 366361: (DEADCODE) /drivers/st/fmc/stm32_fmc2_nand.c: 247 in stm32_fmc2_nand_setup_timing() /drivers/st/fmc/stm32_fmc2_nand.c: 250 in stm32_fmc2_nand_setup_timing() /drivers/st/fmc/stm32_fmc2_nand.c: 203 in stm32_fmc2_nand_setup_timing() ________________________________________________________________________________________________________ *** CID 366361: (DEADCODE) /drivers/st/fmc/stm32_fmc2_nand.c: 247 in stm32_fmc2_nand_setup_timing() 241 * tSETUP_ATT > tDS - (tWAIT - tHIZ) 242 */ 243 tset_att = hclkp; 244 if ((twait < NAND_TCS_MIN) && (tset_att < (NAND_TCS_MIN - twait))) { 245 tset_att = NAND_TCS_MIN - twait; 246 } >>> CID 366361: (DEADCODE) >>> Execution cannot reach the expression "tset_att < 50000UL - twait" inside this statement: "if (twait < 50000UL && tset...". 247 if ((twait < NAND_TCLS_MIN) && (tset_att < (NAND_TCLS_MIN - twait))) { 248 tset_att = NAND_TCLS_MIN - twait; 249 } 250 if ((twait < NAND_TALS_MIN) && (tset_att < (NAND_TALS_MIN - twait))) { 251 tset_att = NAND_TALS_MIN - twait; 252 } /drivers/st/fmc/stm32_fmc2_nand.c: 250 in stm32_fmc2_nand_setup_timing() 244 if ((twait < NAND_TCS_MIN) && (tset_att < (NAND_TCS_MIN - twait))) { 245 tset_att = NAND_TCS_MIN - twait; 246 } 247 if ((twait < NAND_TCLS_MIN) && (tset_att < (NAND_TCLS_MIN - twait))) { 248 tset_att = NAND_TCLS_MIN - twait; 249 } >>> CID 366361: (DEADCODE) >>> Execution cannot reach the expression "tset_att < 50000UL - twait" inside this statement: "if (twait < 50000UL && tset...". 250 if ((twait < NAND_TALS_MIN) && (tset_att < (NAND_TALS_MIN - twait))) { 251 tset_att = NAND_TALS_MIN - twait; 252 } 253 if ((thold_mem < NAND_TRHW_MIN) && 254 (tset_att < (NAND_TRHW_MIN - thold_mem))) { 255 tset_att = NAND_TRHW_MIN - thold_mem; /drivers/st/fmc/stm32_fmc2_nand.c: 203 in stm32_fmc2_nand_setup_timing() 197 * tSETUP_MEM > tDS - (tWAIT - tHIZ) 198 */ 199 tset_mem = hclkp; 200 if ((twait < NAND_TCS_MIN) && (tset_mem < (NAND_TCS_MIN - twait))) { 201 tset_mem = NAND_TCS_MIN - twait; 202 } >>> CID 366361: (DEADCODE) >>> Execution cannot reach the expression "tset_mem < 50000UL - twait" inside this statement: "if (twait < 50000UL && tset...". 203 if ((twait < NAND_TALS_MIN) && (tset_mem < (NAND_TALS_MIN - twait))) { 204 tset_mem = NAND_TALS_MIN - twait; 205 } 206 if ((twait > thiz) && ((twait - thiz) < NAND_TDS_MIN) && 207 (tset_mem < (NAND_TDS_MIN - (twait - thiz)))) { 208 tset_mem = NAND_TDS_MIN - (twait - thiz); ** CID 366360: (UNINIT) /lib/zlib/tf_gunzip.c: 83 in gunzip() /lib/zlib/tf_gunzip.c: 87 in gunzip() ________________________________________________________________________________________________________ *** CID 366360: (UNINIT) /lib/zlib/tf_gunzip.c: 83 in gunzip() 77 zret = inflateInit(&stream); 78 if (zret != Z_OK) { 79 ERROR("zlib: inflate init failed (ret = %d)\n", zret); 80 return (zret == Z_MEM_ERROR) ? -ENOMEM : -EIO; 81 } 82 >>> CID 366360: (UNINIT) >>> Using uninitialized value "stream.total_out" when calling "inflate". [Note: The source code implementation of the function has been overridden by a builtin model.] 83 zret = inflate(&stream, Z_NO_FLUSH); 84 if (zret == Z_STREAM_END) { 85 ret = 0; 86 } else { 87 if (stream.msg) 88 ERROR("%s\n", stream.msg); /lib/zlib/tf_gunzip.c: 87 in gunzip() 81 } 82 83 zret = inflate(&stream, Z_NO_FLUSH); 84 if (zret == Z_STREAM_END) { 85 ret = 0; 86 } else { >>> CID 366360: (UNINIT) >>> Using uninitialized value "stream.msg". 87 if (stream.msg) 88 ERROR("%s\n", stream.msg); 89 ERROR("zlib: inflate failed (ret = %d)\n", zret); 90 ret = (zret == Z_MEM_ERROR) ? -ENOMEM : -EIO; 91 } 92 ** CID 366283: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/x509_crt.c: 568 in x509_get_key_usage() ________________________________________________________________________________________________________ *** CID 366283: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/x509_crt.c: 568 in x509_get_key_usage() 562 if( bs.len < 1 ) 563 return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + 564 MBEDTLS_ERR_ASN1_INVALID_LENGTH ); 565 566 /* Get actual bitstring */ 567 *key_usage = 0; >>> CID 366283: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "bs.len" as a loop boundary. 568 for( i = 0; i < bs.len && i < sizeof( unsigned int ); i++ ) 569 { 570 *key_usage |= (unsigned int) bs.p[i] << (8*i); 571 } 572 573 return( 0 ); ** CID 366277: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/asn1parse.c: 158 in asn1_get_tagged_int() ________________________________________________________________________________________________________ *** CID 366277: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/asn1parse.c: 158 in asn1_get_tagged_int() 152 return( MBEDTLS_ERR_ASN1_INVALID_LENGTH ); 153 /* This is a cryptography library. Reject negative integers. */ 154 if( ( **p & 0x80 ) != 0 ) 155 return( MBEDTLS_ERR_ASN1_INVALID_LENGTH ); 156 157 /* Skip leading zeros. */ >>> CID 366277: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "len" as a loop boundary. 158 while( len > 0 && **p == 0 ) 159 { 160 ++( *p ); 161 --len; 162 } 163 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 8 months

1
0
0 0

Re: [TF-A] 1023 INTID - closed

by AT&T

All right. Thank you Manish and Olivier for your feedback. You can close this topic. Oliver answered the concern I had regarding implementing a vector table during boot time. Ian Burres Cybersecurity R&D > On Feb 3, 2021, at 3:14 AM, tf-a-request(a)lists.trustedfirmware.org wrote: > > Send TF-A mailing list submissions to > tf-a(a)lists.trustedfirmware.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > or, via email, send a message with subject or body 'help' to > tf-a-request(a)lists.trustedfirmware.org > > You can reach the person managing the list at > tf-a-owner(a)lists.trustedfirmware.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TF-A digest..." > > > Today's Topics: > > 1. Re: 1023 spurious interrupt (AT&T) > 2. Re: 1023 spurious interrupt (Olivier Deprez) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Feb 2021 18:15:25 -0700 > From: AT&T <iburres(a)att.net> > To: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] 1023 spurious interrupt > Message-ID: <04497C24-78D2-460F-BCC0-535998937145(a)att.net> > Content-Type: text/plain; charset=utf-8 > > Yep, I had an O not a zero. Don’t see a difference yet, but that definitely needed to be fixed. Thank you. > > Ian Burres > Cybersecurity R&D > > >> On Feb 2, 2021, at 3:53 PM, tf-a-request(a)lists.trustedfirmware.org wrote: >> >> Send TF-A mailing list submissions to >> tf-a(a)lists.trustedfirmware.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> or, via email, send a message with subject or body 'help' to >> tf-a-request(a)lists.trustedfirmware.org >> >> You can reach the person managing the list at >> tf-a-owner(a)lists.trustedfirmware.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of TF-A digest..." >> >> >> Today's Topics: >> >> 1. Re: Spurious interrupt 1023 (Ian Burres) >> 2. Re: Spurious interrupt 1023 (Manish Pandey2) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 2 Feb 2021 14:03:05 -0700 >> From: Ian Burres <iburres(a)att.net> >> To: Olivier Deprez <Olivier.Deprez(a)arm.com>, >> "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> >> Subject: Re: [TF-A] Spurious interrupt 1023 >> Message-ID: <20210202210320.2C48741B32(a)lists.trustedfirmware.org> >> Content-Type: text/plain; charset="utf-8" >> >> UPDATE: I managed to get the Pi to complete the boot process, which is a major hurdle I have been trying to overcome. >> >> As for your questions Olivier: >> >> The vector table is loaded during bl31 (its called in the bl31_main.c main() function, right after bl31_platform_setup()). The Pi 4B uses GICv2 (your assumption was correct) and the BCM2711 chip. >> >> Right now both my irq and fiq handlers use: ID = gicv2_get_pending_interrupt_id(); to read the INTID. >> >> Neither handler does anything else other than print the ID, which returns 1023 for fiq only, using HS_DEBUG(). Nothing returns for irq. >> >> Build options are: PLAT=rpi4 DEBUG=1 LOG_LEVEL=50 RUNTIME_UART=2 GICV2_GO_FOR_EL3=1 >> >> Wasn’t trying to route the UART RX interrupt to EL3, though that’s not a bad idea (FIFO, right?) . However, I have been exploring the idea of generating an ARM timer interrupt (not system timer), but I couldn’t get past the boot issue, which seems to have now been resolved. >> >> Questions: Do you see any reason why loading the vector table during the boot process will prevent interrupts from being routed to EL3 correctly? If you do not, then I think I can take it from here. >> >> Sent from Mail for Windows 10 >> >> From: Olivier Deprez >> Sent: Monday, February 1, 2021 2:36 AM >> To: tf-a(a)lists.trustedfirmware.org; AT&T >> Subject: Re: [TF-A] Spurious interrupt 1023 >> >> Hi Ian, >> >> I guess we'll need a bit more details in order to help you. >> Which platform are you using? which GIC version is it using (looks like GICv2?) ? >> How did you built TF-A for this platform (command line arguments)? >> What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? >> Are you trying to route the UART RX interrupt to EL3? >> Is this UART instance only owned by the SWd? >> How did you setup the interrupt handler? >> Which function are you using to read the INTID? >> >> Regards, >> Olivier. >> >> ________________________________________ >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> >> Sent: 29 January 2021 21:08 >> To: tf-a(a)lists.trustedfirmware.org >> Subject: [TF-A] Spurious interrupt 1023 >> >> I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. >> >> I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? >> >> >> >> Ian Burres >> Cybersecurity R&D >> >> >> -- >> TF-A mailing list >> TF-A(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> >>

4 years, 9 months

1
0
0 0

Re: [TF-A] 1023 spurious interrupt

by Olivier Deprez

Hi, Stepping back to the initial thread, I now miss the rationale for routing interrupts to EL3. "I have successfully implement a Linux driver that allows me to dump kernel page tables and memory; however, I cannot see user page tables (even after running a CPU intensive program ). I believe the only way to view user page tables is to have interrupts routed to EL3 – a Linux driver is not sufficient." If your intent is to dump user process page tables, that's something to do using the linux kernel mm framework, and not necessarily at EL3. Not sure why a "linux driver is not sufficient". More inputs on this may be beneficial. Nevertheless if you need a service in EL3 to do "introspection", you would rather write a form of SiP service accessed through SMC (not necessarily routing interrupts through FIQ). As for the code snippets, replacing vbar_el3 with your own vector table looks wrong. This will break any service call back into EL3 when linux is booted (e.g. PSCI calls....) If you really want to route interrupts to EL3 you shall use the Interrupt Handling Framework as Manish suggested. e.g. uint64_t fiq_handler(uint32_t id, uint32_t flags, void *handle, void *cookie) { [...] return 0; } void register_my_interrupt(void) { int32_t rc, flags = 0; plat_ic_set_interrupt_type(intid, INTR_TYPE_EL3); set_interrupt_rm_flag(flags, NON_SECURE); rc = register_interrupt_type_handler(INTR_TYPE_EL3, fiq_handler, flags); NOTICE("register_interrupt_type_handler %d\n", rc); } Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 03 February 2021 02:15 To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] 1023 spurious interrupt Yep, I had an O not a zero. Don’t see a difference yet, but that definitely needed to be fixed. Thank you. Ian Burres Cybersecurity R&D > On Feb 2, 2021, at 3:53 PM, tf-a-request(a)lists.trustedfirmware.org wrote: > > Send TF-A mailing list submissions to > tf-a(a)lists.trustedfirmware.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > or, via email, send a message with subject or body 'help' to > tf-a-request(a)lists.trustedfirmware.org > > You can reach the person managing the list at > tf-a-owner(a)lists.trustedfirmware.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TF-A digest..." > > > Today's Topics: > > 1. Re: Spurious interrupt 1023 (Ian Burres) > 2. Re: Spurious interrupt 1023 (Manish Pandey2) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Feb 2021 14:03:05 -0700 > From: Ian Burres <iburres(a)att.net> > To: Olivier Deprez <Olivier.Deprez(a)arm.com>, > "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> > Subject: Re: [TF-A] Spurious interrupt 1023 > Message-ID: <20210202210320.2C48741B32(a)lists.trustedfirmware.org> > Content-Type: text/plain; charset="utf-8" > > UPDATE: I managed to get the Pi to complete the boot process, which is a major hurdle I have been trying to overcome. > > As for your questions Olivier: > > The vector table is loaded during bl31 (its called in the bl31_main.c main() function, right after bl31_platform_setup()). The Pi 4B uses GICv2 (your assumption was correct) and the BCM2711 chip. > > Right now both my irq and fiq handlers use: ID = gicv2_get_pending_interrupt_id(); to read the INTID. > > Neither handler does anything else other than print the ID, which returns 1023 for fiq only, using HS_DEBUG(). Nothing returns for irq. > > Build options are: PLAT=rpi4 DEBUG=1 LOG_LEVEL=50 RUNTIME_UART=2 GICV2_GO_FOR_EL3=1 > > Wasn’t trying to route the UART RX interrupt to EL3, though that’s not a bad idea (FIFO, right?) . However, I have been exploring the idea of generating an ARM timer interrupt (not system timer), but I couldn’t get past the boot issue, which seems to have now been resolved. > > Questions: Do you see any reason why loading the vector table during the boot process will prevent interrupts from being routed to EL3 correctly? If you do not, then I think I can take it from here. > > Sent from Mail for Windows 10 > > From: Olivier Deprez > Sent: Monday, February 1, 2021 2:36 AM > To: tf-a(a)lists.trustedfirmware.org; AT&T > Subject: Re: [TF-A] Spurious interrupt 1023 > > Hi Ian, > > I guess we'll need a bit more details in order to help you. > Which platform are you using? which GIC version is it using (looks like GICv2?) ? > How did you built TF-A for this platform (command line arguments)? > What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? > Are you trying to route the UART RX interrupt to EL3? > Is this UART instance only owned by the SWd? > How did you setup the interrupt handler? > Which function are you using to read the INTID? > > Regards, > Olivier. > > ________________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 29 January 2021 21:08 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Spurious interrupt 1023 > > I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. > > I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? > > > > Ian Burres > Cybersecurity R&D > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > >

4 years, 9 months

1
0
0 0

Re: [TF-A] 1023 spurious interrupt

by AT&T

Yep, I had an O not a zero. Don’t see a difference yet, but that definitely needed to be fixed. Thank you. Ian Burres Cybersecurity R&D > On Feb 2, 2021, at 3:53 PM, tf-a-request(a)lists.trustedfirmware.org wrote: > > Send TF-A mailing list submissions to > tf-a(a)lists.trustedfirmware.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > or, via email, send a message with subject or body 'help' to > tf-a-request(a)lists.trustedfirmware.org > > You can reach the person managing the list at > tf-a-owner(a)lists.trustedfirmware.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TF-A digest..." > > > Today's Topics: > > 1. Re: Spurious interrupt 1023 (Ian Burres) > 2. Re: Spurious interrupt 1023 (Manish Pandey2) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Feb 2021 14:03:05 -0700 > From: Ian Burres <iburres(a)att.net> > To: Olivier Deprez <Olivier.Deprez(a)arm.com>, > "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> > Subject: Re: [TF-A] Spurious interrupt 1023 > Message-ID: <20210202210320.2C48741B32(a)lists.trustedfirmware.org> > Content-Type: text/plain; charset="utf-8" > > UPDATE: I managed to get the Pi to complete the boot process, which is a major hurdle I have been trying to overcome. > > As for your questions Olivier: > > The vector table is loaded during bl31 (its called in the bl31_main.c main() function, right after bl31_platform_setup()). The Pi 4B uses GICv2 (your assumption was correct) and the BCM2711 chip. > > Right now both my irq and fiq handlers use: ID = gicv2_get_pending_interrupt_id(); to read the INTID. > > Neither handler does anything else other than print the ID, which returns 1023 for fiq only, using HS_DEBUG(). Nothing returns for irq. > > Build options are: PLAT=rpi4 DEBUG=1 LOG_LEVEL=50 RUNTIME_UART=2 GICV2_GO_FOR_EL3=1 > > Wasn’t trying to route the UART RX interrupt to EL3, though that’s not a bad idea (FIFO, right?) . However, I have been exploring the idea of generating an ARM timer interrupt (not system timer), but I couldn’t get past the boot issue, which seems to have now been resolved. > > Questions: Do you see any reason why loading the vector table during the boot process will prevent interrupts from being routed to EL3 correctly? If you do not, then I think I can take it from here. > > Sent from Mail for Windows 10 > > From: Olivier Deprez > Sent: Monday, February 1, 2021 2:36 AM > To: tf-a(a)lists.trustedfirmware.org; AT&T > Subject: Re: [TF-A] Spurious interrupt 1023 > > Hi Ian, > > I guess we'll need a bit more details in order to help you. > Which platform are you using? which GIC version is it using (looks like GICv2?) ? > How did you built TF-A for this platform (command line arguments)? > What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? > Are you trying to route the UART RX interrupt to EL3? > Is this UART instance only owned by the SWd? > How did you setup the interrupt handler? > Which function are you using to read the INTID? > > Regards, > Olivier. > > ________________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 29 January 2021 21:08 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Spurious interrupt 1023 > > I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. > > I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? > > > > Ian Burres > Cybersecurity R&D > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > >

4 years, 9 months

1
0
0 0

Re: [TF-A] Spurious interrupt 1023

by Manish Pandey2

I have seen same thing in your previous thread also, could you please confirm that the build option GICV2_G0_FOR_EL3 instead of GICV2_GO_FOR_EL3 (zero instead of "O"). ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Ian Burres via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 02 February 2021 21:03 To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Spurious interrupt 1023 UPDATE: I managed to get the Pi to complete the boot process, which is a major hurdle I have been trying to overcome. As for your questions Olivier: The vector table is loaded during bl31 (its called in the bl31_main.c main() function, right after bl31_platform_setup()). The Pi 4B uses GICv2 (your assumption was correct) and the BCM2711 chip. Right now both my irq and fiq handlers use: ID = gicv2_get_pending_interrupt_id(); to read the INTID. Neither handler does anything else other than print the ID, which returns 1023 for fiq only, using HS_DEBUG(). Nothing returns for irq. Build options are: PLAT=rpi4 DEBUG=1 LOG_LEVEL=50 RUNTIME_UART=2 GICV2_GO_FOR_EL3=1 Wasn’t trying to route the UART RX interrupt to EL3, though that’s not a bad idea (FIFO, right?) . However, I have been exploring the idea of generating an ARM timer interrupt (not system timer), but I couldn’t get past the boot issue, which seems to have now been resolved. Questions: Do you see any reason why loading the vector table during the boot process will prevent interrupts from being routed to EL3 correctly? If you do not, then I think I can take it from here. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Olivier Deprez<mailto:Olivier.Deprez@arm.com> Sent: Monday, February 1, 2021 2:36 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>; AT&T<mailto:iburres@att.net> Subject: Re: [TF-A] Spurious interrupt 1023 Hi Ian, I guess we'll need a bit more details in order to help you. Which platform are you using? which GIC version is it using (looks like GICv2?) ? How did you built TF-A for this platform (command line arguments)? What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? Are you trying to route the UART RX interrupt to EL3? Is this UART instance only owned by the SWd? How did you setup the interrupt handler? Which function are you using to read the INTID? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 29 January 2021 21:08 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Spurious interrupt 1023 I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? Ian Burres Cybersecurity R&D -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 months

1
0
0 0

Re: [TF-A] Spurious interrupt 1023

by Olivier Deprez

Hi Ian, I guess we'll need a bit more details in order to help you. Which platform are you using? which GIC version is it using (looks like GICv2?) ? How did you built TF-A for this platform (command line arguments)? What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? Are you trying to route the UART RX interrupt to EL3? Is this UART instance only owned by the SWd? How did you setup the interrupt handler? Which function are you using to read the INTID? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 29 January 2021 21:08 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Spurious interrupt 1023 I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? Ian Burres Cybersecurity R&D -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 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. 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 366312: Uninitialized variables (UNINIT) /drivers/renesas/rzg/ddr/ddr_b/boot_init_dram.c: 760 in ddrphy_regif_chk() ________________________________________________________________________________________________________ *** CID 366312: Uninitialized variables (UNINIT) /drivers/renesas/rzg/ddr/ddr_b/boot_init_dram.c: 760 in ddrphy_regif_chk() 754 PI_VERSION_CODE = 0x2041U; /* G2M */ 755 } 756 757 ddr_getval_ach(_reg_PI_VERSION, (uint32_t *)tmp_ach); 758 err = 0U; 759 foreach_vch(ch) { >>> CID 366312: Uninitialized variables (UNINIT) >>> Using uninitialized value "PI_VERSION_CODE". 760 if (tmp_ach[ch] != PI_VERSION_CODE) { 761 err = 1U; 762 } 763 } 764 return err; 765 } ** CID 366311: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 366311: Memory - corruptions (OVERRUN) /drivers/renesas/rzg/ddr/ddr_b/boot_init_dram.c: 3156 in rdqdm_man1() 3150 } 3151 } 3152 } 3153 if ((prr_product == PRR_PRODUCT_M3) && 3154 (prr_cut <= PRR_PRODUCT_10)) { 3155 for (slice = 0U; slice < SLICE_CNT; slice++) { >>> CID 366311: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 32 by passing argument "slice" (which evaluates to 24) in call to "rdqdm_man1_set". 3156 rdqdm_man1_set(ddr_csn, ch, slice); 3157 } 3158 } 3159 } 3160 ddrphy_regif_idle(); 3161 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 9 months

1
0
0 0

Spurious interrupt 1023

by AT&T

I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? Ian Burres Cybersecurity R&D

4 years, 9 months

1
0
0 0

Re: [TF-A] PK hash verify after signature virified

by Manish Badarkhe

Hi Bin Wu, Thanks for coming up with this question. As per the below signature verification code, you raised a valid point that signature gets verified before ROTPK hash verification. 1. Get ROTPK hash from the platform (Using platform implemented method e.g., HW register). 2. Extract ROTPK from the image itself. 3. Use ROTPK to verify the image signature. 4. Calculate the hash of ROTPK and compare it against the hash received in step[1]. But we can't see any concern as the system fails to boot anyways at step [4] if the ROTPK gets corrupted. Regards Manish Badarkhe From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of 吴斌(郅隆) via TF-A <tf-a(a)lists.trustedfirmware.org> Date: Friday, 29 January 2021 at 07:55 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] PK hash verify after signature virified Hi All, I am studying tbbr module in ATF recenlty. I have a little confusion about the ROTPK hash verify flow. In ATF current implementation, we will verify the signature first, then verify the ROTPK hash. But in my understanding, we should verify ROTPK first then verify signature. So, what is the consideration that we use current flow in ATF? Thanks for you patience BRs， Bin Wu

4 years, 9 months

1
0
0 0

PK hash verify after signature virified

by 吴斌(郅隆)

Hi All, I am studying tbbr module in ATF recenlty. I have a little confusion about the ROTPK hash verify flow. In ATF current implementation, we will verify the signature first, then verify the ROTPK hash. But in my understanding, we should verify ROTPK first then verify signature. So, what is the consideration that we use current flow in ATF? Thanks for you patience BRs， Bin Wu

4 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A