- TF-A - lists.trustedfirmware.org

Re: [TF-A] Adoption of Conventional Commits

by Varun Wadekar

Hi Chris, This seems like a good proposal to alleviate some of the pain around releases. Some observations/questions. 1. Introducing additional tags will eat into precious real estate. This will be a problem for some changes and developers. 2. In the transition period, the proposal has the potential to "pollute" the history 3. The proposal will add more work for patches cherry-picked from other projects e.g. libfdt 4. How do we handle scenarios where platforms donot want to switch to this policy? I can see how #1 might be of concern to many, but we will have to implement some policy to see how many commits really fall in this category. -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Chris Kay via TF-A Sent: Thursday, February 11, 2021 5:59 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Adoption of Conventional Commits External email: Use caution opening links or attachments Hi all, Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits<https://www.conventionalcommits.org/en/v1.0.0/> specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future. This requires some buy-in (or buy-out, in this case) from maintainers because - even though it's to only a relatively minor extent - it does involve an adjustment to everybody's workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to "something that looks like Conventional Commits", so the change is not exactly sweeping, but any change has the potential be an inconvenience. With that in mind, I propose the following: * We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands * We suggest - in the prerequisites documentation - the installation of two helper tools: * Commitizen<https://github.com/commitizen/cz-cli> * Commitlint<https://github.com/conventional-changelog/commitlint> Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation). You'll find the patches here<https://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%2…>, and specifically the changes to the prerequisites documentation here<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/…>. Feel free to review these changes if you have comments specifically on their implementation. Let me know if you have any questions or concerns. If everybody's on board, we can look to have this upstreamed shortly. Chris

5 years, 3 months

2
4
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 5 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 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: 203 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: 247 in stm32_fmc2_nand_setup_timing() ________________________________________________________________________________________________________ *** CID 366361: (DEADCODE) /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); /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: 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 } ** CID 366360: (UNINIT) /lib/zlib/tf_gunzip.c: 87 in gunzip() /lib/zlib/tf_gunzip.c: 83 in gunzip() ________________________________________________________________________________________________________ *** CID 366360: (UNINIT) /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 /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); ** 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…

5 years, 3 months

1
0
0 0

Re: [TF-A] Getting BUILD_STRING from FIP file

by Manish Pandey2

Hi Daniele, TBBR specification, from where fip format was introduced, is not very clear about usage of serial number and it can be used in IMP DEFINED manner "ToC Serial Number - 32 - The serial number of this ToC". So, theoretically it's possible to use serial number for the purpose you described and it's a valid use of currently (un)used serial number. Currently, at boot time serial number is checked against a non-zero value, which certainly will hold true if you put a valid timstamp instead of "0x12345678". IMO you can go ahead and implement a mechanism to feed Build timestamp to be used as serial number. Thanks Manish P ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Manish Badarkhe via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 11 February 2021 11:39 To: Daniele Alessandrelli <daniele.alessandrelli(a)linux.intel.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Getting BUILD_STRING from FIP file Hi Daniele Please see my replies inline. Thanks Manish Badarkhe From: Daniele Alessandrelli <daniele.alessandrelli(a)linux.intel.com> Date: Thursday, 11 February 2021 at 11:22 To: Manish Badarkhe <Manish.Badarkhe(a)arm.com>, tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Getting BUILD_STRING from FIP file Hi Manish, Thank you very much for the information. 16 bits are not enough to store an epoch, but I'll see if I can encode some other unique build information into 16 bits. Just a question, from your answer I assume that I shouldn't use the 'serial_number' field for what I want to do; so I wonder: what is that field meant to be used for? 'serial_number' field is non-zero number provided by the fip creation tool. It is hardcoded value i.e. TOC_HEADER_SERIAL_NUMBER=0x12345678 as of now. Specifically used during the validation of the TOC header in the code. Regards, Daniele On Thu, 2021-02-11 at 10:14 +0000, Manish Badarkhe wrote: > Hi Daniele > > You can use the ‘flag’ field to mention the platform-specific data(in > your case, a build number). Usage of the ‘flag’ field(64 bit) in the > toc_header are as below: > Bits 0-31 -> reserved > Bits 32-47 -> platform defined data > Bits 48-63 -> reserved > You can make use of the flag[32:47] to put build information. I am > not sure if you can accommodate epoch (converted timestamp) into this > field but, you can encode any data to fit into this 16bit flag field > to identify the FIP build. > > You can use a build command: fiptool update/create --plat-toc-flags > <platform defined data> <your fip bin path> to put the platform > defined data in the FIP image. > > Thanks > Manish Badarkhe > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of > Daniele Alessandrelli via TF-A <tf-a(a)lists.trustedfirmware.org> > Date: Wednesday, 10 February 2021 at 17:04 > To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > Subject: [TF-A] Getting BUILD_STRING from FIP file > > Hi, > > Is there a way to get BUILD_STRING (or a similar string / number that > uniquely identifies the TF-A build, e.g., BUILD_MESSAGE_TIMESTAMP) > from > the FIP file? > > Basically, I'm trying to find a way to know the build number of a FIP > without flashing it. > > I've seen that the FIP TOC header has a 32-bit field named > 'serial_number'. Can it be used to this end? I'm considering > converting BUILD_MESSAGE_TIMESTAMP into an epoch and adding it as > 'serial number', but I'm worried that might be an unintended usage of > the 'serial_number' field. > > Regards, > Daniele > > >

5 years, 3 months

3
3
0 0

Adoption of Conventional Commits

by Chris Kay

Hi all, Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits<https://www.conventionalcommits.org/en/v1.0.0/> specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future. This requires some buy-in (or buy-out, in this case) from maintainers because - even though it's to only a relatively minor extent - it does involve an adjustment to everybody's workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to "something that looks like Conventional Commits", so the change is not exactly sweeping, but any change has the potential be an inconvenience. With that in mind, I propose the following: * We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands * We suggest - in the prerequisites documentation - the installation of two helper tools: * Commitizen<https://github.com/commitizen/cz-cli> * Commitlint<https://github.com/conventional-changelog/commitlint> Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation). You'll find the patches here<https://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%2…>, and specifically the changes to the prerequisites documentation here<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/…>. Feel free to review these changes if you have comments specifically on their implementation. Let me know if you have any questions or concerns. If everybody's on board, we can look to have this upstreamed shortly. Chris

5 years, 3 months

1
0
0 0

Re: [TF-A] Getting BUILD_STRING from FIP file

by Manish Badarkhe

Hi Daniele You can use the ‘flag’ field to mention the platform-specific data(in your case, a build number). Usage of the ‘flag’ field(64 bit) in the toc_header are as below: 1. Bits 0-31 -> reserved 2. Bits 32-47 -> platform defined data 3. Bits 48-63 -> reserved You can make use of the flag[32:47] to put build information. I am not sure if you can accommodate epoch (converted timestamp) into this field but, you can encode any data to fit into this 16bit flag field to identify the FIP build. You can use a build command: fiptool update/create --plat-toc-flags <platform defined data> <your fip bin path> to put the platform defined data in the FIP image. Thanks Manish Badarkhe From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Daniele Alessandrelli via TF-A <tf-a(a)lists.trustedfirmware.org> Date: Wednesday, 10 February 2021 at 17:04 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Getting BUILD_STRING from FIP file Hi, Is there a way to get BUILD_STRING (or a similar string / number that uniquely identifies the TF-A build, e.g., BUILD_MESSAGE_TIMESTAMP) from the FIP file? Basically, I'm trying to find a way to know the build number of a FIP without flashing it. I've seen that the FIP TOC header has a 32-bit field named 'serial_number'. Can it be used to this end? I'm considering converting BUILD_MESSAGE_TIMESTAMP into an epoch and adding it as 'serial number', but I'm worried that might be an unintended usage of the 'serial_number' field. Regards, Daniele -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

2
2
0 0

Getting BUILD_STRING from FIP file

by Daniele Alessandrelli

Hi, Is there a way to get BUILD_STRING (or a similar string / number that uniquely identifies the TF-A build, e.g., BUILD_MESSAGE_TIMESTAMP) from the FIP file? Basically, I'm trying to find a way to know the build number of a FIP without flashing it. I've seen that the FIP TOC header has a 32-bit field named 'serial_number'. Can it be used to this end? I'm considering converting BUILD_MESSAGE_TIMESTAMP into an epoch and adding it as 'serial number', but I'm worried that might be an unintended usage of the 'serial_number' field. Regards, Daniele

5 years, 3 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 11h February 2021 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 11th February 2021 16:00 – 17:00 (GMT). Agenda: * TF-A: Open-CI Introduction & Status * Presented by Joanna Farley with support from Linaro OpenCI Enablement Team * Having a Public CI (Continuous Integration) extensible system has been a goal for a while and this presentation will give an introduction and a high level overview along with the current status. A brief walk through what CI jobs are available, when they are run and how results can be accessed will be shown/demoed. Deeper dives into the OpenCI results and how to analyse will be the subject of future Tech Forum sessions. 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: 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 on the TF-A mailing list. 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…> Thanks Joanna

5 years, 3 months

1
0
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. 7 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 5 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 7 of 7 defect(s) ** 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 ** CID 361221: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 361221: Insecure data handling (TAINTED_SCALAR) /plat/arm/board/arm_fpga/fpga_bl31_setup.c: 238 in fpga_prepare_dtb() 232 233 if (node >= 0) { 234 fdt_del_node(fdt, node); 235 } 236 } 237 >>> CID 361221: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 238 err = fdt_pack(fdt); 239 if (err < 0) { 240 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, err); 241 } 242 243 clean_dcache_range((uintptr_t)fdt, fdt_blob_size(fdt)); ** CID 360537: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 360537: Insecure data handling (TAINTED_SCALAR) /plat/qemu/common/qemu_bl2_setup.c: 72 in update_dt() 66 67 if (dt_add_psci_cpu_enable_methods(fdt)) { 68 ERROR("Failed to add PSCI cpu enable methods in Device Tree\n"); 69 return; 70 } 71 >>> CID 360537: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 72 ret = fdt_pack(fdt); 73 if (ret < 0) 74 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, ret); 75 } 76 77 void bl2_platform_setup(void) ** CID 360536: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 360536: (TAINTED_SCALAR) /plat/rpi/rpi4/rpi4_bl31_setup.c: 214 in rpi4_prepare_dtb() 208 int ret, offs; 209 210 /* Return if no device tree is detected */ 211 if (fdt_check_header(dtb) != 0) 212 return; 213 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->totalsize" to a tainted sink. 214 ret = fdt_open_into(dtb, dtb, 0x100000); 215 if (ret < 0) { 216 ERROR("Invalid Device Tree at %p: error %d\n", dtb, ret); 217 return; 218 } 219 /plat/rpi/rpi4/rpi4_bl31_setup.c: 243 in rpi4_prepare_dtb() 237 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 238 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 239 240 offs = fdt_path_offset(dtb, "/chosen"); 241 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 242 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 243 ret = fdt_pack(dtb); 244 if (ret < 0) 245 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 246 247 clean_dcache_range((uintptr_t)dtb, fdt_blob_size(dtb)); 248 INFO("Changed device tree to advertise PSCI.\n"); /plat/rpi/rpi4/rpi4_bl31_setup.c: 214 in rpi4_prepare_dtb() 208 int ret, offs; 209 210 /* Return if no device tree is detected */ 211 if (fdt_check_header(dtb) != 0) 212 return; 213 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_strings" to a tainted sink. 214 ret = fdt_open_into(dtb, dtb, 0x100000); 215 if (ret < 0) { 216 ERROR("Invalid Device Tree at %p: error %d\n", dtb, ret); 217 return; 218 } 219 /plat/rpi/rpi4/rpi4_bl31_setup.c: 243 in rpi4_prepare_dtb() 237 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 238 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 239 240 offs = fdt_path_offset(dtb, "/chosen"); 241 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 242 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 243 ret = fdt_pack(dtb); 244 if (ret < 0) 245 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 246 247 clean_dcache_range((uintptr_t)dtb, fdt_blob_size(dtb)); 248 INFO("Changed device tree to advertise PSCI.\n"); /plat/rpi/rpi4/rpi4_bl31_setup.c: 243 in rpi4_prepare_dtb() 237 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 238 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 239 240 offs = fdt_path_offset(dtb, "/chosen"); 241 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 242 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 243 ret = fdt_pack(dtb); 244 if (ret < 0) 245 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 246 247 clean_dcache_range((uintptr_t)dtb, fdt_blob_size(dtb)); 248 INFO("Changed device tree to advertise PSCI.\n"); /plat/rpi/rpi4/rpi4_bl31_setup.c: 243 in rpi4_prepare_dtb() 237 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 238 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 239 240 offs = fdt_path_offset(dtb, "/chosen"); 241 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 242 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 243 ret = fdt_pack(dtb); 244 if (ret < 0) 245 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 246 247 clean_dcache_range((uintptr_t)dtb, fdt_blob_size(dtb)); 248 INFO("Changed device tree to advertise PSCI.\n"); ** CID 360535: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 360535: Insecure data handling (TAINTED_SCALAR) /plat/renesas/rcar/bl2_plat_setup.c: 1005 in bl2_el3_early_platform_setup() 999 bl2_lossy_setting(1, LOSSY_ST_ADDR1, LOSSY_END_ADDR1, 1000 LOSSY_FMT1, LOSSY_ENA_DIS1, fcnlnode); 1001 bl2_lossy_setting(2, LOSSY_ST_ADDR2, LOSSY_END_ADDR2, 1002 LOSSY_FMT2, LOSSY_ENA_DIS2, fcnlnode); 1003 #endif 1004 >>> CID 360535: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 1005 fdt_pack(fdt); 1006 NOTICE("BL2: FDT at %p\n", fdt); 1007 1008 if (boot_dev == MODEMR_BOOT_DEV_EMMC_25X1 || 1009 boot_dev == MODEMR_BOOT_DEV_EMMC_50X8) 1010 rcar_io_emmc_setup(); ** CID 346762: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 346762: (TAINTED_SCALAR) /lib/libfdt/fdt_empty_tree.c: 33 in fdt_create_empty_tree() 27 return err; 28 29 err = fdt_end_node(buf); 30 if (err) 31 return err; 32 >>> CID 346762: (TAINTED_SCALAR) >>> Passing tainted variable "buf->size_dt_strings" to a tainted sink. 33 err = fdt_finish(buf); 34 if (err) 35 return err; 36 37 return fdt_open_into(buf, buf, bufsize); /lib/libfdt/fdt_empty_tree.c: 37 in fdt_create_empty_tree() 31 return err; 32 33 err = fdt_finish(buf); 34 if (err) 35 return err; 36 >>> CID 346762: (TAINTED_SCALAR) >>> Passing tainted variable "buf->size_dt_struct" to a tainted sink. 37 return fdt_open_into(buf, buf, bufsize); /lib/libfdt/fdt_empty_tree.c: 37 in fdt_create_empty_tree() 31 return err; 32 33 err = fdt_finish(buf); 34 if (err) 35 return err; 36 >>> CID 346762: (TAINTED_SCALAR) >>> Passing tainted variable "buf->totalsize" to a tainted sink. 37 return fdt_open_into(buf, buf, bufsize); /lib/libfdt/fdt_empty_tree.c: 37 in fdt_create_empty_tree() 31 return err; 32 33 err = fdt_finish(buf); 34 if (err) 35 return err; 36 >>> CID 346762: (TAINTED_SCALAR) >>> Passing tainted variable "buf->size_dt_strings" to a tainted sink. 37 return fdt_open_into(buf, buf, bufsize); ** CID 342997: (TAINTED_SCALAR) /plat/st/common/stm32mp_dt.c: 79 in fdt_get_status() /plat/st/common/stm32mp_dt.c: 89 in fdt_get_status() ________________________________________________________________________________________________________ *** CID 342997: (TAINTED_SCALAR) /plat/st/common/stm32mp_dt.c: 79 in fdt_get_status() 73 { 74 uint8_t status = DT_DISABLED; 75 int len; 76 const char *cchar; 77 78 cchar = fdt_getprop(fdt, node, "status", &len); >>> CID 342997: (TAINTED_SCALAR) >>> Passing tainted variable "(size_t)len" to a tainted sink. [Note: The source code implementation of the function has been overridden by a builtin model.] 79 if ((cchar == NULL) || 80 (strncmp(cchar, "okay", (size_t)len) == 0)) { 81 status |= DT_NON_SECURE; 82 } 83 84 cchar = fdt_getprop(fdt, node, "secure-status", &len); /plat/st/common/stm32mp_dt.c: 89 in fdt_get_status() 83 84 cchar = fdt_getprop(fdt, node, "secure-status", &len); 85 if (cchar == NULL) { 86 if (status == DT_NON_SECURE) { 87 status |= DT_SECURE; 88 } >>> CID 342997: (TAINTED_SCALAR) >>> Passing tainted variable "(size_t)len" to a tainted sink. [Note: The source code implementation of the function has been overridden by a builtin model.] 89 } else if (strncmp(cchar, "okay", (size_t)len) == 0) { 90 status |= DT_SECURE; 91 } 92 93 return status; 94 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

5 years, 3 months

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 5 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 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…

5 years, 3 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 >> >>

5 years, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A