- TF-A - lists.trustedfirmware.org

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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 > >

5 years, 1 month

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 > >

5 years, 1 month

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

5 years, 1 month

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

5 years, 1 month

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…

5 years, 1 month

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

5 years, 1 month

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

5 years, 1 month

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

5 years, 1 month

1
0
0 0

TF-A Tech Forum Agenda @ Thr 28th January 2021 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 28th January 2021 16:00 – 17:00 (GMT). Agenda: * TF-A: Automotive Enhance (AE) Architecture Support Requirements Discussion * Presented by Manish Pandy and Manish Badarkhe * A discussion on the needs for the Automotive Enhance (AE) space and how TF-A can support that with CPU and GIC capabilities. The goal is to follow-up the recent email to the TF-A mailing list and try and understand project needs in this space by talking to the project community. 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, 1 month

1
0
0 0

Re: [TF-A] Gather GIC changes required for safety critical machines

by Varun Wadekar

<Cc alias> I guess, something went wrong when I clicked "Reply all" the first time. Manish, can you also talk about the tasks that Arm is willing to work on? Then we can ask for volunteers for the remaining ones. I'm sure, NVIDIA will contribute as this topic is close to our heart. -Varun From: Manish Pandey2 <Manish.Pandey2(a)arm.com> Sent: Monday, January 25, 2021 8:05 AM To: Varun Wadekar <vwadekar(a)nvidia.com> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com>; Robin Randhawa <Robin.Randhawa(a)ARM.com>; Ed Doxat <Ed.Doxat(a)arm.com>; Joanna Farley <joannafarley(a)icloud.com>; Manish Badarkhe <Manish.Badarkhe(a)arm.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; Matteo Carlini <Matteo.Carlini(a)arm.com>; Doug Richmond <Doug.Richmond(a)arm.com> Subject: Re: Gather GIC changes required for safety critical machines External email: Use caution opening links or attachments ++ Other Arm folks Just realized that Varun has reduced the recipients(guess that was intentional) ________________________________ From: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Sent: 25 January 2021 10:15 To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com<mailto:Filipe.Rinaldi@arm.com>>; Robin Randhawa <Robin.Randhawa(a)ARM.com<mailto:Robin.Randhawa@ARM.com>>; Ed Doxat <Ed.Doxat(a)arm.com<mailto:Ed.Doxat@arm.com>> Subject: Re: Gather GIC changes required for safety critical machines Hi Varun, We are trying to do both, based on interest from community we will prioritize these tasks. The reason why we can't do all the asks (mentioned in the list) ourselves is, currently we do not have "use cases/platforms" to test all the features, so we would rely on wider community to understand the requirements and work together to develop/test those features. Thanks Manish ________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Sent: 22 January 2021 17:46 To: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com<mailto:Filipe.Rinaldi@arm.com>>; Robin Randhawa <Robin.Randhawa(a)ARM.com<mailto:Robin.Randhawa@ARM.com>>; Ed Doxat <Ed.Doxat(a)arm.com<mailto:Ed.Doxat@arm.com>> Subject: RE: Gather GIC changes required for safety critical machines HI Manish, Thanks for starting this discussion. The list captures all the functionalities that are useful and interesting to us. Trying to understand the ask - are you trying to get feedback to allow you to prioritize the feature list? Or are you asking for the community to rate importance of these requirements? I am afraid, if there isn't enough interest the list might be trimmed which would be an absolute shame. -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Manish Pandey2 via TF-A Sent: Friday, January 22, 2021 8:02 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com<mailto:Filipe.Rinaldi@arm.com>>; Robin Randhawa <Robin.Randhawa(a)ARM.com<mailto:Robin.Randhawa@ARM.com>>; Ed Doxat <Ed.Doxat(a)arm.com<mailto:Ed.Doxat@arm.com>> Subject: [TF-A] Gather GIC changes required for safety critical machines External email: Use caution opening links or attachments Hi, GIC600-AE is variant of GIC for safety critical machines, though its TRM is publicly available from quite some time but currently we do not have support in TF-A. Purpose of this email is to kick start discussions around various possible GIC requirements as far as safety critical machines are concerned. We have created following list of requirements based on inputs we got so far, changes are either adding new AE features or enhancements to existing drivers. GIC-600AE feature requirement: - Inject and detect RAS errors using Fault management unit(FMU) - Validating feature parity with GIC600 - Running GIC IP in Dual core Lock-step(DCLS) mode. GIC/RAS driver enhancements: - Read trace and PMU records - Keep RAS error records alive across a reset - Disable GICR frames of fused-off cores - Support for message signalled interrupts - Saving/Restoring additional GIC registers during PM events Feel free to add any additional requirements. If there is enough community interest during the next Tech-forum meeting(28th Jan) we would like to go through these requirements in more detail. Thanks Manish IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 1 month

1
0
0 0

[PATCHv9 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v9: - cosmetic changes (move if from patch2 to patch3, rename function name and define). v8: - use gpio 0 and 1, align dtb with kernel gpio-restart, gpio-poweroff, change define names, trigger on upper front. (Peter Maydell). v7: - same as v6, but resplit patches: patch 2 no function changes and refactor gpio setup for virt platfrom and patch 3 adds secure gpio. v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/886965bddb0624bdf851… Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: refactor gpios creation arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 111 ++++++++++++++++++++++++++++++++++-------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 ++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 167 insertions(+), 21 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

5 years, 1 month

2
4
0 0

Gather GIC changes required for safety critical machines

by Manish Pandey2

Hi, GIC600-AE is variant of GIC for safety critical machines, though its TRM is publicly available from quite some time but currently we do not have support in TF-A. Purpose of this email is to kick start discussions around various possible GIC requirements as far as safety critical machines are concerned. We have created following list of requirements based on inputs we got so far, changes are either adding new AE features or enhancements to existing drivers. GIC-600AE feature requirement: - Inject and detect RAS errors using Fault management unit(FMU) - Validating feature parity with GIC600 - Running GIC IP in Dual core Lock-step(DCLS) mode. GIC/RAS driver enhancements: - Read trace and PMU records - Keep RAS error records alive across a reset - Disable GICR frames of fused-off cores - Support for message signalled interrupts - Saving/Restoring additional GIC registers during PM events Feel free to add any additional requirements. If there is enough community interest during the next Tech-forum meeting(28th Jan) we would like to go through these requirements in more detail. Thanks Manish

5 years, 1 month

1
0
0 0

[PATCHv8 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v8: - use gpio 0 and 1, align dtb with kernel gpio-restart, gpio-poweroff, change define names, trigger on upper front. (Peter Maydell). v7: - same as v6, but resplit patches: patch 2 no function changes and refactor gpio setup for virt platfrom and patch 3 adds secure gpio. v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/886965bddb0624bdf851… Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: refactor gpios creation arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 111 ++++++++++++++++++++++++++++++++++-------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 ++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 167 insertions(+), 21 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

5 years, 1 month

3
9
0 0

[PATCHv7 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v7: - same as v6, but resplit patches: patch 2 no function changes and refactor gpio setup for virt platfrom and patch 3 adds secure gpio. v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/7556d07e87f755c602cd… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: refactor gpios creation arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 117 ++++++++++++++++++++++++++++++++++-------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 174 insertions(+), 20 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

5 years, 1 month

2
8
0 0

[PATCHv6 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/7556d07e87f755c602cd… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: add secure pl061 for reset/power down arm-virt: combine code for secure and non secure pl061 hw/arm/Kconfig | 1 + hw/arm/virt.c | 118 +++++++++++++++++++++++++++++++++++------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 175 insertions(+), 20 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

5 years, 2 months

2
4
0 0

[PATCHv4 0/2] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/dd4401d8eb8e0f3018b3… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Maxim Uvarov (2): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 40 +++++++++++++++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 3 ++ 6 files changed, 118 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

5 years, 2 months

4
14
0 0

Cancelled event with note: TF-A Tech Forum @ Thu 14 Jan 2021 16:00 - 17:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: "Cancelled - see the mail from Joanna for more details" Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 14 Jan 2021 16:00 – 17:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 2 months

1
0
0 0

CANCELLED: TF-A Tech Forum Agenda @ Thr 14th January 2021 16:00-1700 GMT

by Joanna Farley

Apologies for the late notice I am cancelling this weeks TF-A Tech forum tomorrow as the subject I had hoped to get presented is not ready and I don’t have any alternative for this slot. I will look to have something for the next session on 28th January. Apologies for the late notice. Cancellations of the calendar invite will come from trustedformware.org as I don’t own the invite so it may not appear in your calendars until that is sent out. Thanks Joanna

5 years, 2 months

1
0
0 0

[PATCHv5 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/dd4401d8eb8e0f3018b3… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: add secure pl061 for reset/power down arm-virt: combine code for secure and non secure pl061 hw/arm/Kconfig | 1 + hw/arm/virt.c | 118 +++++++++++++++++++++++++++++++++++------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 175 insertions(+), 20 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

5 years, 2 months

1
3
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 365287: Control flow issues (MISSING_BREAK) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 334 in pm_smc_handler() ________________________________________________________________________________________________________ *** CID 365287: Control flow issues (MISSING_BREAK) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 334 in pm_smc_handler() 328 SMC_RET1(handle, (uint64_t)ret); 329 330 case PM_SET_MAX_LATENCY: 331 ret = pm_set_max_latency(pm_arg[0], pm_arg[1]); 332 SMC_RET1(handle, (uint64_t)ret); 333 >>> CID 365287: Control flow issues (MISSING_BREAK) >>> The case for value "PM_GET_API_VERSION" is not terminated by a 'break' statement. 334 case PM_GET_API_VERSION: 335 /* Check is PM API version already verified */ 336 if (pm_ctx.api_version >= PM_VERSION) { 337 if (!ipi_irq_flag) { 338 /* 339 * Enable IPI IRQ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

5 years, 2 months

1
0
0 0

Re: [TF-A] Routing FIQ timer interrupts to EL3 on Raspberry Pi 4B

by Manish Pandey2

Hi To understand the interrupt handling in TF-A, i recommend you go through https://trustedfirmware-a.readthedocs.io/en/latest/design/interrupt-framewo… To debug your problem, you need to first check if the timer interrupt is generated as FIQ and check whether it indeed is trapped in EL3 (checking SCR_EL3.FIQ=1). Regarding build errors while adding .S files and your assembly implementation, it will be better if you share your code (may be pushing a patch on https://review.trustedfirmware.org). Thanks Manish ________________________________ 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: 06 January 2021 17:56 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Routing FIQ timer interrupts to EL3 on Raspberry Pi 4B I am attempting to route FIQ timer interrupts using the ARM timers (not system timers) to EL3 in order to achieve introspection. I am running TF-A (cross compiled for AArch64/AArch32) on a Raspberry Pi 4B, which uses the Broadcom 2711 chipset. I have written some code, but I am not an embedded software engineer – I’m an IoT pentester. The ARM timers look like this: RPI4_ARM_TIMER_LOAD 0x400 RPI4_ARM_TIMER_VALUE 0x404 ….. RPI4_ARM_TIMER_FREE_COUNTER 0x420 System timers are: RPI4_SYS_TIMER_CLO, RPI4_SYS_TIMER_CS, etc… 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. I have 3 UARTs attached with a debug log and screen setup. From what I have read, the Raspberry Pi 4B uses GICv2. TF-A supports EL3 routing when the build option GICV2_GO_FOR_EL3 is enabled, which I have done. >From what I have gathered, the FIQ interrupt has to be written in assembly. So far, I have created a vector table, loaded the vector table, and masked and unmasked interrupts using daifclr, #3 and daifset, #3 instructions, using inline assembly. The timer is initinitialized and handled using C functions. I am using inline assembly, because I am adding code to the TF-A base, and I have not discovered how to add .S files to the build without receiving make errors. I will gladly share the code I have if it helps, but what I am really looking for is if anyone believes I am on the right track or not. Obviously, I am not implementing something correctly since the interrupt is not being handled. Thanks. Thomas Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

5 years, 2 months

2
1
0 0

[PATCHv3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

Add secure pl061 for reset/power down machine from the secure world (Arm Trusted Firmware). Use the same gpio 3 and gpio 4 which were used by non acpi variant of linux power control gpios. Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org> --- v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) hw/arm/Kconfig | 1 + hw/arm/virt.c | 24 ++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 85 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 1 + 6 files changed, 115 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig index 0a242e4c5d..13cc42dcc8 100644 --- a/hw/arm/Kconfig +++ b/hw/arm/Kconfig @@ -17,6 +17,7 @@ config ARM_VIRT select PL011 # UART select PL031 # RTC select PL061 # GPIO + select GPIO_PWR select PLATFORM_BUS select SMBIOS select VIRTIO_MMIO diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 96985917d3..eff0345303 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -147,6 +147,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_RTC] = { 0x09010000, 0x00001000 }, [VIRT_FW_CFG] = { 0x09020000, 0x00000018 }, [VIRT_GPIO] = { 0x09030000, 0x00001000 }, + [VIRT_SECURE_GPIO] = { 0x09031000, 0x00001000 }, [VIRT_SECURE_UART] = { 0x09040000, 0x00001000 }, [VIRT_SMMU] = { 0x09050000, 0x00020000 }, [VIRT_PCDIMM_ACPI] = { 0x09070000, MEMORY_HOTPLUG_IO_LEN }, @@ -189,6 +190,7 @@ static const int a15irqmap[] = { [VIRT_GPIO] = 7, [VIRT_SECURE_UART] = 8, [VIRT_ACPI_GED] = 9, + [VIRT_SECURE_GPIO] = 10, [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */ [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */ [VIRT_SMMU] = 74, /* ...to 74 + NUM_SMMU_IRQS - 1 */ @@ -864,6 +866,24 @@ static void create_gpio(const VirtMachineState *vms) g_free(nodename); } +static void create_gpio_secure(const VirtMachineState *vms) +{ + DeviceState *pl061_dev; + static DeviceState *gpio_pwr_dev; + + hwaddr base = vms->memmap[VIRT_SECURE_GPIO].base; + int irq = vms->irqmap[VIRT_SECURE_GPIO]; + + pl061_dev = sysbus_create_simple("pl061", base, + qdev_get_gpio_in(vms->gic, irq)); + + gpio_pwr_dev = sysbus_create_simple("gpio-pwr", -1, + qdev_get_gpio_in(pl061_dev, 3)); + + qdev_connect_gpio_out(pl061_dev, 3, qdev_get_gpio_in(gpio_pwr_dev, 3)); + qdev_connect_gpio_out(pl061_dev, 4, qdev_get_gpio_in(gpio_pwr_dev, 4)); +} + static void create_virtio_devices(const VirtMachineState *vms) { int i; @@ -1993,6 +2013,10 @@ static void machvirt_init(MachineState *machine) create_gpio(vms); } + if (vms->secure) { + create_gpio_secure(vms); + } + /* connect powerdown request */ vms->powerdown_notifier.notify = virt_powerdown_req; qemu_register_powerdown_notifier(&vms->powerdown_notifier); diff --git a/hw/gpio/Kconfig b/hw/gpio/Kconfig index b6fdaa2586..f0e7405f6e 100644 --- a/hw/gpio/Kconfig +++ b/hw/gpio/Kconfig @@ -8,5 +8,8 @@ config PL061 config GPIO_KEY bool +config GPIO_PWR + bool + config SIFIVE_GPIO bool diff --git a/hw/gpio/gpio_pwr.c b/hw/gpio/gpio_pwr.c new file mode 100644 index 0000000000..0d0680c9f7 --- /dev/null +++ b/hw/gpio/gpio_pwr.c @@ -0,0 +1,85 @@ +/* + * GPIO qemu power controller + * + * Copyright (c) 2020 Linaro Limited + * + * Author: Maxim Uvarov <maxim.uvarov(a)linaro.org> + * + * Virtual gpio driver which can be used on top of pl061 + * to reboot and shutdown qemu virtual machine. One of use + * case is gpio driver for secure world application (ARM + * Trusted Firmware.). + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "qemu/log.h" +#include "hw/irq.h" +#include "hw/sysbus.h" +#include "sysemu/runstate.h" + +#define TYPE_GPIOPWR "gpio-pwr" +OBJECT_DECLARE_SIMPLE_TYPE(GPIO_PWR_State, GPIOPWR) + +struct GPIO_PWR_State { + SysBusDevice parent_obj; + qemu_irq irq; +}; + +static void gpio_pwr_set_irq(void *opaque, int irq, int level) +{ + GPIO_PWR_State *s = (GPIO_PWR_State *)opaque; + + qemu_set_irq(s->irq, 1); + + if (level) { + return; + } + + switch (irq) { + case 3: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN); + break; + case 4: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET); + break; + default: + qemu_log_mask(LOG_GUEST_ERROR, + "qemu; gpio_pwr: unknown interrupt %d lvl %d\n", + irq, level); + } +} + + +static void gpio_pwr_realize(DeviceState *dev, Error **errp) +{ + GPIO_PWR_State *s = GPIOPWR(dev); + SysBusDevice *sbd = SYS_BUS_DEVICE(dev); + + sysbus_init_irq(sbd, &s->irq); + qdev_init_gpio_in(dev, gpio_pwr_set_irq, 8); +} + +static void gpio_pwr_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + + dc->realize = gpio_pwr_realize; +} + +static const TypeInfo gpio_pwr_info = { + .name = TYPE_GPIOPWR, + .parent = TYPE_SYS_BUS_DEVICE, + .instance_size = sizeof(GPIO_PWR_State), + .class_init = gpio_pwr_class_init, +}; + +static void gpio_pwr_register_types(void) +{ + type_register_static(&gpio_pwr_info); +} + +type_init(gpio_pwr_register_types) diff --git a/hw/gpio/meson.build b/hw/gpio/meson.build index 5c0a7d7b95..79568f00ce 100644 --- a/hw/gpio/meson.build +++ b/hw/gpio/meson.build @@ -1,5 +1,6 @@ softmmu_ss.add(when: 'CONFIG_E500', if_true: files('mpc8xxx.c')) softmmu_ss.add(when: 'CONFIG_GPIO_KEY', if_true: files('gpio_key.c')) +softmmu_ss.add(when: 'CONFIG_GPIO_PWR', if_true: files('gpio_pwr.c')) softmmu_ss.add(when: 'CONFIG_MAX7310', if_true: files('max7310.c')) softmmu_ss.add(when: 'CONFIG_PL061', if_true: files('pl061.c')) softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_gpio.c')) diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index abf54fab49..77a4523cc7 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -81,6 +81,7 @@ enum { VIRT_GPIO, VIRT_SECURE_UART, VIRT_SECURE_MEM, + VIRT_SECURE_GPIO, VIRT_PCDIMM_ACPI, VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, -- 2.17.1

5 years, 2 months

3
3
0 0

Routing FIQ timer interrupts to EL3 on Raspberry Pi 4B

by Ian Burres

I am attempting to route FIQ timer interrupts using the ARM timers (not system timers) to EL3 in order to achieve introspection. I am running TF-A (cross compiled for AArch64/AArch32) on a Raspberry Pi 4B, which uses the Broadcom 2711 chipset. I have written some code, but I am not an embedded software engineer – I’m an IoT pentester. The ARM timers look like this: RPI4_ARM_TIMER_LOAD 0x400 RPI4_ARM_TIMER_VALUE 0x404 ….. RPI4_ARM_TIMER_FREE_COUNTER 0x420 System timers are: RPI4_SYS_TIMER_CLO, RPI4_SYS_TIMER_CS, etc… 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. I have 3 UARTs attached with a debug log and screen setup. >From what I have read, the Raspberry Pi 4B uses GICv2. TF-A supports EL3 routing when the build option GICV2_GO_FOR_EL3 is enabled, which I have done. >From what I have gathered, the FIQ interrupt has to be written in assembly. So far, I have created a vector table, loaded the vector table, and masked and unmasked interrupts using daifclr, #3 and daifset, #3 instructions, using inline assembly. The timer is initinitialized and handled using C functions. I am using inline assembly, because I am adding code to the TF-A base, and I have not discovered how to add .S files to the build without receiving make errors. I will gladly share the code I have if it helps, but what I am really looking for is if anyone believes I am on the right track or not. Obviously, I am not implementing something correctly since the interrupt is not being handled. Thanks. Thomas Sent from Mail for Windows 10

5 years, 2 months

1
0
0 0

[PATCHv2] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

Add secure pl061 for reset/power down machine from the secure world (Arm Trusted Firmware). Use the same gpio 3 and gpio 4 which were used by non acpi variant of linux power control gpios. Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org> --- v2: replace printf with qemu_log (Philippe Mathieu-Daudé) hw/arm/Kconfig | 1 + hw/arm/virt.c | 24 +++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 84 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 1 + 6 files changed, 114 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig index 0a242e4c5d..13cc42dcc8 100644 --- a/hw/arm/Kconfig +++ b/hw/arm/Kconfig @@ -17,6 +17,7 @@ config ARM_VIRT select PL011 # UART select PL031 # RTC select PL061 # GPIO + select GPIO_PWR select PLATFORM_BUS select SMBIOS select VIRTIO_MMIO diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 96985917d3..eff0345303 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -147,6 +147,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_RTC] = { 0x09010000, 0x00001000 }, [VIRT_FW_CFG] = { 0x09020000, 0x00000018 }, [VIRT_GPIO] = { 0x09030000, 0x00001000 }, + [VIRT_SECURE_GPIO] = { 0x09031000, 0x00001000 }, [VIRT_SECURE_UART] = { 0x09040000, 0x00001000 }, [VIRT_SMMU] = { 0x09050000, 0x00020000 }, [VIRT_PCDIMM_ACPI] = { 0x09070000, MEMORY_HOTPLUG_IO_LEN }, @@ -189,6 +190,7 @@ static const int a15irqmap[] = { [VIRT_GPIO] = 7, [VIRT_SECURE_UART] = 8, [VIRT_ACPI_GED] = 9, + [VIRT_SECURE_GPIO] = 10, [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */ [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */ [VIRT_SMMU] = 74, /* ...to 74 + NUM_SMMU_IRQS - 1 */ @@ -864,6 +866,24 @@ static void create_gpio(const VirtMachineState *vms) g_free(nodename); } +static void create_gpio_secure(const VirtMachineState *vms) +{ + DeviceState *pl061_dev; + static DeviceState *gpio_pwr_dev; + + hwaddr base = vms->memmap[VIRT_SECURE_GPIO].base; + int irq = vms->irqmap[VIRT_SECURE_GPIO]; + + pl061_dev = sysbus_create_simple("pl061", base, + qdev_get_gpio_in(vms->gic, irq)); + + gpio_pwr_dev = sysbus_create_simple("gpio-pwr", -1, + qdev_get_gpio_in(pl061_dev, 3)); + + qdev_connect_gpio_out(pl061_dev, 3, qdev_get_gpio_in(gpio_pwr_dev, 3)); + qdev_connect_gpio_out(pl061_dev, 4, qdev_get_gpio_in(gpio_pwr_dev, 4)); +} + static void create_virtio_devices(const VirtMachineState *vms) { int i; @@ -1993,6 +2013,10 @@ static void machvirt_init(MachineState *machine) create_gpio(vms); } + if (vms->secure) { + create_gpio_secure(vms); + } + /* connect powerdown request */ vms->powerdown_notifier.notify = virt_powerdown_req; qemu_register_powerdown_notifier(&vms->powerdown_notifier); diff --git a/hw/gpio/Kconfig b/hw/gpio/Kconfig index b6fdaa2586..f0e7405f6e 100644 --- a/hw/gpio/Kconfig +++ b/hw/gpio/Kconfig @@ -8,5 +8,8 @@ config PL061 config GPIO_KEY bool +config GPIO_PWR + bool + config SIFIVE_GPIO bool diff --git a/hw/gpio/gpio_pwr.c b/hw/gpio/gpio_pwr.c new file mode 100644 index 0000000000..f5868653b3 --- /dev/null +++ b/hw/gpio/gpio_pwr.c @@ -0,0 +1,84 @@ +/* + * GPIO qemu power controller + * + * Copyright (c) 2020 Linaro Limited + * + * Author: Maxim Uvarov <maxim.uvarov(a)linaro.org> + * + * Virtual gpio driver which can be used on top of pl061 + * to reboot and shutdown qemu virtual machine. One of use + * case is gpio driver for secure world application (ARM + * Trusted Firmware.). + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "hw/irq.h" +#include "hw/sysbus.h" +#include "sysemu/runstate.h" + +#define TYPE_GPIOPWR "gpio-pwr" +OBJECT_DECLARE_SIMPLE_TYPE(GPIO_PWR_State, GPIOPWR) + +struct GPIO_PWR_State { + SysBusDevice parent_obj; + qemu_irq irq; +}; + +static void gpio_pwr_set_irq(void *opaque, int irq, int level) +{ + GPIO_PWR_State *s = (GPIO_PWR_State *)opaque; + + qemu_set_irq(s->irq, 1); + + if (level) { + return; + } + + switch (irq) { + case 3: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN); + break; + case 4: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET); + break; + default: + qemu_log_mask(LOG_GUEST_ERROR, + "qemu; gpio_pwr: unknown interrupt %d lvl %d\n", + irq, level); + } +} + + +static void gpio_pwr_realize(DeviceState *dev, Error **errp) +{ + GPIO_PWR_State *s = GPIOPWR(dev); + SysBusDevice *sbd = SYS_BUS_DEVICE(dev); + + sysbus_init_irq(sbd, &s->irq); + qdev_init_gpio_in(dev, gpio_pwr_set_irq, 8); +} + +static void gpio_pwr_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + + dc->realize = gpio_pwr_realize; +} + +static const TypeInfo gpio_pwr_info = { + .name = TYPE_GPIOPWR, + .parent = TYPE_SYS_BUS_DEVICE, + .instance_size = sizeof(GPIO_PWR_State), + .class_init = gpio_pwr_class_init, +}; + +static void gpio_pwr_register_types(void) +{ + type_register_static(&gpio_pwr_info); +} + +type_init(gpio_pwr_register_types) diff --git a/hw/gpio/meson.build b/hw/gpio/meson.build index 5c0a7d7b95..79568f00ce 100644 --- a/hw/gpio/meson.build +++ b/hw/gpio/meson.build @@ -1,5 +1,6 @@ softmmu_ss.add(when: 'CONFIG_E500', if_true: files('mpc8xxx.c')) softmmu_ss.add(when: 'CONFIG_GPIO_KEY', if_true: files('gpio_key.c')) +softmmu_ss.add(when: 'CONFIG_GPIO_PWR', if_true: files('gpio_pwr.c')) softmmu_ss.add(when: 'CONFIG_MAX7310', if_true: files('max7310.c')) softmmu_ss.add(when: 'CONFIG_PL061', if_true: files('pl061.c')) softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_gpio.c')) diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index abf54fab49..77a4523cc7 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -81,6 +81,7 @@ enum { VIRT_GPIO, VIRT_SECURE_UART, VIRT_SECURE_MEM, + VIRT_SECURE_GPIO, VIRT_PCDIMM_ACPI, VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, -- 2.17.1

5 years, 2 months

1
0
0 0

[PATCH] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

Add secure pl061 for reset/power down machine from the secure world (Arm Trusted Firmware). Use the same gpio 3 and gpio 4 which were used by non acpi variant of linux power control gpios. Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org> --- This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/dd4401d8eb8e0f3018b3… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Regards, Maxim. hw/arm/Kconfig | 1 + hw/arm/virt.c | 24 +++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 83 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 1 + 6 files changed, 113 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig index 0a242e4c5d..13cc42dcc8 100644 --- a/hw/arm/Kconfig +++ b/hw/arm/Kconfig @@ -17,6 +17,7 @@ config ARM_VIRT select PL011 # UART select PL031 # RTC select PL061 # GPIO + select GPIO_PWR select PLATFORM_BUS select SMBIOS select VIRTIO_MMIO diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 96985917d3..eff0345303 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -147,6 +147,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_RTC] = { 0x09010000, 0x00001000 }, [VIRT_FW_CFG] = { 0x09020000, 0x00000018 }, [VIRT_GPIO] = { 0x09030000, 0x00001000 }, + [VIRT_SECURE_GPIO] = { 0x09031000, 0x00001000 }, [VIRT_SECURE_UART] = { 0x09040000, 0x00001000 }, [VIRT_SMMU] = { 0x09050000, 0x00020000 }, [VIRT_PCDIMM_ACPI] = { 0x09070000, MEMORY_HOTPLUG_IO_LEN }, @@ -189,6 +190,7 @@ static const int a15irqmap[] = { [VIRT_GPIO] = 7, [VIRT_SECURE_UART] = 8, [VIRT_ACPI_GED] = 9, + [VIRT_SECURE_GPIO] = 10, [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */ [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */ [VIRT_SMMU] = 74, /* ...to 74 + NUM_SMMU_IRQS - 1 */ @@ -864,6 +866,24 @@ static void create_gpio(const VirtMachineState *vms) g_free(nodename); } +static void create_gpio_secure(const VirtMachineState *vms) +{ + DeviceState *pl061_dev; + static DeviceState *gpio_pwr_dev; + + hwaddr base = vms->memmap[VIRT_SECURE_GPIO].base; + int irq = vms->irqmap[VIRT_SECURE_GPIO]; + + pl061_dev = sysbus_create_simple("pl061", base, + qdev_get_gpio_in(vms->gic, irq)); + + gpio_pwr_dev = sysbus_create_simple("gpio-pwr", -1, + qdev_get_gpio_in(pl061_dev, 3)); + + qdev_connect_gpio_out(pl061_dev, 3, qdev_get_gpio_in(gpio_pwr_dev, 3)); + qdev_connect_gpio_out(pl061_dev, 4, qdev_get_gpio_in(gpio_pwr_dev, 4)); +} + static void create_virtio_devices(const VirtMachineState *vms) { int i; @@ -1993,6 +2013,10 @@ static void machvirt_init(MachineState *machine) create_gpio(vms); } + if (vms->secure) { + create_gpio_secure(vms); + } + /* connect powerdown request */ vms->powerdown_notifier.notify = virt_powerdown_req; qemu_register_powerdown_notifier(&vms->powerdown_notifier); diff --git a/hw/gpio/Kconfig b/hw/gpio/Kconfig index b6fdaa2586..f0e7405f6e 100644 --- a/hw/gpio/Kconfig +++ b/hw/gpio/Kconfig @@ -8,5 +8,8 @@ config PL061 config GPIO_KEY bool +config GPIO_PWR + bool + config SIFIVE_GPIO bool diff --git a/hw/gpio/gpio_pwr.c b/hw/gpio/gpio_pwr.c new file mode 100644 index 0000000000..dded12381b --- /dev/null +++ b/hw/gpio/gpio_pwr.c @@ -0,0 +1,83 @@ +/* + * GPIO qemu power controller + * + * Copyright (c) 2020 Linaro Limited + * + * Author: Maxim Uvarov <maxim.uvarov(a)linaro.org> + * + * Virtual gpio driver which can be used on top of pl061 + * to reboot and shutdown qemu virtual machine. One of use + * case is gpio driver for secure world application (ARM + * Trusted Firmware.). + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "hw/irq.h" +#include "hw/sysbus.h" +#include "sysemu/runstate.h" + +#define TYPE_GPIOPWR "gpio-pwr" +OBJECT_DECLARE_SIMPLE_TYPE(GPIO_PWR_State, GPIOPWR) + +struct GPIO_PWR_State { + SysBusDevice parent_obj; + qemu_irq irq; +}; + +static void gpio_pwr_set_irq(void *opaque, int irq, int level) +{ + GPIO_PWR_State *s = (GPIO_PWR_State *)opaque; + + qemu_set_irq(s->irq, 1); + + if (level) { + return; + } + + switch (irq) { + case 3: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN); + break; + case 4: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET); + break; + default: + printf("qemu; gpio_pwr: unknown interrupt %d lvl %d\n", + irq, level); + } +} + + +static void gpio_pwr_realize(DeviceState *dev, Error **errp) +{ + GPIO_PWR_State *s = GPIOPWR(dev); + SysBusDevice *sbd = SYS_BUS_DEVICE(dev); + + sysbus_init_irq(sbd, &s->irq); + qdev_init_gpio_in(dev, gpio_pwr_set_irq, 8); +} + +static void gpio_pwr_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + + dc->realize = gpio_pwr_realize; +} + +static const TypeInfo gpio_pwr_info = { + .name = TYPE_GPIOPWR, + .parent = TYPE_SYS_BUS_DEVICE, + .instance_size = sizeof(GPIO_PWR_State), + .class_init = gpio_pwr_class_init, +}; + +static void gpio_pwr_register_types(void) +{ + type_register_static(&gpio_pwr_info); +} + +type_init(gpio_pwr_register_types) diff --git a/hw/gpio/meson.build b/hw/gpio/meson.build index 5c0a7d7b95..79568f00ce 100644 --- a/hw/gpio/meson.build +++ b/hw/gpio/meson.build @@ -1,5 +1,6 @@ softmmu_ss.add(when: 'CONFIG_E500', if_true: files('mpc8xxx.c')) softmmu_ss.add(when: 'CONFIG_GPIO_KEY', if_true: files('gpio_key.c')) +softmmu_ss.add(when: 'CONFIG_GPIO_PWR', if_true: files('gpio_pwr.c')) softmmu_ss.add(when: 'CONFIG_MAX7310', if_true: files('max7310.c')) softmmu_ss.add(when: 'CONFIG_PL061', if_true: files('pl061.c')) softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_gpio.c')) diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index abf54fab49..77a4523cc7 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -81,6 +81,7 @@ enum { VIRT_GPIO, VIRT_SECURE_UART, VIRT_SECURE_MEM, + VIRT_SECURE_GPIO, VIRT_PCDIMM_ACPI, VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, -- 2.17.1

5 years, 2 months

2
1
0 0

Build error with GCC 10.2-2020.11

by Manish Badarkhe

Hi Carlo Alexei created a patch for testing TF-A/TFTF builds with the toolchain GCC 10.2-2020.11 https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/7733 which flagged build errors for plat/amlogic/axg platform, please see below: Build command lines: make CROSS_COMPILE=aarch64-none-elf- PLAT=axg SPD=opteed DEBUG=1 V=1 fiptool all make AML_USE_ATOS=1 CROSS_COMPILE=aarch64-none-elf- PLAT=axg DEBUG=1 V=1 fiptool all plat/amlogic/axg/axg_pm.c: In function 'axg_pwr_domain_off': plat/amlogic/axg/axg_pm.c:124:43: error: array subscript 2 is above array bounds of 'const plat_local_state_t[2]' {aka 'const unsigned char[2]'} [-Werror=array-bounds] 124 | if (target_state->pwr_domain_state[MPIDR_AFFLVL2] == | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ In file included from plat/amlogic/axg/axg_pm.c:14: include/lib/psci/psci.h:270:28: note: while referencing 'pwr_domain_state' 270 | plat_local_state_t pwr_domain_state[PLAT_MAX_PWR_LVL + U(1)]; | ^~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Makefile:1103: recipe for target '/work/workspace/workspace/tf-worker/trusted_firmware/build/axg/debug/bl31/axg_pm.o' failed make: *** [/work/workspace/workspace/tf-worker/trusted_firmware/build/axg/debug/bl31/axg_pm.o] Error 1 Please help to resolve this issue. Thanks Manish Badarkhe

5 years, 2 months

1
0
0 0

Re: [TF-A] Interrupt about ff-a spec

by Achin Gupta

Hi Feng, On Fri, Dec 18, 2020 at 04:41:37PM +0000, Chen Feng via TF-A wrote: > Hi, > > While reading the Arm Firmware Framework for Armv8-A > https://developer.arm.com/documentation/den0077/latest > > I do not find the API that for a sp to request vIRQ, or do I miss something. > > Is this some private API that is implementing defined FF-A IDs? Is what you have in mind is an ABI that allows SP0 to raise an interrupt in SP1? Could you please provide more information about your use case? cheers, Achin > > > -- > cheers, > feng > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 2 months

3
3
0 0

Re: [TF-A] Does TF-A support to load and run both TEE and SPM_MM?

by Chen Feng

Hi all, I have a similar but different question here :) Why not the tf-a support both smpd and tspd. Since the vendor's teeos that has not support ff-a interface currently. With armv8.4-sel2, is there a choice to disable scr.eel2 with origin vendor's theeos IDs, and enable scr.eel2 with new ff-a services? It seems to need some tlb maintenance, but it seems work. On 2020/11/23 3:27 下午, Achin Gupta via TF-A wrote: > Hi Heyi, > > Happy to discuss the detail but the short answer is no. > > Instead, it is possible to run an MM partition in S-EL0 under the TEE. This work is being done with OP-TEE. > > From a SW architecture standpoint, it did not seem like a good idea to let EL3 run its "application" i.e. MM SP alongside a TEE which also runs its own applications. It is better to let the TEE own S-EL1 and run all applications in S-EL0 under it. > > Cheers, > Achin > > On 23/11/2020, 05:36, "TF-A on behalf of Heyi Guo via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > > Hi All, > > On some platforms there may be requirements to run both TEE and SPM_MM > instances, such as providing TEE services on server platforms. > > Do TF-A support this scenario? If it doesn't, do it make sense to add > such support? > > Thanks, > > Heyi > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- cheers, feng

5 years, 2 months

2
3
0 0

Interrupt about ff-a spec

by Chen Feng

Hi, While reading the Arm Firmware Framework for Armv8-A https://developer.arm.com/documentation/den0077/latest I do not find the API that for a sp to request vIRQ, or do I miss something. Is this some private API that is implementing defined FF-A IDs? -- cheers, feng

5 years, 2 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 17th December 2020 16:00-1700 GMT: Introduction to the Trusted Services project

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 17th December 2020 16:00 – 17:00 (GMT). As well as being posted to the TF-A mailing list this has been cross posted to OPTEE mailing list. For OPTEE attendees the Zoom call details are included below. Agenda: * An introduction to the Trusted Services project * Presented by Julian Hall * Summary * The Trusted Services project is a new trustedfirmware.org project that provides a home for security related service components that can run in the different isolated processing environments available on Arm Cortex-A. The project attempts to promote reuse and standardization to enable a consistent set of services to be provided by firmware, independent of which isolation technology is used. 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. This is the last TF-A Tech Forum session until January 2021. 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

Re: [TF-A] Question about validity period of X509 certificate

by Andrej Butok

Hello Masato Fukumori, To check a "validity period" of a X 509 certificate, you must be sure that your system date & time is set, correct and not changed. Do you have a reliable way to achieve this? Best regards, Andrej Butok From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of fukumori.masato--- via TF-A Sent: Thursday, December 10, 2020 2:23 PM To: 'tf-a(a)lists.trustedfirmware.org' <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Question about validity period of X509 certificate Hello. I have a question about checking the X 509 certificate with tf-a. My understanding is that tf-a does not check the "validity period" of the X 509 certificate. I 'm not sure why tf-a doesn't check. Does anyone know this background? Best Regards, Masato Fukumori

5 years, 3 months

2
4
0 0

Question about validity period of X509 certificate

by fukumori.masato＠fujitsu.com

Hello. I have a question about checking the X 509 certificate with tf-a. My understanding is that tf-a does not check the "validity period" of the X 509 certificate. I 'm not sure why tf-a doesn't check. Does anyone know this background? Best Regards, Masato Fukumori

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. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 364146: Control flow issues (DEADCODE) /plat/mediatek/mt8192/plat_pm.c: 301 in plat_validate_power_state() ________________________________________________________________________________________________________ *** CID 364146: Control flow issues (DEADCODE) /plat/mediatek/mt8192/plat_pm.c: 301 in plat_validate_power_state() 295 { 296 unsigned int pstate = psci_get_pstate_type(power_state); 297 unsigned int aff_lvl = psci_get_pstate_pwrlvl(power_state); 298 unsigned int cpu = plat_my_core_pos(); 299 300 if (aff_lvl > PLAT_MAX_PWR_LVL) { >>> CID 364146: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return -2;". 301 return PSCI_E_INVALID_PARAMS; 302 } 303 304 if (pstate == PSTATE_TYPE_STANDBY) { 305 req_state->pwr_domain_state[0] = PLAT_MAX_RET_STATE; 306 } else { ** CID 364145: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 42 in ptp3_init() ________________________________________________________________________________________________________ *** CID 364145: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 42 in ptp3_init() 36 * API 37 ************************************************/ 38 void ptp3_init(unsigned int core) 39 { 40 unsigned int _core; 41 >>> CID 364145: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "core >= 0U". 42 if (core >= PTP3_CFG1_CPU_START_ID) { 43 if (core < NR_PTP3_CFG1_CPU) { 44 /* update ptp3_cfg1 */ 45 ptp3_write( 46 ptp3_cfg1[core][PTP3_CFG_ADDR], 47 ptp3_cfg1[core][PTP3_CFG_VALUE]); ** CID 364144: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 76 in ptp3_deinit() ________________________________________________________________________________________________________ *** CID 364144: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 76 in ptp3_deinit() 70 } 71 } 72 } 73 74 void ptp3_deinit(unsigned int core) 75 { >>> CID 364144: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "core >= 0U". 76 if (core >= PTP3_CFG1_CPU_START_ID) { 77 if (core < NR_PTP3_CFG1_CPU) { 78 /* update ptp3_cfg1 */ 79 ptp3_write( 80 ptp3_cfg1[core][PTP3_CFG_ADDR], 81 ptp3_cfg1[core][PTP3_CFG_VALUE] & 82 ~PTP3_CFG1_MASK); 83 } 84 } ________________________________________________________________________________________________________ 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

Cancelled event: TF-A Tech Forum @ Thu 31 Dec 2020 16:00 - 17:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled. Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 31 Dec 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 3 months

1
0
0 0

Cancelled event: TF-A Tech Forum @ Thu 3 Dec 2020 16:00 - 17:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled. Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 3 Dec 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 3 months

1
0
0 0

Re: [TF-A] Does TF-A support to load and run both TEE and SPM_MM?

by Achin Gupta

Hi Heyi, Happy to discuss the detail but the short answer is no. Instead, it is possible to run an MM partition in S-EL0 under the TEE. This work is being done with OP-TEE. From a SW architecture standpoint, it did not seem like a good idea to let EL3 run its "application" i.e. MM SP alongside a TEE which also runs its own applications. It is better to let the TEE own S-EL1 and run all applications in S-EL0 under it. Cheers, Achin On 23/11/2020, 05:36, "TF-A on behalf of Heyi Guo via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi All, On some platforms there may be requirements to run both TEE and SPM_MM instances, such as providing TEE services on server platforms. Do TF-A support this scenario? If it doesn't, do it make sense to add such support? Thanks, Heyi -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

3
7
0 0

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

by Joanna Farley

Apologies, I need to cancel this weeks TF-A Tech Forum session on 3rd December due to clashing events for Arm attendees. Next meeting will be 17th December which will be the last session of 2020. 31st December session is also cancelled with the first 2021 session being 14th January 2021. Thanks Joanna From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 3 December 2020 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

5 years, 3 months

1
0
0 0

Does TF-A support to load and run both TEE and SPM_MM?

by Heyi Guo

Hi All, On some platforms there may be requirements to run both TEE and SPM_MM instances, such as providing TEE services on server platforms. Do TF-A support this scenario? If it doesn't, do it make sense to add such support? Thanks, Heyi

5 years, 3 months

1
0
0 0

Re: [TF-A] [PATCH] plat/qemu/qemu_sbsa: Include libraries for Cortex-A72

by Jens Wiklander

Hi Tanmay, Please upload the patch at https://review.trustedfirmware.org/, for details see https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.html Thanks, Jens On Thu, Nov 19, 2020 at 7:28 PM Tanmay Jagdale <tanmay.jagdale(a)linaro.org> wrote: > > Include libraries needed to emulate Cortex-A72 in sbsa-ref target of Qemu. > > Signed-off-by: Tanmay Jagdale <tanmay.jagdale(a)linaro.org> > --- > plat/qemu/qemu_sbsa/platform.mk | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/plat/qemu/qemu_sbsa/platform.mk b/plat/qemu/qemu_sbsa/platform.mk > index 1a4a2db02..a8036f622 100644 > --- a/plat/qemu/qemu_sbsa/platform.mk > +++ b/plat/qemu/qemu_sbsa/platform.mk > @@ -43,7 +43,8 @@ BL1_SOURCES += drivers/io/io_semihosting.c \ > > BL1_SOURCES += lib/cpus/aarch64/aem_generic.S \ > lib/cpus/aarch64/cortex_a53.S \ > - lib/cpus/aarch64/cortex_a57.S > + lib/cpus/aarch64/cortex_a57.S \ > + lib/cpus/aarch64/cortex_a72.S > > BL2_SOURCES += drivers/io/io_semihosting.c \ > drivers/io/io_storage.c \ > @@ -72,6 +73,7 @@ QEMU_GIC_SOURCES := ${GICV3_SOURCES} \ > BL31_SOURCES += lib/cpus/aarch64/aem_generic.S \ > lib/cpus/aarch64/cortex_a53.S \ > lib/cpus/aarch64/cortex_a57.S \ > + lib/cpus/aarch64/cortex_a72.S \ > lib/semihosting/semihosting.c \ > lib/semihosting/${ARCH}/semihosting_call.S \ > plat/common/plat_psci_common.c \ > -- > 2.29.2 >

5 years, 3 months

2
1
0 0

Hafnium / TF-A v2.4 first tagged release is available

by Olivier Deprez

Hi All, Following the announcement of the Trusted Firmware-A/Trusted Firmware-A-tests v2.4 release: We are pleased to announce the first tagged release of Hafnium [1] implementing the SPMC according to the FF-A v1.0 specification [2]. As a reminder, Hafnium has been transferred to trustedfirmware.org back in May 2020 to become the reference open source S-EL2 firmware, under an Arm/Google co-maintainership. Contributions are open to partners in trustedfirmware.org The Secure Partition Manager documentation is available at [3] Please also refer to the change log at [4] The companion TF-A test suite permits the validation of FF-A ABIs and NWd/SWd communication by the use of bare-metal S-EL1 secure partitions. Thanks to all who contributed to make it happen. Regards, Olivier. [1] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.4 [2] https://developer.arm.com/documentation/den0077/latest [3] https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… [4] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… ________________________________________ 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: 18 November 2020 14:35 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Trusted Firmware-A & Trusted Firmware-A-tests version 2.4 is now available Hi All, Trusted Firmware-A and Trusted Firmware-A-tests version 2.4 is now available and can be found here: Trusted Firmware-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.4 Trusted Firmware-A-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.4 Please refer to the change log of Trusted Firmware-A and Trusted Firmware-A-tests for further information here: Trusted Firmware-A: https://trustedfirmware-a.readthedocs.io/en/v2.4/change-log.html Trusted Firmware-A-tests: https://trustedfirmware-a-tests.readthedocs.io/en/v2.4/change-log.html Thanks Manish Badarkhe

5 years, 3 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 19th November 2020 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 19th November 2020 16:00 – 17:00 (GMT). Please note UK entered Daylight Saving on 25th October when clocks went back one hour to go to GMT from 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: * Trace-based Code Coverage Tooling for Firmware Projects * Presented by Basil Eljuse & Saul Romero * Summary * TF-A has adopted a code coverage system to measure the effectiveness of the various runtime testing performed and this is achieved without doing code instrumentation. This presentation is an overview of that approach which has applicability beyond the TF-A project. * 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

5 years, 3 months

1
0
0 0

Trusted Firmware-A & Trusted Firmware-A-tests version 2.4 is now available

by Manish Badarkhe

Hi All, Trusted Firmware-A and Trusted Firmware-A-tests version 2.4 is now available and can be found here: Trusted Firmware-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.4 Trusted Firmware-A-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.4 Please refer to the change log of Trusted Firmware-A and Trusted Firmware-A-tests for further information here: Trusted Firmware-A: https://trustedfirmware-a.readthedocs.io/en/v2.4/change-log.html Trusted Firmware-A-tests: https://trustedfirmware-a-tests.readthedocs.io/en/v2.4/change-log.html Thanks Manish Badarkhe

5 years, 3 months

1
0
0 0

atf-a with optee-os for firefly-rk3399

by Piotr Lobacz

Hi All, i've been trying for a couple of days to load current optee together with atf from the github, with no luck. For that i have been using manuals (https://trustedfirmware-a.readthedocs.io/en/latest/plat/rockchip.html , http://opensource.rock-chips.com/wiki_ATF ) for rockchip and what i have succeded is to run very old atf tag 1.3 with optee blob from rockchip which i suspect is also very old. And if i try to use any newer atf >= 1.4 than i suspect that it does not load, because i do not see any LOGS from it, no matter that LOG_LEVEL was set to 50... Can anybody help me solving this issue or point me to some solution? Thanks in advance. BR Piotr Łobacz [https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com> Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND KRS: 0000674406, NIP: 9581679801, REGON: 367090912 www.softgent.com Sąd Rejonowy Gdańsk-Północ w Gdańsku, VII Wydział Gospodarczy Krajowego Rejestru Sądowego KRS 0000674406, Kapitał zakładowy: 25 000,00 zł wpłacony w całości.

5 years, 4 months

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Soby Mathew

Hi Julius, The TF-A build sets the `-mstrict-align` compiler option, that means that the compiler will generate only aligned accesses as default. So disabling the check at runtime, seems `unaligned` with the compiler option IMO. The programmer can induce unaligned access though, although I am struggling to understand why the programmer would want to do that. The case you have pointed out seems like an error which needs to be corrected in platform code IMO. > Well, my assumption is that performing an unaligned access cannot be a > vulnerability. TF-A has linker symbol references and non-trivial linker section manipulations at runtime and these have previously triggered alignment errors when binary layout changed due to code issues. Disabling the alignment check at runtime means these errors would have remained undetected and would have resulted in more obscure crash at runtime or even a vulnerablility. In some cases, only the RELEASE builds (DEBUG=0) triggered the alignment fault. > There are scenarios where unaligned accesses can be intentional, but I am not too worried about those -- there are ways to work around that, and if we make it policy that those accesses always need to be written that way I'm okay with that. What I am worried about is mistakes and oversights that slip through testing and then cause random or even attacker-controllable crashes in production. If the main reason you're enabling this flag is to help with early detection of coding mistakes, I wonder if the best approach would be to enable it for DEBUG=1 and disable it for DEBUG=0 (of course, if there are really security issues associated with it like you mentioned above, that wouldn't make sense). Agree. But I am failing to understand why the unaligned accesses came to be there in the first place. My worry is, if this was not intended by the programmer, this might as well be a bug that will remain undetected if the alignment check is disabled. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius > Werner via TF-A > Sent: 10 November 2020 02:31 > To: raghu.ncstate(a)icloud.com > Cc: tf-a <tf-a(a)lists.trustedfirmware.org> > Subject: Re: [TF-A] Alignment fault checking in EL3 > > > >>. What I am worried about is mistakes and oversights that slip > > >>through testing and then cause random or even attacker-controllable > > >>crashes in production > > > > Why would this not be the case even with SCTLR.A bit set? I'm not seeing > the relation between the crash and SCTLR.A bit. If there are oversights that > slip through testing and an attacker can cause a crash, there is > vulnerability/bug. > > If there is something that slipped through, that causes a data > abort(perhaps address not mapped in the translation tables), would we turn > off the MMU ? > > Well, my assumption is that performing an unaligned access cannot be a > vulnerability. If you have examples to the contrary please let me know, but > as far as I am aware letting an unaligned access through should always work > and will always result in the behavior the programmer intended (other than > maybe contrived cases where device address space is mapped with a non- > Device memory type, which is already very wrong for plenty of other reasons > and should never happen). The only negative consequence is that the access > may take slightly longer than if it were aligned. I do understand the desire to > be able to shake out unaligned accesses during development and testing > > I don't think the comparison to a data abort works because obviously with a > data abort the program usually can't just continue and still assume its internal > state is valid.

5 years, 4 months

2
2
0 0

FW: [Linaro-open-discussions] Kickoff: Extend PSCI with OS-initiated mode in TF-A

by Matteo Carlini

Cross-posting on the TF-A mailing list too for interested people to attend the kickoff meeting listed below hosted by Linaro. Thanks Matteo -----Original Message----- From: Linaro-open-discussions <linaro-open-discussions-bounces(a)op-lists.linaro.org> On Behalf Of Ulf Hansson via Linaro-open-discussions Sent: 10 November 2020 10:21 To: linaro-open-discussions(a)op-lists.linaro.org Subject: [Linaro-open-discussions] Kickoff: Extend PSCI with OS-initiated mode in TF-A Hi all, As previously announced we are hosting a kickoff meeting for the above topic/project. The meeting has been added to the linaro-open-discussions calendar, according to the below. Feel free to join us on Thursday this week! Kind regards Ulf Hansson, Linaro KWG When: Thursday Nov 12, 16:00-17:00 CET. Agenda: 1. Introduction. 2. Update of the current support in Linux. 3. Collaborations. 4. Technical things. 5. Other matters. To join the Zoom Meeting: https://linaro-org.zoom.us/j/97261221687 Meeting ID: 972 6122 1687 One tap mobile +13462487799,,97261221687# US (Houston) +16465588656,,97261221687# US (New York) Dial by your location +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) Meeting ID: 972 6122 1687 Find your local number: https://linaro-org.zoom.us/u/acg3UrpmdE -- Linaro-open-discussions mailing list https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions

5 years, 4 months

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Julius Werner

> >>. What I am worried about is mistakes and > >>oversights that slip through testing and then cause random or even > >>attacker-controllable crashes in production > > Why would this not be the case even with SCTLR.A bit set? I'm not seeing the relation between the crash and SCTLR.A bit. If there are oversights that slip through testing and an attacker can cause a crash, there is vulnerability/bug. > If there is something that slipped through, that causes a data abort(perhaps address not mapped in the translation tables), would we turn off the MMU ? Well, my assumption is that performing an unaligned access cannot be a vulnerability. If you have examples to the contrary please let me know, but as far as I am aware letting an unaligned access through should always work and will always result in the behavior the programmer intended (other than maybe contrived cases where device address space is mapped with a non-Device memory type, which is already very wrong for plenty of other reasons and should never happen). The only negative consequence is that the access may take slightly longer than if it were aligned. I do understand the desire to be able to shake out unaligned accesses during development and testing, but at least in a production build I think taking that performance hit would always be preferable to a crash. I don't think the comparison to a data abort works because obviously with a data abort the program usually can't just continue and still assume its internal state is valid.

5 years, 4 months

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Joanna Farley

Hi Julius, A lot of the rationale for the default initialization is not listed in the documentation and I do think perhaps we can do better as at the end of the day it’s decisions around platform ports and how they are going to be deployed in products that may influence decisions here for changing the defaults. Your thoughts around attacker control able crashes are a valid one. I don’t think any one setting is all pros with no cons and platform providers need to make decisions but I think the default code with the settings is more likely to flush out alignment bugs and although I don’t have specific examples any bug could play a part in future vulnerability so best to flush them out rather than lie hidden. It could be said that in the reference implementation a known crash may be better than a more nebulous unknown behaviour that could come with an undetected bug that could later be taken advantage of. The use a DEBUG flag is an idea but we have all seen debug builds not operating like production builds so the value may be lost here. It’s why on reviewing our documentation on seeing your post I think we could do better to explain the rationale for the settings in TF-A so platform owners can be better informed and override default settings if they really feel they have the need. Cheers Joanna ________________________________ From: Julius Werner Sent: Monday, November 9, 2020 10:42 PM To: Joanna Farley Cc: raghu.ncstate(a)icloud.com; tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Alignment fault checking in EL3 Hi Joanna, Thank you for your detailed response. I was mostly wondering if this was a deliberate choice or just something someone wrote this way once and nobody ever thought about again. Since it sounds like it is intentional, I'll try to understand your rationale better. > Maintaining these settings in production is also advised as best practice as it is known any such defects can possibly play a part in allowing an actor to take advantage of the defect as part of a vulnerability and memory related defects in particular can be taken advantage of. So it seems prudent to guard against them. I'm curious, can you elaborate on that? I can't really think of a scenario where lack of alignment checking can really make code behave in an unintentional way. (I don't think Raghu's scenario of accessing MMIO registers works because those registers should be mapped with a Device memory type anyway, and that memory type enforces aligned accesses regardless of the SCTLR.A flag.) If there truly are security concerns with this I can understand your approach much better. > Saying all this for those few cases where unaligned accesses are correct and intentional we could look to define better ways to handle these and provide that in reference code as an option to try and get the best for robustness and debuggability which seemed a big part of the concern in your post. Team members in Arm have ideas on how that could be provided but it needs broader discussion on the implications for security and performance before taking forward. There are scenarios where unaligned accesses can be intentional, but I am not too worried about those -- there are ways to work around that, and if we make it policy that those accesses always need to be written that way I'm okay with that. What I am worried about is mistakes and oversights that slip through testing and then cause random or even attacker-controllable crashes in production. If the main reason you're enabling this flag is to help with early detection of coding mistakes, I wonder if the best approach would be to enable it for DEBUG=1 and disable it for DEBUG=0 (of course, if there are really security issues associated with it like you mentioned above, that wouldn't make sense).

5 years, 4 months

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Joanna Farley

Hi Julius, Talking to the team here its has always been felt it is best practise to forbid unaligned data accesses in Arm's embedded projects. That's the reason TF-A also enforces the build options: -mno-unaligned-access (AArch32) and -mstrict-align (AArch64). In the TF-A documentation [1] SCTLR_EL3.A and other settings are listed in the Architectural Initialisation section. There is thought to be only a few cases where unaligned access are correct and intentional and most are defects that should be caught early and not in production and as such it is better to detect unaligned data access conditions early in a platform porting, rather than in the field especially if there is no firmware update capability. Alignment faults should be treated as fatal as they should never happen in production when components have been designed as such from the beginning. Maintaining these settings in production is also advised as best practice as it is known any such defects can possibly play a part in allowing an actor to take advantage of the defect as part of a vulnerability and memory related defects in particular can be taken advantage of. So it seems prudent to guard against them. We can of course provide better rationalisation based on the above in our documentation to provide platforms porting efforts better guidance. It is after all up to partners in their platform ports to make appropriate decisions for their ports where settings could be changed however the upstreamed reference code should follow the settings we have which are felt to be best practices for TF-A. It is known other projects follow other practices and that is fine if that works for them. Once a project enables unaligned accesses, it's very hard to go back again since it's likely that code that does unaligned accesses will slowly get added to the project. However for TF-A maintaining the current settings is felt to be the best approach when weighing up the costs and benefits. Saying all this for those few cases where unaligned accesses are correct and intentional we could look to define better ways to handle these and provide that in reference code as an option to try and get the best for robustness and debuggability which seemed a big part of the concern in your post. Team members in Arm have ideas on how that could be provided but it needs broader discussion on the implications for security and performance before taking forward. Thanks Joanna [1] https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.h… On 09/11/2020, 17:47, "TF-A on behalf of Raghu Krishnamurthy via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Julius, I tend to agree with your argument about not using SCTLR.A bit but I think the unexpected crashes or instability is due buggy code and insufficient validation of invariants such as aligned pointers, irrespective of whether SCTRLR.A is set or unset. Even if we allow unaligned accesses, we could have buggy code that access registers that typically have to be size aligned and we wouldn’t catch those bugs with SCTLR.A. Worse, some hardware implementations have undefined/impdef behavior when there are unaligned access to MMIO registers for ex, in which case, I would rather take an alignment fault at the core than allow triggering of undefined behavior. So I don’t think stability/reliability and the use of SCTLR.A bit are related. If TF-A's position is that we want to allow only aligned accesses in EL3(for whatever reason, I can only think of efficiency), it is the code's responsibility to enforce this invariants using asserts or explicit checks. >> I am still wondering why we choose to set the SCTLR_EL3.A I think this is the relevant question. If there are good security reasons(which I don’t know about), I would say we should keep it. If it is for efficiency, given the way recent ARM64 cores are performing, I wouldn't have a problem with SCTLR.A=0. Thanks Raghu -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TF-A Sent: Friday, November 6, 2020 6:38 PM To: tf-a <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Alignment fault checking in EL3 Hi, I just debugged a TF-A boot crash that turned out to be caused by an alignment fault in platform code. Someone had defined some static storage space as a uint8_t array, and then accessed it by dereferencing uint16_t pointers. Of course this is ultimately a bug in the platform code that should be fixed, but I am still wondering why we choose to set the SCTLR_EL3.A (Alignment fault checking) flag in TF-A? In an ideal world, maybe we could say that code which can generate alignment faults should not exist -- but, unfortunately, people make mistakes, and this kind of mistake may linger unnoticed for a long time in the codebase before randomly getting triggered due to subtle shifts in the binary's memory layout. (Worse, in some situations this could get affected by SMC parameters passed in from lower exception levels, so it would only be noticeable and could possibly be intentionally triggered if the lower exception level passes in just the right values.) For that reason, most other environments I know (e.g. Linux) always keep that flag cleared. There's no harm in that -- as far as I'm aware all aarch64 cores are required to support unaligned accesses to cached memory types, and the worst that would happen is a slight performance penalty for the access. I think that flag is mostly meant as a debugging feature to be able to shake out accidental unaligned accesses from your code? If our goal is to be stable and reliable firmware, shouldn't we disable it to reduce the chance of unexpected crashes? -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 4 months

3
2
0 0

Re: [TF-A] Alignment fault checking in EL3

by raghu.ncstate＠icloud.com

Hi Julius, I tend to agree with your argument about not using SCTLR.A bit but I think the unexpected crashes or instability is due buggy code and insufficient validation of invariants such as aligned pointers, irrespective of whether SCTRLR.A is set or unset. Even if we allow unaligned accesses, we could have buggy code that access registers that typically have to be size aligned and we wouldn’t catch those bugs with SCTLR.A. Worse, some hardware implementations have undefined/impdef behavior when there are unaligned access to MMIO registers for ex, in which case, I would rather take an alignment fault at the core than allow triggering of undefined behavior. So I don’t think stability/reliability and the use of SCTLR.A bit are related. If TF-A's position is that we want to allow only aligned accesses in EL3(for whatever reason, I can only think of efficiency), it is the code's responsibility to enforce this invariants using asserts or explicit checks. >> I am still wondering why we choose to set the SCTLR_EL3.A I think this is the relevant question. If there are good security reasons(which I don’t know about), I would say we should keep it. If it is for efficiency, given the way recent ARM64 cores are performing, I wouldn't have a problem with SCTLR.A=0. Thanks Raghu -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TF-A Sent: Friday, November 6, 2020 6:38 PM To: tf-a <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Alignment fault checking in EL3 Hi, I just debugged a TF-A boot crash that turned out to be caused by an alignment fault in platform code. Someone had defined some static storage space as a uint8_t array, and then accessed it by dereferencing uint16_t pointers. Of course this is ultimately a bug in the platform code that should be fixed, but I am still wondering why we choose to set the SCTLR_EL3.A (Alignment fault checking) flag in TF-A? In an ideal world, maybe we could say that code which can generate alignment faults should not exist -- but, unfortunately, people make mistakes, and this kind of mistake may linger unnoticed for a long time in the codebase before randomly getting triggered due to subtle shifts in the binary's memory layout. (Worse, in some situations this could get affected by SMC parameters passed in from lower exception levels, so it would only be noticeable and could possibly be intentionally triggered if the lower exception level passes in just the right values.) For that reason, most other environments I know (e.g. Linux) always keep that flag cleared. There's no harm in that -- as far as I'm aware all aarch64 cores are required to support unaligned accesses to cached memory types, and the worst that would happen is a slight performance penalty for the access. I think that flag is mostly meant as a debugging feature to be able to shake out accidental unaligned accesses from your code? If our goal is to be stable and reliable firmware, shouldn't we disable it to reduce the chance of unexpected crashes?

5 years, 4 months

1
0
0 0

Alignment fault checking in EL3

by Julius Werner

Hi, I just debugged a TF-A boot crash that turned out to be caused by an alignment fault in platform code. Someone had defined some static storage space as a uint8_t array, and then accessed it by dereferencing uint16_t pointers. Of course this is ultimately a bug in the platform code that should be fixed, but I am still wondering why we choose to set the SCTLR_EL3.A (Alignment fault checking) flag in TF-A? In an ideal world, maybe we could say that code which can generate alignment faults should not exist -- but, unfortunately, people make mistakes, and this kind of mistake may linger unnoticed for a long time in the codebase before randomly getting triggered due to subtle shifts in the binary's memory layout. (Worse, in some situations this could get affected by SMC parameters passed in from lower exception levels, so it would only be noticeable and could possibly be intentionally triggered if the lower exception level passes in just the right values.) For that reason, most other environments I know (e.g. Linux) always keep that flag cleared. There's no harm in that -- as far as I'm aware all aarch64 cores are required to support unaligned accesses to cached memory types, and the worst that would happen is a slight performance penalty for the access. I think that flag is mostly meant as a debugging feature to be able to shake out accidental unaligned accesses from your code? If our goal is to be stable and reliable firmware, shouldn't we disable it to reduce the chance of unexpected crashes?

5 years, 4 months

1
0
0 0

[RFC PATCH] hw/arm/virt: use sbsa-ec for reboot and poweroff in secure mode

by Maxim Uvarov

If we're emulating EL3 then the EL3 guest firmware is responsible for providing the PSCI ABI, including reboot, core power down, etc. sbsa-ref machine has an embedded controller to do reboot, poweroff. Machine virt,secure=on can reuse this code to do reboot inside ATF. Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org> --- Hello, This patch implements reboot for the secure machine inside ATF firmware. I.e. current qemu patch should be used with [1] ATF patch. It looks like that Embedded Controller qemu driver (sbsa-ec) can be common and widely used for other emulated machines. While if there are plans to extend sbsa-ec then we might find some other solution. So for the long term it looks like machine virt was used as an initial playground for secure firmware. While the original intent was a runner for kvm guests. Relation between kvm guest and firmware is not very clear now. If everyone agree it might be good solution to move secure firmware things from virt machine to bsa-ref and make this machine reference for secure boot, firmware updates etc. [1] https://github.com/muvarov/arm-trusted-firmware/commit/6d3339a0081f6f2b45d9… Best regards, Maxim. hw/arm/virt.c | 9 +++++++++ include/hw/arm/virt.h | 2 ++ 2 files changed, 11 insertions(+) diff --git a/hw/arm/virt.c b/hw/arm/virt.c index e465a988d6..6b77912f02 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -152,6 +152,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_ACPI_GED] = { 0x09080000, ACPI_GED_EVT_SEL_LEN }, [VIRT_NVDIMM_ACPI] = { 0x09090000, NVDIMM_ACPI_IO_LEN}, [VIRT_PVTIME] = { 0x090a0000, 0x00010000 }, + [VIRT_EC] = { 0x090c0000, 0x00001000 }, [VIRT_MMIO] = { 0x0a000000, 0x00000200 }, /* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that size */ [VIRT_PLATFORM_BUS] = { 0x0c000000, 0x02000000 }, @@ -1729,6 +1730,13 @@ static void virt_cpu_post_init(VirtMachineState *vms, int max_cpus, } } +static void init_ec_controller(VirtMachineState *vms) +{ + vms->ec = qdev_new("sbsa-ec"); + + sysbus_mmio_map(SYS_BUS_DEVICE(vms->ec), 0, vms->memmap[VIRT_EC].base); +} + static void machvirt_init(MachineState *machine) { VirtMachineState *vms = VIRT_MACHINE(machine); @@ -1797,6 +1805,7 @@ static void machvirt_init(MachineState *machine) */ if (vms->secure && firmware_loaded) { vms->psci_conduit = QEMU_PSCI_CONDUIT_DISABLED; + init_ec_controller(vms); } else if (vms->virt) { vms->psci_conduit = QEMU_PSCI_CONDUIT_SMC; } else { diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index aad6d69841..6f2ce4e4ff 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -85,6 +85,7 @@ enum { VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, VIRT_PVTIME, + VIRT_EC, VIRT_LOWMEMMAP_LAST, }; @@ -163,6 +164,7 @@ struct VirtMachineState { DeviceState *gic; DeviceState *acpi_dev; Notifier powerdown_notifier; + DeviceState *ec; }; #define VIRT_ECAM_ID(high) (high ? VIRT_HIGH_PCIE_ECAM : VIRT_PCIE_ECAM) -- 2.17.1

5 years, 4 months

5
7
0 0

TF-A Tech Forum Agenda @ Thr 5th November 2020 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 5th November 2020 16:00 – 17:00 (GMT). Please note UK entered Daylight Saving on 25th October when clocks went back one hour to go to GMT from 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: * TF-A Tests Framework Overview * Presented by Varun Wadekar * Summary * Trusted Firmware-A Tests (TF-A Tests) is a suite of baremetal tests to exercise the Trusted Firmware-A (TF-A) features from the Normal World. * 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

5 years, 4 months

1
0
0 0

Mbed TLS Virtual Workshop Tomorrow

by Shebu Varghese Kuriakose

Hi All, Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT. See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/ Thanks, Shebu -----Original Appointment----- From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com> Sent: Friday, October 23, 2020 12:32 AM To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org; Don Harbin; psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman Subject: Mbed TLS Virtual Workshop When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London. Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… You have been invited to the following event. Mbed TLS Virtual Workshop When Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix Where Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>) Calendar shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> Who • Don Harbin - creator • shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> • mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> • psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org> • dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com> more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Hi, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration Here is the agenda for the workshop. Topic Time (in GMT) Welcome 2.00 - 2.10pm Constant-time code 2.10 – 2.30pm Processes - how does work get scheduled? 2.30 – 2.50pm PSA Crypto APIs 2.50 – 3.20pm PSA Crypto for Silicon Labs Wireless MCUs - Why, What, Where and When 3.20 – 3.50pm Break Roadmap, TLS1.3 Update 4.10 – 4.30pm Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm How do I contribute my first review and be an effective Mbed TLS reviewer 5.00 – 5.30pm Regards, Don Harbin Trusted Firmware Community Manager ==============Zoom details below:==================== Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: Mbed TLS Virtual Workshop Time: Nov 3, 2020 02:00 PM Greenwich Mean Time Join Zoom Meeting https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…> Meeting ID: 953 1520 0315 Passcode: 143755 One tap mobile +16699009128,,95315200315# US (San Jose) +12532158782,,95315200315# US (Tacoma) Dial by your location +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 953 1520 0315 Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…> Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.

5 years, 4 months

1
0
0 0

Re: [TF-A] Questions raised about Measured Boot + fTPM test case

by Ruchika Gupta

Hi, *For [1] - Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood.* You can check the implementation at https://github.com/microsoft/MSRSec This compiles for aarch64. I had a few queries for chips having physical TPM. Case 1. Should all entities doing the measurement (BL1, BL2) have the TPM driver to extend the measurements as they are done. This would be the most secure flow. Case 2. If BL1 and BL2 don't have the TPM driver as mentioned in Case 1 above, who would be responsible for extending the measurements for secure world entities. -- Should there be a TPM driver in Secure EL0/EL1 which does this ? -- Event log is also passed to the BL33. In case there is no TPM driver at all in the secure world - is it expected that BL33 should extend the measurements in PCR ? Regards, Ruchika On Mon, 26 Oct 2020 at 21:03, Stuart Yoder via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Regarding measuring TB_FW_CONFIG-- > > BL1 could measure the unmodified TB_FW_CONFIG image as it was loaded from > flash. It could then update TB_FW_CONFIG with that measurement which > reflects the image as it was on flash. This could allow detection of > tampering with flash. I would recommend doing this, as TB_FW_CONFIG is > critical data. > > BL2 could make a measurement of the TB_FW_CONFIG image as it was passed to > it in memory. > > Thanks, > Stuart > > > On 10/26/20 6:16 AM, Alexei Fedorov wrote: > > Hi Javer, > > Please see my comments below. > > [3] Provide platform hooks in tpm_record_measurement function for a > platform to actually extend those measurements to a physical TPM right when > they are measured. > > These hooks can be implemented in the next phase #2 of Measured Boot > implementation. > > [4] On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should > also be measured since they are images being loaded as well. See > arm_bl1_setup.c where these images are loaded but not measured(unless I’m > missing something). > > FW_CONFIG and TB_FW_CONFIG images are loaded by BL1 but not BL2. > BL1 calculates BL2 hash and passes the measurement to BL2 in TB_FW_CONFIG. > It can also pass FW_CONFIG hash in the same DTB, but it is not clear how > own TB_FW_CONFIG hash can be passed in itself. > > Stuart, do you have opinion on that? > > Regards. > > Alexei > ------------------------------ > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> > <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Javier Almansa > Sobrino via TF-A <tf-a(a)lists.trustedfirmware.org> > <tf-a(a)lists.trustedfirmware.org> > *Sent:* 26 October 2020 10:25 > *To:* raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> > <raghu.ncstate(a)icloud.com> > *Cc:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > <tf-a(a)lists.trustedfirmware.org> > *Subject:* Re: [TF-A] Questions raised about Measured Boot + fTPM test > case > > Hi Raghu, > > Thank you very much for your comments and for your feedback. > > With regards to the (f)TPM service and as discussed during the last TF-A > Tech Forum call, we will discuss internally the need of a new > implementation, probably after the next TF-A release, and we will schedule > the work (in case we decide to go ahead with it) for the upcoming months. > We will announce any decision we make through the mailing list and/or on > future TF-A Tech Forum calls . > > Regarding to changes to TF-A to include extra functionality/APIs/hooks, I > guess my colleague Alexei can provide further details about the next > features planned for Measured Boot, if any. > > To finish, I would just like to clarify one of the questions raised on > your email: > > [1] Would be good if the test infrastructure(the TPM TA) can compile in > AARCH64. I thought I heard on the tf-a call that there already is a > Microsoft FW TPM port for aarch64 already. Please let me know if I > misunderstood. > > > - Microsoft has a reference implementation of the TPM 2.0 > specification. That implementation is in the form of an architecture > agnostic library that implements the specification. Along with the library, > there are a couple of example applications for different platforms built > around the former, one of them being the fTPM we used for testing. That > application was written for AARCH32 and seemed to be outdated (I don't know > if it was abandoned, actually), so we updated it and added support for > Measured Boot to it. > > > Best regards, > Javier > > -----Original Message----- > *From*: raghu.ncstate(a)icloud.com > *To*: 'Javier Almansa Sobrino' <Javier.AlmansaSobrino(a)arm.com > <'Javier%20Almansa%20Sobrino'%20%3cJavier.AlmansaSobrino(a)arm.com%3e>> > *Cc*: tf-a(a)lists.trustedfirmware.org > *Subject*: RE: [TF-A] Questions raised about Measured Boot + fTPM test > case > *Date*: Sun, 25 Oct 2020 14:31:10 -0700 > > Hi Javier, > > > > As discussed during the TF-A call, here are some suggestions/feedback that > can be incorporated when time permits based on priorities, schedule, > resources etc: > > 1. Would be good if the test infrastructure(the TPM TA) can compile in > AARCH64. I thought I heard on the tf-a call that there already is a > Microsoft FW TPM port for aarch64 already. Please let me know if I > misunderstood. > 2. Would be good if the TPM TA works on FF-A as opposed to proprietary > OPTEE API’s. > 3. Provide platform hooks in tpm_record_measurement function for a > platform to actually extend those measurements to a physical TPM right when > they are measured. This is a requirement from a security perspective to not > wait until the tpm TA is loaded to be able to extend the measurements into > a tpm. I understand this can be done in the platform hook that calls > tpm_record_measurement but it is convenient place to put tpm related > platform hooks. > 4. On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should > also be measured since they are images being loaded as well. See > arm_bl1_setup.c where these images are loaded but not measured(unless I’m > missing something). > > > > Thanks > > Raghu > > > > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> > <tf-a-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Javier Almansa > Sobrino via TF-A > *Sent:* Friday, October 9, 2020 10:51 AM > *To:* tf-a(a)lists.trustedfirmware.org > *Subject:* [TF-A] Questions raised about Measured Boot + fTPM test case > > > > Hello all, > > > > Following up the question raised yesterday during the TF-A Tech Forum with > regards to any modification needed on the Linux Kernel to run the test case > that I was presenting (Measured Boot + fTPM service), I double checked > today and I ran some tests on system and I can confirm that the test case > works with the mainline Linux Kernel, with no modification other than > enabling the driver on the DTB. > > > > The modules involved on the interaction with the fTPM (for this particular > example) are: > > > > * optee.ko: Allows communication between the REE (unsecure world), the > Trusted OS (secure world) and the tee-supplicant (unsecure world). > > * tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a > char device. This also includes the reference implementation used on the > test case. > > > > In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 > TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM. > > > > I would also like to highlight the following points: > > > > A) The test case is only meant to test the ability of the Measured Boot > Driver and a TPM 2.0 compliant device to interact with each other. As such, > we are not providing an fTPM meant to be used on a production environment. > Instead, we are using an existing reference implementation to which we > added support for Measured Boot to fulfil our needs for the test and use it > as a functional example. The implementation details on how to interact with > a particular TPM device (either firmware or discrete) can differ from the > ones used on the test case as those details can be platform dependent. For > example, we use an OPTEE TA fTPM on this example, but other platforms might > use a discrete TPM or an fTPM running on a different Trusted OS. > > > > B) As stated on the presentation, we are undergoing internal review of the > contributions done for the fTPM service to make it compatible with Measured > Boot. Once the review is completed and the changes merged into the TPM repo > mainline, we will update the TF-A documentation with instructions on how to > download and build all the components to run the tests manually. > > > > Please, let me know in case you have any more questions. > > > > Best regards, > > Javier > > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

5 years, 4 months

3
2
0 0

Re: [TF-A] [Linaro-open-discussions] Extend TF-A with PSCI OS-initiated mode

by Matteo Carlini

Cross-posting to the TF-A mailing list as well for interested partners. > -----Original Message----- > From: Linaro-open-discussions <linaro-open-discussions-bounces@op- > lists.linaro.org> On Behalf Of Ulf Hansson via Linaro-open-discussions > Sent: 28 October 2020 15:45 > To: linaro-open-discussions(a)op-lists.linaro.org > Cc: Lauren Wehrmeister <Lauren.Wehrmeister(a)arm.com>; Lina Iyer > <ilina(a)codeaurora.org>; Dan Handley <Dan.Handley(a)arm.com>; Madhukar > Pappireddy <Madhukar.Pappireddy(a)arm.com>; Bhutada Harshad > <hbhutada(a)qti.qualcomm.com>; Gabriel FERNANDEZ > <gabriel.fernandez(a)st.com> > Subject: [Linaro-open-discussions] Extend TF-A with PSCI OS-initiated mode > > Hi all, > > In the Linux kernel v5.6, we introduced the basic support for PSCI OS-initiated > mode. Linaro is still working on evolving the support, step by step. > Additionally, we are helping some of our members with corresponding SoC > deployment, which is planned to continue for a while. > > Basically, the PSCI OS-initiated mode allows Linux to be in charge of idlestate > decisions for a group of CPUs (aka CPU cluster), which may share idlestates. > In some cases this enables improvements in regards to performance/energy, > but could also be used to help manage resources that may share power- > /clock-domains with CPUs. > > Moving forward, we are now planning to extend the corresponding PSCI > implementation in the Trusted Firmware-A (TF-A) with the OS-initiated mode, > together with our members and member engineers. Currently, only the > default PSCI platform-coordinated mode is supported by the TF-A. > > We seek for additional collaborations and input to the new project! > Please get in touch, if you have any feedback and/or find this project > interesting. > > Finally, a kickoff meeting is about to be scheduled and held within a few > weeks. Let me know if you want to join the discussions. > > Kind regards > Ulf Hansson, Linaro Kernel Working Group > -- > Linaro-open-discussions mailing list > https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home > https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions

5 years, 4 months

1
0
0 0

Re: [TF-A] BL31 as bootloader

by rkohli2000 gmail

Hi Alexei, I'm able to eliminate the warning using the -j .text and see the image load and run ok. The issue I am seeing is that the bsp I am using expects my bot loader bl31.bin to power on the UART and do the low level init that makes PCIe controller accessible. I think at exit from bl31.bin I don't have this initialization. Can you point me the TFA code to enable LPUART and make PCIe controller accessible in imx8qm before handoff to BL33 ? Regards Ravi > On Oct 28, 2020, at 11:33 AM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Alexei, Thanks for the hint. Yes, my App.bin image has a bunch of header info > and that's the root cause of the undef ARM instructions. I grabbed a pure ELF image > I built using the integrity compiler and see the following warning on trying to convert ELF to > raw binary on linux. The conversion is not permitted. Do I need some flags ? > > Regards > Ravi > > ravi:~/imx8qm/gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin$ ./aarch64-none-elf-readelf -h ~/imx8qm/imx-mkimage/iMX8QM/example_app.elf > ELF Header: > Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 > Class: ELF64 > Data: 2's complement, little endian > Version: 1 (current) > OS/ABI: UNIX - System V > ABI Version: 0 > Type: EXEC (Executable file) > Machine: AArch64 > Version: 0x1 > Entry point address: 0xffffff8080200000 > Start of program headers: 64 (bytes into file) > Start of section headers: 866208 (bytes into file) > Flags: 0x0 > Size of this header: 64 (bytes) > Size of program headers: 56 (bytes) > Number of program headers: 49 > Size of section headers: 64 (bytes) > Number of section headers: 78 > Section header string table index: 77 > > ravi:~/imx8qm/gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin$ ./aarch64-none-elf-objcopy -O binary ~/imx8qm/imx-mkimage/iMX8QM/example_app.elf ~/imx8qm/imx-mkimage/iMX8QM/dummy.bin > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.text' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.rodata' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.rodata' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.data' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.boottable' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.secinfo' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy:/home/ravi/imx8qm/imx-mkimage/iMX8QM/dummy.bin[.example_virtual.text]: file truncated > > > > > > On Wed, Oct 28, 2020 at 10:09 AM Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > Hi Ravi, > > Is App.bin generated by the tool you use is a "pure" binary or contains some extra entries at the start of the image (e.g. 0x7F 0x45 0x4C 0x46 = "ELF" )? > This might also help: > https://stackoverflow.com/questions/49814470/u-boot-how-to-run-a-standalone… <https://stackoverflow.com/questions/49814470/u-boot-how-to-run-a-standalone…> > > Alexei > From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > Sent: 27 October 2020 22:03 > To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > Subject: Re: [TF-A] BL31 as bootloader > > Hi Alexei, > No, we don't see the same behavior when launching our hello world app (using Integrity178 rtos) > from U-boot. The only change uboot needed was related to size of the image (i don't have specifics about this change). > But, the hello app runs fine from U-boot printing normally on the imx8qm MEK board. > > I don't see this test app write to the UART launching from bl31.bin at 0x80020000. I can see the > handoff is successful setting a breakpoint at 0x80020000 from my Lauterbach debugger probe. > > The test app is prepared using the GHS tools (elf to bin) using gmemfile.exe and then uboot's mkimage > command: mkimage -A arm64 -O u-boot -T kernel -C none -a 0x80200000 -e 0x80200000 -n "INTEG" -d tmp.bin App.bin. > This generates the App.bin that tftpboots boots fine from any given address on my board. This very same image > does not work booting from bl31.bin. > > Can you suggest what could be going on ? > > Regards > Ravi > > > > > > On Oct 27, 2020, at 8:34 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > > > > Hi Ravi, > > > > It is good to know that you have some progress with your problem. > > > > "I'm seeing some undef instruction, etc, etc." > > Do you see the same behaviour when launching BL33 from U-Boot? > > > > Regards. > > Alexei > > From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > > Sent: 26 October 2020 20:23 > > To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > > Subject: Re: [TF-A] BL31 as bootloader > > > > Hi Alexei, Manish, > > > > I had some better luck with my debugger this time. I can see > > the handoff from bl31.bin (imx-atf) to BL33 entry point (0x80020000) > > in my debugger now. > > > > The problem was in setting up the debugger properly which was > > preventing me from seeing the breakpoint. My bad. > > > > Now, I can see the handoff and execution of instruction of the > > test app. This app is an integrity178 app and I'm seeing some undef > > instruction, etc, etc. Likely specific to the rtos we are using for this app. > > So, I will follow up on that end. Thanks for your debug support and > > helping me experiment with TFA for our product. > > > > Regards > > Ravi > > > > > >> On Oct 26, 2020, at 4:44 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >> > >> Hi Ravi > >> > >> As you can see in debugger that memory at 0x80020000 address is populated correctly, can you set a breakpoint at it to check if execuion reaches it? If you cannot set a breakpoint I would suggest to add a few assembler instructions in the start of your BL33 entry point to write any specific character, e.g. '!' to debug UART data port and branch to the next instruction in an infinite loop with "b .". Seeing ! char on debug console would prove that control to BL33 image has been passed. > >> > >> Regards. > >> Alexei > >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >> Sent: 24 October 2020 22:48 > >> To: Ravi Kohli <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >> Subject: Re: [TF-A] BL31 as bootloader > >> > >> Hi Alexei, Manish, > >> > >> I instrumented the imx8QM platform code and saw normal execution with bl31_main() > >> exiting normally with entry point for my BL33 image. But, I haven't seen the handoff > >> work yet. Can you suggest what else I can try to debug this ? I have an image copied > >> at 0x80020000 from what I can see in the debugger. Thanks in advance. > >> > >> Regards > >> Ravi > >> > >> > >> > >> > >> On Fri, Oct 23, 2020 at 3:43 PM rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> wrote: > >> Hi Manish, > >> > >> I have been able to copy the test app (BL33) to entry point address 0x80020000. > >> I confirmed from the Debugger that RAM address 0x80020000 is populated. I had to modify imx-atf > >> makefile target to use the "-data" option as follows: > >> flash_test_8: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb > >> ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -data App.bin 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > >> The -data option appears to copy the image at the 0x80020000 address. Now, I think we should > >> be able to handoff since PC (program counter) is set : > >> bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); > >> > >> I don't see any serial console output using an image that works when using u-boot. I am not using > >> u-boot for certification reasons. Is there some way I can confirm that the handoff is happening from bl31.bin to > >> the App.bin ? At which BL31 function or module does the handoff occur ? > >> > >> I don't see my HW breakpoint trigger at location location 0x80020000. > >> > >> Regards > >> Ravi > >> > >>> On Oct 23, 2020, at 9:25 AM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: > >>> > >>> Hi Manish, > >>> > >>> Can you please point me to any example or a BL2 module which does the copy to RAM from Flash ? > >>> Maybe I can try to copy the image to 0x80020000 before exiting BL31 from bl31_main(). > >>> > >>> The bl31.bin image boot fine on the target board (imx8qm) from location 0x80000000 > >>> to start with. That copy to 0x80000000 must happen as well. I'm not sure where assuming > >>> its some NXP firmware doing it. Do you know where it could be ? > >>> > >>> Regards > >>> Ravi > >>> > >>> > >>>> On Oct 23, 2020, at 4:46 AM, Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: > >>>> > >>>> Hi Ravi, > >>>> > >>>> This is normal behaviour when you RESET_TO_BL31. > >>>> The loading of images (from flash to RAM) is part of BL2 code and in case of directly jumping to BL31, you need a mechanism to Load these images at proper location. > >>>> Some platforms have a separate firmware which does this before starting execution of BL31, so that when BL31 hands over to BL33 it gets valid image there. > >>>> > >>>> thanks > >>>> Manish > >>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>> Sent: 23 October 2020 05:08 > >>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>>; Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> > >>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>> Subject: Re: [TF-A] BL31 as bootloader > >>>> > >>>> Hi Alexei, Manish, > >>>> > >>>> I repeated the test (below) a few times and see the same result. > >>>> > >>>> (1) Do I need to copy my BL33 (non-secure) image from > >>>> flash.bin some how to RAM 0x80020000 entry point address ? > >>>> Is there any example of how to copy the flash.bin image ? I not sure > >>>> what address or where to copy it from. > >>>> > >>>> (2) Is there some existing debug code that I can use > >>>> to dump/print the ARMv8 RAM address space from inside > >>>> BL31.bin ? > >>>> > >>>> I only found some TF-A tf_log macros in debug.h. > >>>> I would like to dump some memory address contents > >>>> (like 0x80020000) from inside bl31.bin to console just for > >>>> debugging at run-time. > >>>> > >>>>> On Oct 22, 2020, at 4:28 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: > >>>>> > >>>>> Hi Alexei, > >>>>> > >>>>> I captured the LOG_LEVEL=50 log (attached putty-ser0.log) from TF-A bl31.bin. > >>>>> I see bl31 boots normally but never hands off to the BL33 normal world image (App.bin) > >>>>> > >>>>> The flash.bin image I am running is constructed using imx-mkimage tool with the following target: > >>>>>> flash_test_7: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb > >>>>>> ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -p3 -ap App.bin a53 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > >>>>> > >>>>> I used UUU tool to flash eMMC with flash.bin on the imx8QM MEK board. > >>>>> > >>>>> I inspected RAM using a trace32 debugger SW after using a while (1) to halt the execution at the end of bl31.bin main function (bl31_main()). > >>>>>> diff --git a/bl31/bl31_main.c b/bl31/bl31_main.c > >>>>>> index 92a2027dd..51afb13ea 100644 > >>>>>> --- a/bl31/bl31_main.c > >>>>>> > >>>>>> +++ b/bl31/bl31_main.c > >>>>>> @@ -147,6 +147,11 @@ void bl31_main(void) > >>>>>> * from BL31 > >>>>>> */ > >>>>>> bl31_plat_runtime_setup(); > >>>>>> + > >>>>>> + INFO("BL31: leaving bl31_main\n"); > >>>>>> + INFO("entering while(1)\n"); > >>>>>> + > >>>>>> + while (1) {}; > >>>>>> } > >>>>> It appears that there's no data or image at 0x80020000 just before exiting bl31_main(). See the debugger RAM dump at > >>>>> address 0x80000000 (bl31.bin entry point) and 0x80020000 (BL33 or App.bin normal world app entry point). > >>>>> See the debugger output. > >>>>> > >>>>> When should the flash image provided in flash.bin get copied to the RAM entry point 0x80020000 ? Should bl31.bin > >>>>> copy the image from flash to RAM ? > >>>>> > >>>>> Can you suggest what could be going on ? > >>>>> > >>>>> Regards > >>>>> Ravi > >>>>> > >>>>> > >>>>> > >>>>>> On Oct 22, 2020, at 6:15 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>> > >>>>>> Hi Ravi, > >>>>>> > >>>>>> TFTF image can be built from https://git.trustedfirmware.org/TF-A/tf-a-tests.git <https://git.trustedfirmware.org/TF-A/tf-a-tests.git> > >>>>>> > >>>>>> You can also try to increase TF-A log level by setting LOG_LEVEL=50 and check if BL33 memory region is mapped correctly. > >>>>>> Before passing control to BL33 and could add code to dump initial memory at BL33 start address to see if the image was loaded with no issues. > >>>>>> > >>>>>> Regards. > >>>>>> Alexei > >>>>>> > >>>>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>>>> Sent: 21 October 2020 19:59 > >>>>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > >>>>>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>> > >>>>>> Alexei, > >>>>>> > >>>>>> I don't have a DS-5 debugger setup/licensed. I am hoping > >>>>>> on getting something shortly. > >>>>>> > >>>>>> Can you point me to the TFTF image that I can use to > >>>>>> test the BL33 handoff ? > >>>>>> > >>>>>> Sorry, I'm not familiar at this time. > >>>>>> > >>>>>> Regards > >>>>>> Ravi > >>>>>> > >>>>>> > >>>>>>> On Oct 21, 2020, at 12:35 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>>> > >>>>>>> You can also use TFTF image as BL33. > >>>>>>> > >>>>>>> Alexei > >>>>>>> > >>>>>>> From: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> > >>>>>>> Sent: 21 October 2020 15:26 > >>>>>>> To: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > >>>>>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>>> > >>>>>>> The best way to figure out whether handing off to BL33 happened or not is by attaching a debugger(DS-5). > >>>>>>> > >>>>>>> is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? > >>>>>>> - You can use a linux image and device tree to test it > >>>>>>> Refer to plat/brcm/common/brcm_bl31_setup.c -> "brcm_bl31_early_platform_setup()" function > >>>>>>> For linux as BL33 payload please use coder under "ARM_LINUX_KERNEL_AS_BL33" > >>>>>>> > >>>>>>> > >>>>>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>>>>> Sent: 21 October 2020 12:12 > >>>>>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > >>>>>>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>>> > >>>>>>> Hi Alexei, Manish, > >>>>>>> > >>>>>>> I tried the following patch to plat/imx/imx8qm/imx8qm_bl31_setup.c: > >>>>>>>> @@ -483,11 +486,15 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, > >>>>>>>> bl32_image_ep_info.args.arg3 = BL32_FDT_OVERLAY_ADDR; > >>>>>>>> #endif > >>>>>>>> #endif > >>>>>>>> + // DEBUG ONLY - FIXME > >>>>>>>> + SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); > >>>>>>>> + > >>>>>>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); > >>>>>>>> > >>>>>>>> /* init the first cluster's cci slave interface */ > >>>>>>>> cci_init(PLAT_CCI_BASE, imx8qm_cci_map, PLATFORM_CLUSTER_COUNT); > >>>>>>>> cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); > >>>>>>>> + > >>>>>>>> } > >>>>>>> But no luck. > >>>>>>> > >>>>>>> Is there some way to confirm my bl31.bin is handing off to any BL33 (normal world) test image ? > >>>>>>> In other words, is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? > >>>>>>>> > >>>>>>> Thanks. > >>>>>>> > >>>>>>> > >>>>>>>> On Oct 21, 2020, at 6:10 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>>>> > >>>>>>>> Hi Ravi, > >>>>>>>> > >>>>>>>> You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: > >>>>>>>> > >>>>>>>> /* Populate entry point information for BL33 */ > >>>>>>>> SET_PARAM_HEAD(&bl33_image_ep_info, > >>>>>>>> PARAM_EP, > >>>>>>>> VERSION_1, > >>>>>>>> 0); > >>>>>>>> /* > >>>>>>>> * Tell BL31 where the non-trusted software image > >>>>>>>> * is located and the entry state information > >>>>>>>> */ > >>>>>>>> bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); > >>>>>>>> > >>>>>>>> bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); > >>>>>>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); > >>>>>>>> > >>>>>>>> Regards. > >>>>>>>> Alexei > >>>>>>>> > >>>>>>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> Sent: 21 October 2020 10:57 > >>>>>>>> To: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> > >>>>>>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>>>> > >>>>>>>> Hi Manish, > >>>>>>>> > >>>>>>>> The test image should not have any dependency on device tree (dtb?) > >>>>>>>> for console init. > >>>>>>>> I used the NXP provided imx8qm-mek-ca53.dtb file which should match > >>>>>>>> the MEK board. > >>>>>>>> I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) > >>>>>>>> as well but no luck. > >>>>>>>> I don't believe PC is getting set to the 0x80020000 entry point. > >>>>>>>> > >>>>>>>> The test image has validated with u-boot using these tftpboot settings: > >>>>>>>> setenv ipaddr x.x.x.x > >>>>>>>> setenv serverip x.x.x.x > >>>>>>>> tftpboot 0xf0000000 App.bin > >>>>>>>> bootm 0xf0000000 > >>>>>>>> > >>>>>>>> I don't see any console output on the screen running it with bl31.bin as below. > >>>>>>>> Is there any debug I can add somewhere to help troubleshoot? > >>>>>>>> > >>>>>>>> Can you please provide me instructions on where to patch this missing code : > >>>>>>>> "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" > >>>>>>>> I can try it to see if any change in behavior. > >>>>>>>> > >>>>>>>> Thanks in advance. > >>>>>>>> Regards > >>>>>>>> Ravi > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: > >>>>>>>> > > >>>>>>>> > Hi Ravi, > >>>>>>>> > > >>>>>>>> > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. > >>>>>>>> > Also, does your "test image" depends on device tree for console initialization? > >>>>>>>> > > >>>>>>>> > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization > >>>>>>>> > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); > >>>>>>>> > > >>>>>>>> > thanks > >>>>>>>> > Manish > >>>>>>>> > > >>>>>>>> > ________________________________ > >>>>>>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Sent: 21 October 2020 00:10 > >>>>>>>> > To: Ravi Kohli <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>>>>>> > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Subject: Re: [TF-A] BL31 as bootloader > >>>>>>>> > > >>>>>>>> > Hi Alexei, > >>>>>>>> > > >>>>>>>> > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. > >>>>>>>> > > >>>>>>>> > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 > >>>>>>>> > > >>>>>>>> > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: > >>>>>>>> > > >>>>>>>> > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb > >>>>>>>> > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > >>>>>>>> > > >>>>>>>> > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). > >>>>>>>> > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. > >>>>>>>> > > >>>>>>>> > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff > >>>>>>>> > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff > >>>>>>>> > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff > >>>>>>>> > NOTICE: Memreg 6 0x80000000 -- 0xffffffff > >>>>>>>> > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff > >>>>>>>> > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff > >>>>>>>> > NOTICE: Non-secure Partitioning Succeeded > >>>>>>>> > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty > >>>>>>>> > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 > >>>>>>>> > INFO: bl31_platform_setup is called > >>>>>>>> > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 > >>>>>>>> > INFO: BL31: Initializing runtime services > >>>>>>>> > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > >>>>>>>> > INFO: BL31: Preparing for EL3 exit to normal world > >>>>>>>> > INFO: Entry point address = 0x80020000 > >>>>>>>> > INFO: SPSR = 0x3c9 > >>>>>>>> > INFO: BL31: DEBUG: image_type is: normal > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > Can anyone please suggest what could be the issue here that I don't see the test image console output ? > >>>>>>>> > Note, the same test image works fine using u-boot. > >>>>>>>> > > >>>>>>>> > Regards > >>>>>>>> > Ravi > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: > >>>>>>>> > > >>>>>>>> > Hi Alexei, > >>>>>>>> > > >>>>>>>> > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. > >>>>>>>> > I will try it out and confirm. And, thanks for this suggestion. > >>>>>>>> > > >>>>>>>> > Regards > >>>>>>>> > Ravi > >>>>>>>> > > >>>>>>>> > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>>>> > > >>>>>>>> > Hi Ravi, > >>>>>>>> > > >>>>>>>> > Have you tried to use RESET_TO_BL31 build option for your platform? > >>>>>>>> > > >>>>>>>> > Regards. > >>>>>>>> > Alexei > >>>>>>>> > ________________________________ > >>>>>>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Sent: 07 October 2020 17:01 > >>>>>>>> > To: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Subject: [TF-A] BL31 as bootloader > >>>>>>>> > > >>>>>>>> > Hi, > >>>>>>>> > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. > >>>>>>>> > > >>>>>>>> > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. > >>>>>>>> > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can > >>>>>>>> > specify this container image with both bl31.bin and a separate custom app at a give flash address. > >>>>>>>> > This is without any security requirements or dependencies. > >>>>>>>> > > >>>>>>>> > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch > >>>>>>>> > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point > >>>>>>>> > 0x80020000 address ? > >>>>>>>> > > >>>>>>>> > Thanks in advance. > >>>>>>>> > Ravi > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > -- > >>>>>>>> > TF-A mailing list > >>>>>>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>>>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > -- > >>>>>>>> > TF-A mailing list > >>>>>>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>>>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>>>>>>> > > >>>>>>>> > > >>>>>>>> -- > >>>>>>>> TF-A mailing list > >>>>>>>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>>>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>>>> > >>>>> > >>>>> -- > >>>>> TF-A mailing list > >>>>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>> > >>> -- > >>> TF-A mailing list > >>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <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

5 years, 4 months

1
0
0 0

Re: [TF-A] BL31 as bootloader

by Alexei Fedorov

Hi Ravi As you can see in debugger that memory at 0x80020000 address is populated correctly, can you set a breakpoint at it to check if execuion reaches it? If you cannot set a breakpoint I would suggest to add a few assembler instructions in the start of your BL33 entry point to write any specific character, e.g. '!' to debug UART data port and branch to the next instruction in an infinite loop with "b .". Seeing ! char on debug console would prove that control to BL33 image has been passed. Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 24 October 2020 22:48 To: Ravi Kohli <rkohli2000(a)gmail.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] BL31 as bootloader Hi Alexei, Manish, I instrumented the imx8QM platform code and saw normal execution with bl31_main() exiting normally with entry point for my BL33 image. But, I haven't seen the handoff work yet. Can you suggest what else I can try to debug this ? I have an image copied at 0x80020000 from what I can see in the debugger. Thanks in advance. Regards Ravi On Fri, Oct 23, 2020 at 3:43 PM rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> wrote: Hi Manish, I have been able to copy the test app (BL33) to entry point address 0x80020000. I confirmed from the Debugger that RAM address 0x80020000 is populated. I had to modify imx-atf makefile target to use the "-data" option as follows: flash_test_8: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -data App.bin 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin The -data option appears to copy the image at the 0x80020000 address. Now, I think we should be able to handoff since PC (program counter) is set : bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); I don't see any serial console output using an image that works when using u-boot. I am not using u-boot for certification reasons. Is there some way I can confirm that the handoff is happening from bl31.bin to the App.bin ? At which BL31 function or module does the handoff occur ? I don't see my HW breakpoint trigger at location location 0x80020000. Regards Ravi On Oct 23, 2020, at 9:25 AM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hi Manish, Can you please point me to any example or a BL2 module which does the copy to RAM from Flash ? Maybe I can try to copy the image to 0x80020000 before exiting BL31 from bl31_main(). The bl31.bin image boot fine on the target board (imx8qm) from location 0x80000000 to start with. That copy to 0x80000000 must happen as well. I'm not sure where assuming its some NXP firmware doing it. Do you know where it could be ? Regards Ravi On Oct 23, 2020, at 4:46 AM, Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> wrote: Hi Ravi, This is normal behaviour when you RESET_TO_BL31. The loading of images (from flash to RAM) is part of BL2 code and in case of directly jumping to BL31, you need a mechanism to Load these images at proper location. Some platforms have a separate firmware which does this before starting execution of BL31, so that when BL31 hands over to BL33 it gets valid image there. thanks Manish ________________________________ From: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> Sent: 23 October 2020 05:08 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>>; Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader Hi Alexei, Manish, I repeated the test (below) a few times and see the same result. (1) Do I need to copy my BL33 (non-secure) image from flash.bin some how to RAM 0x80020000 entry point address ? Is there any example of how to copy the flash.bin image ? I not sure what address or where to copy it from. (2) Is there some existing debug code that I can use to dump/print the ARMv8 RAM address space from inside BL31.bin ? I only found some TF-A tf_log macros in debug.h. I would like to dump some memory address contents (like 0x80020000) from inside bl31.bin to console just for debugging at run-time. On Oct 22, 2020, at 4:28 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hi Alexei, I captured the LOG_LEVEL=50 log (attached putty-ser0.log<https://www.dropbox.com/s/bi3hngmljksxl3a/putty-ser0.log?dl=0>) from TF-A bl31.bin. I see bl31 boots normally but never hands off to the BL33 normal world image (App.bin) The flash.bin image I am running is constructed using imx-mkimage<https://source.codeaurora.org/external/imx/imx-mkimage/tree/README?h=imx_4.…> tool with the following target: flash_test_7: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -p3 -ap App.bin a53 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin I used UUU tool to flash eMMC with flash.bin on the imx8QM MEK board. I inspected RAM using a trace32 debugger SW after using a while (1) to halt the execution at the end of bl31.bin main function (bl31_main()). diff --git a/bl31/bl31_main.c b/bl31/bl31_main.c index 92a2027dd..51afb13ea 100644 --- a/bl31/bl31_main.c +++ b/bl31/bl31_main.c @@ -147,6 +147,11 @@ void bl31_main(void) * from BL31 */ bl31_plat_runtime_setup(); + + INFO("BL31: leaving bl31_main\n"); + INFO("entering while(1)\n"); + + while (1) {}; } It appears that there's no data or image at 0x80020000 just before exiting bl31_main(). See the debugger RAM dump at address 0x80000000 (bl31.bin entry point) and 0x80020000 (BL33 or App.bin normal world app entry point). See the debugger output<https://www.dropbox.com/s/revv4qev2ky5djj/ksnip_20201022-153339.png?dl=0>. When should the flash image provided in flash.bin get copied to the RAM entry point 0x80020000 ? Should bl31.bin copy the image from flash to RAM ? Can you suggest what could be going on ? Regards Ravi On Oct 22, 2020, at 6:15 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: Hi Ravi, TFTF image can be built from https://git.trustedfirmware.org/TF-A/tf-a-tests.git You can also try to increase TF-A log level by setting LOG_LEVEL=50 and check if BL33 memory region is mapped correctly. Before passing control to BL33 and could add code to dump initial memory at BL33 start address to see if the image was loaded with no issues. Regards. Alexei ________________________________ From: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> Sent: 21 October 2020 19:59 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader Alexei, I don't have a DS-5 debugger setup/licensed. I am hoping on getting something shortly. Can you point me to the TFTF image that I can use to test the BL33 handoff ? Sorry, I'm not familiar at this time. Regards Ravi On Oct 21, 2020, at 12:35 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: You can also use TFTF image as BL33. Alexei ________________________________ From: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Sent: 21 October 2020 15:26 To: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader The best way to figure out whether handing off to BL33 happened or not is by attaching a debugger(DS-5). is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? - You can use a linux image and device tree to test it Refer to plat/brcm/common/brcm_bl31_setup.c -> "brcm_bl31_early_platform_setup()" function For linux as BL33 payload please use coder under "ARM_LINUX_KERNEL_AS_BL33" ________________________________ From: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> Sent: 21 October 2020 12:12 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader Hi Alexei, Manish, I tried the following patch to plat/imx/imx8qm/imx8qm_bl31_setup.c: @@ -483,11 +486,15 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, bl32_image_ep_info.args.arg3 = BL32_FDT_OVERLAY_ADDR; #endif #endif + // DEBUG ONLY - FIXME + SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); + SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); /* init the first cluster's cci slave interface */ cci_init(PLAT_CCI_BASE, imx8qm_cci_map, PLATFORM_CLUSTER_COUNT); cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); + } But no luck. Is there some way to confirm my bl31.bin is handing off to any BL33 (normal world) test image ? In other words, is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? Thanks. On Oct 21, 2020, at 6:10 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: Hi Ravi, You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: /* Populate entry point information for BL33 */ SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); /* * Tell BL31 where the non-trusted software image * is located and the entry state information */ bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 21 October 2020 10:57 To: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader Hi Manish, The test image should not have any dependency on device tree (dtb?) for console init. I used the NXP provided imx8qm-mek-ca53.dtb file which should match the MEK board. I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) as well but no luck. I don't believe PC is getting set to the 0x80020000 entry point. The test image has validated with u-boot using these tftpboot settings: setenv ipaddr x.x.x.x setenv serverip x.x.x.x tftpboot 0xf0000000 App.bin bootm 0xf0000000 I don't see any console output on the screen running it with bl31.bin as below. Is there any debug I can add somewhere to help troubleshoot? Can you please provide me instructions on where to patch this missing code : "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" I can try it to see if any change in behavior. Thanks in advance. Regards Ravi On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> wrote: > > Hi Ravi, > > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. > Also, does your "test image" depends on device tree for console initialization? > > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); > > thanks > Manish > > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Sent: 21 October 2020 00:10 > To: Ravi Kohli <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> > Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Subject: Re: [TF-A] BL31 as bootloader > > Hi Alexei, > > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. > > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 > > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: > > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. > > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff > NOTICE: Memreg 6 0x80000000 -- 0xffffffff > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff > NOTICE: Non-secure Partitioning Succeeded > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 > INFO: bl31_platform_setup is called > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 > INFO: BL31: Initializing runtime services > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > INFO: BL31: Preparing for EL3 exit to normal world > INFO: Entry point address = 0x80020000 > INFO: SPSR = 0x3c9 > INFO: BL31: DEBUG: image_type is: normal > > > Can anyone please suggest what could be the issue here that I don't see the test image console output ? > Note, the same test image works fine using u-boot. > > Regards > Ravi > > > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: > > Hi Alexei, > > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. > I will try it out and confirm. And, thanks for this suggestion. > > Regards > Ravi > > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: > > Hi Ravi, > > Have you tried to use RESET_TO_BL31 build option for your platform? > > Regards. > Alexei > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Sent: 07 October 2020 17:01 > To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Subject: [TF-A] BL31 as bootloader > > Hi, > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. > > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can > specify this container image with both bl31.bin and a separate custom app at a give flash address. > This is without any security requirements or dependencies. > > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point > 0x80020000 address ? > > Thanks in advance. > Ravi > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 4 months

2
6
0 0

Re: [TF-A] Questions raised about Measured Boot + fTPM test case

by Alexei Fedorov

Hi Javer, Please see my comments below. [3] Provide platform hooks in tpm_record_measurement function for a platform to actually extend those measurements to a physical TPM right when they are measured. These hooks can be implemented in the next phase #2 of Measured Boot implementation. [4] On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should also be measured since they are images being loaded as well. See arm_bl1_setup.c where these images are loaded but not measured(unless I’m missing something). FW_CONFIG and TB_FW_CONFIG images are loaded by BL1 but not BL2. BL1 calculates BL2 hash and passes the measurement to BL2 in TB_FW_CONFIG. It can also pass FW_CONFIG hash in the same DTB, but it is not clear how own TB_FW_CONFIG hash can be passed in itself. Stuart, do you have opinion on that? Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Javier Almansa Sobrino via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 26 October 2020 10:25 To: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Questions raised about Measured Boot + fTPM test case Hi Raghu, Thank you very much for your comments and for your feedback. With regards to the (f)TPM service and as discussed during the last TF-A Tech Forum call, we will discuss internally the need of a new implementation, probably after the next TF-A release, and we will schedule the work (in case we decide to go ahead with it) for the upcoming months. We will announce any decision we make through the mailing list and/or on future TF-A Tech Forum calls . Regarding to changes to TF-A to include extra functionality/APIs/hooks, I guess my colleague Alexei can provide further details about the next features planned for Measured Boot, if any. To finish, I would just like to clarify one of the questions raised on your email: [1] Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood. * Microsoft has a reference implementation of the TPM 2.0 specification. That implementation is in the form of an architecture agnostic library that implements the specification. Along with the library, there are a couple of example applications for different platforms built around the former, one of them being the fTPM we used for testing. That application was written for AARCH32 and seemed to be outdated (I don't know if it was abandoned, actually), so we updated it and added support for Measured Boot to it. Best regards, Javier -----Original Message----- From: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> To: 'Javier Almansa Sobrino' <Javier.AlmansaSobrino(a)arm.com<mailto:'Javier%20Almansa%20Sobrino'%20%3cJavier.AlmansaSobrino(a)arm.com%3e>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: RE: [TF-A] Questions raised about Measured Boot + fTPM test case Date: Sun, 25 Oct 2020 14:31:10 -0700 Hi Javier, As discussed during the TF-A call, here are some suggestions/feedback that can be incorporated when time permits based on priorities, schedule, resources etc: 1. Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood. 2. Would be good if the TPM TA works on FF-A as opposed to proprietary OPTEE API’s. 3. Provide platform hooks in tpm_record_measurement function for a platform to actually extend those measurements to a physical TPM right when they are measured. This is a requirement from a security perspective to not wait until the tpm TA is loaded to be able to extend the measurements into a tpm. I understand this can be done in the platform hook that calls tpm_record_measurement but it is convenient place to put tpm related platform hooks. 4. On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should also be measured since they are images being loaded as well. See arm_bl1_setup.c where these images are loaded but not measured(unless I’m missing something). Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Javier Almansa Sobrino via TF-A Sent: Friday, October 9, 2020 10:51 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Questions raised about Measured Boot + fTPM test case Hello all, Following up the question raised yesterday during the TF-A Tech Forum with regards to any modification needed on the Linux Kernel to run the test case that I was presenting (Measured Boot + fTPM service), I double checked today and I ran some tests on system and I can confirm that the test case works with the mainline Linux Kernel, with no modification other than enabling the driver on the DTB. The modules involved on the interaction with the fTPM (for this particular example) are: * optee.ko: Allows communication between the REE (unsecure world), the Trusted OS (secure world) and the tee-supplicant (unsecure world). * tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a char device. This also includes the reference implementation used on the test case. In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM. I would also like to highlight the following points: A) The test case is only meant to test the ability of the Measured Boot Driver and a TPM 2.0 compliant device to interact with each other. As such, we are not providing an fTPM meant to be used on a production environment. Instead, we are using an existing reference implementation to which we added support for Measured Boot to fulfil our needs for the test and use it as a functional example. The implementation details on how to interact with a particular TPM device (either firmware or discrete) can differ from the ones used on the test case as those details can be platform dependent. For example, we use an OPTEE TA fTPM on this example, but other platforms might use a discrete TPM or an fTPM running on a different Trusted OS. B) As stated on the presentation, we are undergoing internal review of the contributions done for the fTPM service to make it compatible with Measured Boot. Once the review is completed and the changes merged into the TPM repo mainline, we will update the TF-A documentation with instructions on how to download and build all the components to run the tests manually. Please, let me know in case you have any more questions. Best regards, Javier

5 years, 4 months

2
1
0 0

Re: [TF-A] Questions raised about Measured Boot + fTPM test case

by raghu.ncstate＠icloud.com

Hi Javier, As discussed during the TF-A call, here are some suggestions/feedback that can be incorporated when time permits based on priorities, schedule, resources etc: 1. Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood. 2. Would be good if the TPM TA works on FF-A as opposed to proprietary OPTEE API’s. 3. Provide platform hooks in tpm_record_measurement function for a platform to actually extend those measurements to a physical TPM right when they are measured. This is a requirement from a security perspective to not wait until the tpm TA is loaded to be able to extend the measurements into a tpm. I understand this can be done in the platform hook that calls tpm_record_measurement but it is convenient place to put tpm related platform hooks. 4. On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should also be measured since they are images being loaded as well. See arm_bl1_setup.c where these images are loaded but not measured(unless I’m missing something). Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Javier Almansa Sobrino via TF-A Sent: Friday, October 9, 2020 10:51 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Questions raised about Measured Boot + fTPM test case Hello all, Following up the question raised yesterday during the TF-A Tech Forum with regards to any modification needed on the Linux Kernel to run the test case that I was presenting (Measured Boot + fTPM service), I double checked today and I ran some tests on system and I can confirm that the test case works with the mainline Linux Kernel, with no modification other than enabling the driver on the DTB. The modules involved on the interaction with the fTPM (for this particular example) are: * optee.ko: Allows communication between the REE (unsecure world), the Trusted OS (secure world) and the tee-supplicant (unsecure world). * tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a char device. This also includes the reference implementation used on the test case. In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM. I would also like to highlight the following points: A) The test case is only meant to test the ability of the Measured Boot Driver and a TPM 2.0 compliant device to interact with each other. As such, we are not providing an fTPM meant to be used on a production environment. Instead, we are using an existing reference implementation to which we added support for Measured Boot to fulfil our needs for the test and use it as a functional example. The implementation details on how to interact with a particular TPM device (either firmware or discrete) can differ from the ones used on the test case as those details can be platform dependent. For example, we use an OPTEE TA fTPM on this example, but other platforms might use a discrete TPM or an fTPM running on a different Trusted OS. B) As stated on the presentation, we are undergoing internal review of the contributions done for the fTPM service to make it compatible with Measured Boot. Once the review is completed and the changes merged into the TPM repo mainline, we will update the TF-A documentation with instructions on how to download and build all the components to run the tests manually. Please, let me know in case you have any more questions. Best regards, Javier

5 years, 4 months

2
1
0 0

Re: [TF-A] BL31 as bootloader

by rkohli2000 gmail

Hi Manish, I have been able to copy the test app (BL33) to entry point address 0x80020000. I confirmed from the Debugger that RAM address 0x80020000 is populated. I had to modify imx-atf makefile target to use the "-data" option as follows: flash_test_8: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -data App.bin 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin The -data option appears to copy the image at the 0x80020000 address. Now, I think we should be able to handoff since PC (program counter) is set : bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); I don't see any serial console output using an image that works when using u-boot. I am not using u-boot for certification reasons. Is there some way I can confirm that the handoff is happening from bl31.bin to the App.bin ? At which BL31 function or module does the handoff occur ? I don't see my HW breakpoint trigger at location location 0x80020000. Regards Ravi > On Oct 23, 2020, at 9:25 AM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Manish, > > Can you please point me to any example or a BL2 module which does the copy to RAM from Flash ? > Maybe I can try to copy the image to 0x80020000 before exiting BL31 from bl31_main(). > > The bl31.bin image boot fine on the target board (imx8qm) from location 0x80000000 > to start with. That copy to 0x80000000 must happen as well. I'm not sure where assuming > its some NXP firmware doing it. Do you know where it could be ? > > Regards > Ravi > > >> On Oct 23, 2020, at 4:46 AM, Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: >> >> Hi Ravi, >> >> This is normal behaviour when you RESET_TO_BL31. >> The loading of images (from flash to RAM) is part of BL2 code and in case of directly jumping to BL31, you need a mechanism to Load these images at proper location. >> Some platforms have a separate firmware which does this before starting execution of BL31, so that when BL31 hands over to BL33 it gets valid image there. >> >> thanks >> Manish >> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >> Sent: 23 October 2020 05:08 >> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>>; Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> >> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >> Subject: Re: [TF-A] BL31 as bootloader >> >> Hi Alexei, Manish, >> >> I repeated the test (below) a few times and see the same result. >> >> (1) Do I need to copy my BL33 (non-secure) image from >> flash.bin some how to RAM 0x80020000 entry point address ? >> Is there any example of how to copy the flash.bin image ? I not sure >> what address or where to copy it from. >> >> (2) Is there some existing debug code that I can use >> to dump/print the ARMv8 RAM address space from inside >> BL31.bin ? >> >> I only found some TF-A tf_log macros in debug.h. >> I would like to dump some memory address contents >> (like 0x80020000) from inside bl31.bin to console just for >> debugging at run-time. >> >>> On Oct 22, 2020, at 4:28 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: >>> >>> Hi Alexei, >>> >>> I captured the LOG_LEVEL=50 log (attached putty-ser0.log <https://www.dropbox.com/s/bi3hngmljksxl3a/putty-ser0.log?dl=0>) from TF-A bl31.bin. >>> I see bl31 boots normally but never hands off to the BL33 normal world image (App.bin) >>> >>> The flash.bin image I am running is constructed using imx-mkimage <https://source.codeaurora.org/external/imx/imx-mkimage/tree/README?h=imx_4.…> tool with the following target: >>>> flash_test_7: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb >>> >>>> ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -p3 -ap App.bin a53 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin >>> >>> >>> I used UUU tool to flash eMMC with flash.bin on the imx8QM MEK board. >>> >>> I inspected RAM using a trace32 debugger SW after using a while (1) to halt the execution at the end of bl31.bin main function (bl31_main()). >>>> diff --git a/bl31/bl31_main.c b/bl31/bl31_main.c >>> >>>> index 92a2027dd..51afb13ea 100644 >>> >>>> --- a/bl31/bl31_main.c >>> >>>> >>> >>>> +++ b/bl31/bl31_main.c >>> >>>> @@ -147,6 +147,11 @@ void bl31_main(void) >>> >>>> * from BL31 >>> >>>> */ >>> >>>> bl31_plat_runtime_setup(); >>> >>>> + >>> >>>> + INFO("BL31: leaving bl31_main\n"); >>> >>>> + INFO("entering while(1)\n"); >>> >>>> + >>> >>>> + while (1) {}; >>> >>>> } >>> >>> It appears that there's no data or image at 0x80020000 just before exiting bl31_main(). See the debugger RAM dump at >>> address 0x80000000 (bl31.bin entry point) and 0x80020000 (BL33 or App.bin normal world app entry point). >>> See the debugger output <https://www.dropbox.com/s/revv4qev2ky5djj/ksnip_20201022-153339.png?dl=0>. >>> >>> When should the flash image provided in flash.bin get copied to the RAM entry point 0x80020000 ? Should bl31.bin >>> copy the image from flash to RAM ? >>> >>> Can you suggest what could be going on ? >>> >>> Regards >>> Ravi >>> >>> >>> >>>> On Oct 22, 2020, at 6:15 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>>> >>>> Hi Ravi, >>>> >>>> TFTF image can be built from https://git.trustedfirmware.org/TF-A/tf-a-tests.git <https://git.trustedfirmware.org/TF-A/tf-a-tests.git> >>>> >>>> You can also try to increase TF-A log level by setting LOG_LEVEL=50 and check if BL33 memory region is mapped correctly. >>>> Before passing control to BL33 and could add code to dump initial memory at BL33 start address to see if the image was loaded with no issues. >>>> >>>> Regards. >>>> Alexei >>>> >>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >>>> Sent: 21 October 2020 19:59 >>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >>>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>> Subject: Re: [TF-A] BL31 as bootloader >>>> >>>> Alexei, >>>> >>>> I don't have a DS-5 debugger setup/licensed. I am hoping >>>> on getting something shortly. >>>> >>>> Can you point me to the TFTF image that I can use to >>>> test the BL33 handoff ? >>>> >>>> Sorry, I'm not familiar at this time. >>>> >>>> Regards >>>> Ravi >>>> >>>> >>>>> On Oct 21, 2020, at 12:35 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>>>> >>>>> You can also use TFTF image as BL33. >>>>> >>>>> Alexei >>>>> >>>>> From: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> >>>>> Sent: 21 October 2020 15:26 >>>>> To: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >>>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>> Subject: Re: [TF-A] BL31 as bootloader >>>>> >>>>> The best way to figure out whether handing off to BL33 happened or not is by attaching a debugger(DS-5). >>>>> >>>>> is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? >>>>> - You can use a linux image and device tree to test it >>>>> Refer to plat/brcm/common/brcm_bl31_setup.c -> "brcm_bl31_early_platform_setup()" function >>>>> For linux as BL33 payload please use coder under "ARM_LINUX_KERNEL_AS_BL33" >>>>> >>>>> >>>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >>>>> Sent: 21 October 2020 12:12 >>>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >>>>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>> Subject: Re: [TF-A] BL31 as bootloader >>>>> >>>>> Hi Alexei, Manish, >>>>> >>>>> I tried the following patch to plat/imx/imx8qm/imx8qm_bl31_setup.c: >>>>>> @@ -483,11 +486,15 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, >>>>>> bl32_image_ep_info.args.arg3 = BL32_FDT_OVERLAY_ADDR; >>>>>> #endif >>>>>> #endif >>>>>> + // DEBUG ONLY - FIXME >>>>>> + SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); >>>>>> + >>>>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); >>>>>> >>>>>> /* init the first cluster's cci slave interface */ >>>>>> cci_init(PLAT_CCI_BASE, imx8qm_cci_map, PLATFORM_CLUSTER_COUNT); >>>>>> cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); >>>>>> + >>>>>> } >>>>> But no luck. >>>>> >>>>> Is there some way to confirm my bl31.bin is handing off to any BL33 (normal world) test image ? >>>>> In other words, is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? >>>>>> >>>>> Thanks. >>>>> >>>>> >>>>>> On Oct 21, 2020, at 6:10 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>>>>> >>>>>> Hi Ravi, >>>>>> >>>>>> You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: >>>>>> >>>>>> /* Populate entry point information for BL33 */ >>>>>> SET_PARAM_HEAD(&bl33_image_ep_info, >>>>>> PARAM_EP, >>>>>> VERSION_1, >>>>>> 0); >>>>>> /* >>>>>> * Tell BL31 where the non-trusted software image >>>>>> * is located and the entry state information >>>>>> */ >>>>>> bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); >>>>>> >>>>>> bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); >>>>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); >>>>>> >>>>>> Regards. >>>>>> Alexei >>>>>> >>>>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>>> Sent: 21 October 2020 10:57 >>>>>> To: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> >>>>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>>> Subject: Re: [TF-A] BL31 as bootloader >>>>>> >>>>>> Hi Manish, >>>>>> >>>>>> The test image should not have any dependency on device tree (dtb?) >>>>>> for console init. >>>>>> I used the NXP provided imx8qm-mek-ca53.dtb file which should match >>>>>> the MEK board. >>>>>> I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) >>>>>> as well but no luck. >>>>>> I don't believe PC is getting set to the 0x80020000 entry point. >>>>>> >>>>>> The test image has validated with u-boot using these tftpboot settings: >>>>>> setenv ipaddr x.x.x.x >>>>>> setenv serverip x.x.x.x >>>>>> tftpboot 0xf0000000 App.bin >>>>>> bootm 0xf0000000 >>>>>> >>>>>> I don't see any console output on the screen running it with bl31.bin as below. >>>>>> Is there any debug I can add somewhere to help troubleshoot? >>>>>> >>>>>> Can you please provide me instructions on where to patch this missing code : >>>>>> "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" >>>>>> I can try it to see if any change in behavior. >>>>>> >>>>>> Thanks in advance. >>>>>> Regards >>>>>> Ravi >>>>>> >>>>>> >>>>>> On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: >>>>>> > >>>>>> > Hi Ravi, >>>>>> > >>>>>> > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. >>>>>> > Also, does your "test image" depends on device tree for console initialization? >>>>>> > >>>>>> > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization >>>>>> > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); >>>>>> > >>>>>> > thanks >>>>>> > Manish >>>>>> > >>>>>> > ________________________________ >>>>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>>> > Sent: 21 October 2020 00:10 >>>>>> > To: Ravi Kohli <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >>>>>> > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>>> > Subject: Re: [TF-A] BL31 as bootloader >>>>>> > >>>>>> > Hi Alexei, >>>>>> > >>>>>> > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. >>>>>> > >>>>>> > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 >>>>>> > >>>>>> > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: >>>>>> > >>>>>> > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb >>>>>> > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin >>>>>> > >>>>>> > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). >>>>>> > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. >>>>>> > >>>>>> > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff >>>>>> > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff >>>>>> > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff >>>>>> > NOTICE: Memreg 6 0x80000000 -- 0xffffffff >>>>>> > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff >>>>>> > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff >>>>>> > NOTICE: Non-secure Partitioning Succeeded >>>>>> > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty >>>>>> > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 >>>>>> > INFO: bl31_platform_setup is called >>>>>> > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 >>>>>> > INFO: BL31: Initializing runtime services >>>>>> > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied >>>>>> > INFO: BL31: Preparing for EL3 exit to normal world >>>>>> > INFO: Entry point address = 0x80020000 >>>>>> > INFO: SPSR = 0x3c9 >>>>>> > INFO: BL31: DEBUG: image_type is: normal >>>>>> > >>>>>> > >>>>>> > Can anyone please suggest what could be the issue here that I don't see the test image console output ? >>>>>> > Note, the same test image works fine using u-boot. >>>>>> > >>>>>> > Regards >>>>>> > Ravi >>>>>> > >>>>>> > >>>>>> > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: >>>>>> > >>>>>> > Hi Alexei, >>>>>> > >>>>>> > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. >>>>>> > I will try it out and confirm. And, thanks for this suggestion. >>>>>> > >>>>>> > Regards >>>>>> > Ravi >>>>>> > >>>>>> > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>>>>> > >>>>>> > Hi Ravi, >>>>>> > >>>>>> > Have you tried to use RESET_TO_BL31 build option for your platform? >>>>>> > >>>>>> > Regards. >>>>>> > Alexei >>>>>> > ________________________________ >>>>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>>> > Sent: 07 October 2020 17:01 >>>>>> > To: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>>> > Subject: [TF-A] BL31 as bootloader >>>>>> > >>>>>> > Hi, >>>>>> > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. >>>>>> > >>>>>> > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. >>>>>> > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can >>>>>> > specify this container image with both bl31.bin and a separate custom app at a give flash address. >>>>>> > This is without any security requirements or dependencies. >>>>>> > >>>>>> > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch >>>>>> > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point >>>>>> > 0x80020000 address ? >>>>>> > >>>>>> > Thanks in advance. >>>>>> > Ravi >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > TF-A mailing list >>>>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>>>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > TF-A mailing list >>>>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>>>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>>>>> > >>>>>> > >>>>>> -- >>>>>> TF-A mailing list >>>>>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>>>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>> >>> -- >>> TF-A mailing list >>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <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

5 years, 4 months

1
1
0 0

Re: [TF-A] BL31 as bootloader

by rkohli2000 gmail

Hi Alexei, Manish, I repeated the test (below) a few times and see the same result. (1) Do I need to copy my BL33 (non-secure) image from flash.bin some how to RAM 0x80020000 entry point address ? Is there any example of how to copy the flash.bin image ? I not sure what address or where to copy it from. (2) Is there some existing debug code that I can use to dump/print the ARMv8 RAM address space from inside BL31.bin ? I only found some TF-A tf_log macros in debug.h. I would like to dump some memory address contents (like 0x80020000) from inside bl31.bin to console just for debugging at run-time. > On Oct 22, 2020, at 4:28 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Alexei, > > I captured the LOG_LEVEL=50 log (attached putty-ser0.log <https://www.dropbox.com/s/bi3hngmljksxl3a/putty-ser0.log?dl=0>) from TF-A bl31.bin. > I see bl31 boots normally but never hands off to the BL33 normal world image (App.bin) > > The flash.bin image I am running is constructed using imx-mkimage <https://source.codeaurora.org/external/imx/imx-mkimage/tree/README?h=imx_4.…> tool with the following target: >> flash_test_7: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb > >> ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -p3 -ap App.bin a53 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > > > I used UUU tool to flash eMMC with flash.bin on the imx8QM MEK board. > > I inspected RAM using a trace32 debugger SW after using a while (1) to halt the execution at the end of bl31.bin main function (bl31_main()). >> diff --git a/bl31/bl31_main.c b/bl31/bl31_main.c > >> index 92a2027dd..51afb13ea 100644 > >> --- a/bl31/bl31_main.c > >> > >> +++ b/bl31/bl31_main.c > >> @@ -147,6 +147,11 @@ void bl31_main(void) > >> * from BL31 > >> */ > >> bl31_plat_runtime_setup(); > >> + > >> + INFO("BL31: leaving bl31_main\n"); > >> + INFO("entering while(1)\n"); > >> + > >> + while (1) {}; > >> } > > It appears that there's no data or image at 0x80020000 just before exiting bl31_main(). See the debugger RAM dump at > address 0x80000000 (bl31.bin entry point) and 0x80020000 (BL33 or App.bin normal world app entry point). > See the debugger output <https://www.dropbox.com/s/revv4qev2ky5djj/ksnip_20201022-153339.png?dl=0>. > > When should the flash image provided in flash.bin get copied to the RAM entry point 0x80020000 ? Should bl31.bin > copy the image from flash to RAM ? > > Can you suggest what could be going on ? > > Regards > Ravi > > > >> On Oct 22, 2020, at 6:15 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >> >> Hi Ravi, >> >> TFTF image can be built from https://git.trustedfirmware.org/TF-A/tf-a-tests.git <https://git.trustedfirmware.org/TF-A/tf-a-tests.git> >> >> You can also try to increase TF-A log level by setting LOG_LEVEL=50 and check if BL33 memory region is mapped correctly. >> Before passing control to BL33 and could add code to dump initial memory at BL33 start address to see if the image was loaded with no issues. >> >> Regards. >> Alexei >> >> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >> Sent: 21 October 2020 19:59 >> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >> Subject: Re: [TF-A] BL31 as bootloader >> >> Alexei, >> >> I don't have a DS-5 debugger setup/licensed. I am hoping >> on getting something shortly. >> >> Can you point me to the TFTF image that I can use to >> test the BL33 handoff ? >> >> Sorry, I'm not familiar at this time. >> >> Regards >> Ravi >> >> >>> On Oct 21, 2020, at 12:35 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>> >>> You can also use TFTF image as BL33. >>> >>> Alexei >>> >>> From: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> >>> Sent: 21 October 2020 15:26 >>> To: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> Subject: Re: [TF-A] BL31 as bootloader >>> >>> The best way to figure out whether handing off to BL33 happened or not is by attaching a debugger(DS-5). >>> >>> is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? >>> - You can use a linux image and device tree to test it >>> Refer to plat/brcm/common/brcm_bl31_setup.c -> "brcm_bl31_early_platform_setup()" function >>> For linux as BL33 payload please use coder under "ARM_LINUX_KERNEL_AS_BL33" >>> >>> >>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >>> Sent: 21 October 2020 12:12 >>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> Subject: Re: [TF-A] BL31 as bootloader >>> >>> Hi Alexei, Manish, >>> >>> I tried the following patch to plat/imx/imx8qm/imx8qm_bl31_setup.c: >>>> @@ -483,11 +486,15 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, >>>> bl32_image_ep_info.args.arg3 = BL32_FDT_OVERLAY_ADDR; >>>> #endif >>>> #endif >>>> + // DEBUG ONLY - FIXME >>>> + SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); >>>> + >>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); >>>> >>>> /* init the first cluster's cci slave interface */ >>>> cci_init(PLAT_CCI_BASE, imx8qm_cci_map, PLATFORM_CLUSTER_COUNT); >>>> cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); >>>> + >>>> } >>> But no luck. >>> >>> Is there some way to confirm my bl31.bin is handing off to any BL33 (normal world) test image ? >>> In other words, is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? >>>> >>> Thanks. >>> >>> >>>> On Oct 21, 2020, at 6:10 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>>> >>>> Hi Ravi, >>>> >>>> You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: >>>> >>>> /* Populate entry point information for BL33 */ >>>> SET_PARAM_HEAD(&bl33_image_ep_info, >>>> PARAM_EP, >>>> VERSION_1, >>>> 0); >>>> /* >>>> * Tell BL31 where the non-trusted software image >>>> * is located and the entry state information >>>> */ >>>> bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); >>>> >>>> bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); >>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); >>>> >>>> Regards. >>>> Alexei >>>> >>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>> Sent: 21 October 2020 10:57 >>>> To: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> >>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>> Subject: Re: [TF-A] BL31 as bootloader >>>> >>>> Hi Manish, >>>> >>>> The test image should not have any dependency on device tree (dtb?) >>>> for console init. >>>> I used the NXP provided imx8qm-mek-ca53.dtb file which should match >>>> the MEK board. >>>> I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) >>>> as well but no luck. >>>> I don't believe PC is getting set to the 0x80020000 entry point. >>>> >>>> The test image has validated with u-boot using these tftpboot settings: >>>> setenv ipaddr x.x.x.x >>>> setenv serverip x.x.x.x >>>> tftpboot 0xf0000000 App.bin >>>> bootm 0xf0000000 >>>> >>>> I don't see any console output on the screen running it with bl31.bin as below. >>>> Is there any debug I can add somewhere to help troubleshoot? >>>> >>>> Can you please provide me instructions on where to patch this missing code : >>>> "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" >>>> I can try it to see if any change in behavior. >>>> >>>> Thanks in advance. >>>> Regards >>>> Ravi >>>> >>>> >>>> On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: >>>> > >>>> > Hi Ravi, >>>> > >>>> > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. >>>> > Also, does your "test image" depends on device tree for console initialization? >>>> > >>>> > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization >>>> > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); >>>> > >>>> > thanks >>>> > Manish >>>> > >>>> > ________________________________ >>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>> > Sent: 21 October 2020 00:10 >>>> > To: Ravi Kohli <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >>>> > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>> > Subject: Re: [TF-A] BL31 as bootloader >>>> > >>>> > Hi Alexei, >>>> > >>>> > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. >>>> > >>>> > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 >>>> > >>>> > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: >>>> > >>>> > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb >>>> > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin >>>> > >>>> > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). >>>> > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. >>>> > >>>> > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff >>>> > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff >>>> > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff >>>> > NOTICE: Memreg 6 0x80000000 -- 0xffffffff >>>> > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff >>>> > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff >>>> > NOTICE: Non-secure Partitioning Succeeded >>>> > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty >>>> > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 >>>> > INFO: bl31_platform_setup is called >>>> > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 >>>> > INFO: BL31: Initializing runtime services >>>> > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied >>>> > INFO: BL31: Preparing for EL3 exit to normal world >>>> > INFO: Entry point address = 0x80020000 >>>> > INFO: SPSR = 0x3c9 >>>> > INFO: BL31: DEBUG: image_type is: normal >>>> > >>>> > >>>> > Can anyone please suggest what could be the issue here that I don't see the test image console output ? >>>> > Note, the same test image works fine using u-boot. >>>> > >>>> > Regards >>>> > Ravi >>>> > >>>> > >>>> > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: >>>> > >>>> > Hi Alexei, >>>> > >>>> > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. >>>> > I will try it out and confirm. And, thanks for this suggestion. >>>> > >>>> > Regards >>>> > Ravi >>>> > >>>> > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>>> > >>>> > Hi Ravi, >>>> > >>>> > Have you tried to use RESET_TO_BL31 build option for your platform? >>>> > >>>> > Regards. >>>> > Alexei >>>> > ________________________________ >>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>> > Sent: 07 October 2020 17:01 >>>> > To: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>> > Subject: [TF-A] BL31 as bootloader >>>> > >>>> > Hi, >>>> > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. >>>> > >>>> > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. >>>> > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can >>>> > specify this container image with both bl31.bin and a separate custom app at a give flash address. >>>> > This is without any security requirements or dependencies. >>>> > >>>> > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch >>>> > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point >>>> > 0x80020000 address ? >>>> > >>>> > Thanks in advance. >>>> > Ravi >>>> > >>>> > >>>> > >>>> > -- >>>> > TF-A mailing list >>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>>> > >>>> > >>>> > -- >>>> > TF-A mailing list >>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>>> > >>>> > >>>> -- >>>> TF-A mailing list >>>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <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

5 years, 4 months

2
2
0 0

Fwd: BL31 as bootloader

by rkohli2000 gmail

Hi Alexei, I captured the LOG_LEVEL=50 log (attached putty-ser0.log <https://www.dropbox.com/s/bi3hngmljksxl3a/putty-ser0.log?dl=0>) from TF-A bl31.bin. I see bl31 boots normally but never hands off to the BL33 normal world image (App.bin) The flash.bin image I am running is constructed using imx-mkimage <https://source.codeaurora.org/external/imx/imx-mkimage/tree/README?h=imx_4.…> tool with the following target: > flash_test_7: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -p3 -ap App.bin a53 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin I used UUU tool to flash eMMC with flash.bin on the imx8QM MEK board. I inspected RAM using a trace32 debugger SW after using a while (1) to halt the execution at the end of bl31.bin main function (bl31_main()). > diff --git a/bl31/bl31_main.c b/bl31/bl31_main.c > index 92a2027dd..51afb13ea 100644 > --- a/bl31/bl31_main.c > > +++ b/bl31/bl31_main.c > @@ -147,6 +147,11 @@ void bl31_main(void) > * from BL31 > */ > bl31_plat_runtime_setup(); > + > + INFO("BL31: leaving bl31_main\n"); > + INFO("entering while(1)\n"); > + > + while (1) {}; > } It appears that there's no data or image at 0x80020000 just before exiting bl31_main(). See the debugger RAM dump at address 0x80000000 (bl31.bin entry point) and 0x80020000 (BL33 or App.bin normal world app entry point). See the debugger output <https://www.dropbox.com/s/revv4qev2ky5djj/ksnip_20201022-153339.png?dl=0>. When should the flash image provided in flash.bin get copied to the RAM entry point 0x80020000 ? Should bl31.bin copy the image from flash to RAM ? Can you suggest what could be going on ? Regards Ravi > On Oct 22, 2020, at 6:15 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > > Hi Ravi, > > TFTF image can be built from https://git.trustedfirmware.org/TF-A/tf-a-tests.git <https://git.trustedfirmware.org/TF-A/tf-a-tests.git> > > You can also try to increase TF-A log level by setting LOG_LEVEL=50 and check if BL33 memory region is mapped correctly. > Before passing control to BL33 and could add code to dump initial memory at BL33 start address to see if the image was loaded with no issues. > > Regards. > Alexei > > From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > Sent: 21 October 2020 19:59 > To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > Subject: Re: [TF-A] BL31 as bootloader > > Alexei, > > I don't have a DS-5 debugger setup/licensed. I am hoping > on getting something shortly. > > Can you point me to the TFTF image that I can use to > test the BL33 handoff ? > > Sorry, I'm not familiar at this time. > > Regards > Ravi > > >> On Oct 21, 2020, at 12:35 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >> >> You can also use TFTF image as BL33. >> >> Alexei >> >> From: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> >> Sent: 21 October 2020 15:26 >> To: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >> Subject: Re: [TF-A] BL31 as bootloader >> >> The best way to figure out whether handing off to BL33 happened or not is by attaching a debugger(DS-5). >> >> is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? >> - You can use a linux image and device tree to test it >> Refer to plat/brcm/common/brcm_bl31_setup.c -> "brcm_bl31_early_platform_setup()" function >> For linux as BL33 payload please use coder under "ARM_LINUX_KERNEL_AS_BL33" >> >> >> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >> Sent: 21 October 2020 12:12 >> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >> Subject: Re: [TF-A] BL31 as bootloader >> >> Hi Alexei, Manish, >> >> I tried the following patch to plat/imx/imx8qm/imx8qm_bl31_setup.c: >>> @@ -483,11 +486,15 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, >>> bl32_image_ep_info.args.arg3 = BL32_FDT_OVERLAY_ADDR; >>> #endif >>> #endif >>> + // DEBUG ONLY - FIXME >>> + SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); >>> + >>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); >>> >>> /* init the first cluster's cci slave interface */ >>> cci_init(PLAT_CCI_BASE, imx8qm_cci_map, PLATFORM_CLUSTER_COUNT); >>> cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); >>> + >>> } >> But no luck. >> >> Is there some way to confirm my bl31.bin is handing off to any BL33 (normal world) test image ? >> In other words, is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? >>> >> Thanks. >> >> >>> On Oct 21, 2020, at 6:10 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>> >>> Hi Ravi, >>> >>> You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: >>> >>> /* Populate entry point information for BL33 */ >>> SET_PARAM_HEAD(&bl33_image_ep_info, >>> PARAM_EP, >>> VERSION_1, >>> 0); >>> /* >>> * Tell BL31 where the non-trusted software image >>> * is located and the entry state information >>> */ >>> bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); >>> >>> bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); >>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); >>> >>> Regards. >>> Alexei >>> >>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> Sent: 21 October 2020 10:57 >>> To: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> >>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> Subject: Re: [TF-A] BL31 as bootloader >>> >>> Hi Manish, >>> >>> The test image should not have any dependency on device tree (dtb?) >>> for console init. >>> I used the NXP provided imx8qm-mek-ca53.dtb file which should match >>> the MEK board. >>> I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) >>> as well but no luck. >>> I don't believe PC is getting set to the 0x80020000 entry point. >>> >>> The test image has validated with u-boot using these tftpboot settings: >>> setenv ipaddr x.x.x.x >>> setenv serverip x.x.x.x >>> tftpboot 0xf0000000 App.bin >>> bootm 0xf0000000 >>> >>> I don't see any console output on the screen running it with bl31.bin as below. >>> Is there any debug I can add somewhere to help troubleshoot? >>> >>> Can you please provide me instructions on where to patch this missing code : >>> "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" >>> I can try it to see if any change in behavior. >>> >>> Thanks in advance. >>> Regards >>> Ravi >>> >>> >>> On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: >>> > >>> > Hi Ravi, >>> > >>> > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. >>> > Also, does your "test image" depends on device tree for console initialization? >>> > >>> > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization >>> > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); >>> > >>> > thanks >>> > Manish >>> > >>> > ________________________________ >>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> > Sent: 21 October 2020 00:10 >>> > To: Ravi Kohli <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >>> > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> > Subject: Re: [TF-A] BL31 as bootloader >>> > >>> > Hi Alexei, >>> > >>> > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. >>> > >>> > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 >>> > >>> > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: >>> > >>> > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb >>> > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin >>> > >>> > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). >>> > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. >>> > >>> > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff >>> > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff >>> > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff >>> > NOTICE: Memreg 6 0x80000000 -- 0xffffffff >>> > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff >>> > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff >>> > NOTICE: Non-secure Partitioning Succeeded >>> > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty >>> > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 >>> > INFO: bl31_platform_setup is called >>> > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 >>> > INFO: BL31: Initializing runtime services >>> > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied >>> > INFO: BL31: Preparing for EL3 exit to normal world >>> > INFO: Entry point address = 0x80020000 >>> > INFO: SPSR = 0x3c9 >>> > INFO: BL31: DEBUG: image_type is: normal >>> > >>> > >>> > Can anyone please suggest what could be the issue here that I don't see the test image console output ? >>> > Note, the same test image works fine using u-boot. >>> > >>> > Regards >>> > Ravi >>> > >>> > >>> > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: >>> > >>> > Hi Alexei, >>> > >>> > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. >>> > I will try it out and confirm. And, thanks for this suggestion. >>> > >>> > Regards >>> > Ravi >>> > >>> > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>> > >>> > Hi Ravi, >>> > >>> > Have you tried to use RESET_TO_BL31 build option for your platform? >>> > >>> > Regards. >>> > Alexei >>> > ________________________________ >>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> > Sent: 07 October 2020 17:01 >>> > To: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> > Subject: [TF-A] BL31 as bootloader >>> > >>> > Hi, >>> > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. >>> > >>> > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. >>> > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can >>> > specify this container image with both bl31.bin and a separate custom app at a give flash address. >>> > This is without any security requirements or dependencies. >>> > >>> > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch >>> > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point >>> > 0x80020000 address ? >>> > >>> > Thanks in advance. >>> > Ravi >>> > >>> > >>> > >>> > -- >>> > TF-A mailing list >>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>> > >>> > >>> > -- >>> > TF-A mailing list >>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>> > >>> > >>> -- >>> TF-A mailing list >>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a>

5 years, 4 months

1
0
0 0

Re: [TF-A] BL31 as bootloader

by Alexei Fedorov

Hi Ravi, You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: /* Populate entry point information for BL33 */ SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); /* * Tell BL31 where the non-trusted software image * is located and the entry state information */ bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 21 October 2020 10:57 To: Manish Pandey2 <Manish.Pandey2(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] BL31 as bootloader Hi Manish, The test image should not have any dependency on device tree (dtb?) for console init. I used the NXP provided imx8qm-mek-ca53.dtb file which should match the MEK board. I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) as well but no luck. I don't believe PC is getting set to the 0x80020000 entry point. The test image has validated with u-boot using these tftpboot settings: setenv ipaddr x.x.x.x setenv serverip x.x.x.x tftpboot 0xf0000000 App.bin bootm 0xf0000000 I don't see any console output on the screen running it with bl31.bin as below. Is there any debug I can add somewhere to help troubleshoot? Can you please provide me instructions on where to patch this missing code : "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" I can try it to see if any change in behavior. Thanks in advance. Regards Ravi On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com> wrote: > > Hi Ravi, > > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. > Also, does your "test image" depends on device tree for console initialization? > > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); > > thanks > Manish > > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 21 October 2020 00:10 > To: Ravi Kohli <rkohli2000(a)gmail.com> > Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > Subject: Re: [TF-A] BL31 as bootloader > > Hi Alexei, > > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. > > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 > > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: > > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. > > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff > NOTICE: Memreg 6 0x80000000 -- 0xffffffff > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff > NOTICE: Non-secure Partitioning Succeeded > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 > INFO: bl31_platform_setup is called > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 > INFO: BL31: Initializing runtime services > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > INFO: BL31: Preparing for EL3 exit to normal world > INFO: Entry point address = 0x80020000 > INFO: SPSR = 0x3c9 > INFO: BL31: DEBUG: image_type is: normal > > > Can anyone please suggest what could be the issue here that I don't see the test image console output ? > Note, the same test image works fine using u-boot. > > Regards > Ravi > > > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Alexei, > > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. > I will try it out and confirm. And, thanks for this suggestion. > > Regards > Ravi > > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com> wrote: > > Hi Ravi, > > Have you tried to use RESET_TO_BL31 build option for your platform? > > Regards. > Alexei > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 07 October 2020 17:01 > To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > Subject: [TF-A] BL31 as bootloader > > Hi, > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. > > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can > specify this container image with both bl31.bin and a separate custom app at a give flash address. > This is without any security requirements or dependencies. > > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point > 0x80020000 address ? > > Thanks in advance. > Ravi > > > > -- > 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 > > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 4 months

3
6
0 0

Re: [TF-A] BL31 as bootloader

by Manish Pandey2

Hi Ravi, Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. Also, does your "test image" depends on device tree for console initialization? One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 21 October 2020 00:10 To: Ravi Kohli <rkohli2000(a)gmail.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] BL31 as bootloader Hi Alexei, I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. NOTICE: Memreg 3 0x38000000 -- 0x3bffffff NOTICE: Memreg 4 0x60000000 -- 0x6fffffff NOTICE: Memreg 5 0x70000000 -- 0x7fffffff NOTICE: Memreg 6 0x80000000 -- 0xffffffff NOTICE: Memreg 7 0x400000000 -- 0x43fffffff NOTICE: Memreg 8 0x880000000 -- 0x97fffffff NOTICE: Non-secure Partitioning Succeeded NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty NOTICE: BL31: Built : 17:33:32, Oct 20 2020 INFO: bl31_platform_setup is called INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 855873 was applied INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x80020000 INFO: SPSR = 0x3c9 INFO: BL31: DEBUG: image_type is: normal Can anyone please suggest what could be the issue here that I don't see the test image console output ? Note, the same test image works fine using u-boot. Regards Ravi On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hi Alexei, Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. I will try it out and confirm. And, thanks for this suggestion. Regards Ravi On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: Hi Ravi, Have you tried to use RESET_TO_BL31 build option for your platform? Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 07 October 2020 17:01 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] BL31 as bootloader Hi, I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can specify this container image with both bl31.bin and a separate custom app at a give flash address. This is without any security requirements or dependencies. Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point 0x80020000 address ? Thanks in advance. Ravi -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 4 months

2
1
0 0

Re: [TF-A] BL31 as bootloader

by rkohli2000 gmail

Hi Alexei, I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. NOTICE: Memreg 3 0x38000000 -- 0x3bffffff NOTICE: Memreg 4 0x60000000 -- 0x6fffffff NOTICE: Memreg 5 0x70000000 -- 0x7fffffff NOTICE: Memreg 6 0x80000000 -- 0xffffffff NOTICE: Memreg 7 0x400000000 -- 0x43fffffff NOTICE: Memreg 8 0x880000000 -- 0x97fffffff NOTICE: Non-secure Partitioning Succeeded NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty NOTICE: BL31: Built : 17:33:32, Oct 20 2020 INFO: bl31_platform_setup is called INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 855873 was applied INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x80020000 INFO: SPSR = 0x3c9 INFO: BL31: DEBUG: image_type is: normal Can anyone please suggest what could be the issue here that I don't see the test image console output ? Note, the same test image works fine using u-boot. Regards Ravi > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Alexei, > > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. > I will try it out and confirm. And, thanks for this suggestion. > > Regards > Ravi > >> On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >> >> Hi Ravi, >> >> Have you tried to use RESET_TO_BL31 build option for your platform? >> >> Regards. >> Alexei >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >> Sent: 07 October 2020 17:01 >> To: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >> Subject: [TF-A] BL31 as bootloader >> >> Hi, >> I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. >> >> I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. >> I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can >> specify this container image with both bl31.bin and a separate custom app at a give flash address. >> This is without any security requirements or dependencies. >> >> Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch >> a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point >> 0x80020000 address ? >> >> Thanks in advance. >> Ravi >> >> >> >> -- >> TF-A mailing list >> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <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

5 years, 4 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 22nd October 2020 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 22nd October 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: * Encrypted FIP Support * Presented by Sumit Garg * Summary * Overview of FIP encryption. * Common challenges with firmware encryption implementation and how we addressed those in TF-A. * FIP encryption implementation details. * Follow on Measured Boot Support in TF-A discussion from last meeting (if required) * 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

5 years, 4 months

1
0
0 0

Re: [TF-A] TF-A Tech Forum Agenda @ Thr 8th October 2020 16:00-1700 BST

by Ruchika Gupta

Hi Joanna, Can you please share the presentation of the session on Measured Boot. It is not currently available on the webpage - https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ Regards, Ruchika On Tue, 6 Oct 2020 at 22:58, Joanna Farley via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Hi All, > > > > The next TF-A Tech Forum is scheduled for Thu 8th October 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: > > > > - Measured Boot Support in TF-A > - Presented by Alexei Fedorov and Javier Almansa Sobrino > - Update on the support for Measured Boot in TF-A along with an > overview of test cases for integration with a TPM service > - 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 > > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

5 years, 5 months

2
1
0 0

Mbed TLS Virtual Workshop on Nov. 3rd

by Shebu Varghese Kuriakose

Hi All, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop on November 3rd (Tuesday) from 2pm to 6pm GMT. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration The workshop will be hosted in Zoom open to all. The invitation with the zoom link will be send in the Mbed TLS, PSA Crypto* mailing lists in the coming days. Here are some of the proposed agenda topics. Please reply if there is anything else you would like us or you to present during the workshop that will be interesting to the community * Constant-time code * How to be an effective Mbed TLS reviewer * Processes - how does work get scheduled? * Roadmap, Mbed TLS3.0 * PSA Crypto APIs * How Do I contribute my first review. Thanks, Shebu (TrustedFirmware.org Co-Chair, Mbed TLS Technology Manager) * https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto

5 years, 5 months

1
0
0 0

commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms.

by Biju Das

Hi All, I am porting Renesas RZ/G2M[1] platform to TF-A Master branch(commitid: eeb77da646844) . Initially faced a compilation error [2] which is fixed by using "#define" instead of "static const uint64_t". Then on target, found that BL31 is failed to boot[3], which is fixed by reverting the commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes"), see the logs [3]. Q1) Have you seen this issue? Please share your thoughts on this issues. [1] https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz/… [2] https://lists.trustedfirmware.org/pipermail/tf-a/2020-October/000763.html [3] Failure logs ------------ NOTICE: BL2: RZ/G Initial Program Loader(CA57) Rev.2.0.6 NOTICE: BL2: PRR is RZG G2M Ver.1.3 NOTICE: BL2: Board is HiHope RZ/G2M Rev.4.0 NOTICE: BL2: Boot device is QSPI Flash(40MHz) NOTICE: BL2: LCM state is unknown NOTICE: BL2: DDR3200(rev.0.40) NOTICE: BL2: [COLD_BOOT] NOTICE: BL2: DRAM Split is 2ch NOTICE: BL2: QoS is default setting(rev.0.19) NOTICE: BL2: DRAM refresh interval 1.95 usec NOTICE: BL2: Periodic Write DQ Training NOTICE: BL2: CH0: 400000000 - 47fffffff, 2 GiB NOTICE: BL2: CH2: 600000000 - 67fffffff, 2 GiB NOTICE: BL2: FDT at 0xe632a648 NOTICE: BL2: v2.3(release):v2.3-778-g4fd58b045 NOTICE: BL2: Built : 18:14:35, Oct 8 2020 NOTICE: BL2: Normal boot NOTICE: BL2: dst=0xe6328300 src=0x8180000 len=512(0x200) NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=6144(0x1800) NOTICE: rcar_file_len: len: 0x0003e000 NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=253952(0x3e000) NOTICE: rcar_file_len: len: 0x00100000 NOTICE: BL2: dst=0x50000000 src=0x8300000 len=1048576(0x100000) NOTICE: BL2: Booting BL31 [4]Working logs after reverting the commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") -------------------------------------- NOTICE: BL2: RZ/G Initial Program Loader(CA57) Rev.2.0.6 NOTICE: BL2: PRR is RZG G2M Ver.1.3 NOTICE: BL2: Board is HiHope RZ/G2M Rev.4.0 NOTICE: BL2: Boot device is QSPI Flash(40MHz) NOTICE: BL2: LCM state is unknown NOTICE: BL2: DDR3200(rev.0.40) NOTICE: BL2: [COLD_BOOT] NOTICE: BL2: DRAM Split is 2ch NOTICE: BL2: QoS is default setting(rev.0.19) NOTICE: BL2: DRAM refresh interval 1.95 usec NOTICE: BL2: Periodic Write DQ Training NOTICE: BL2: CH0: 400000000 - 47fffffff, 2 GiB NOTICE: BL2: CH2: 600000000 - 67fffffff, 2 GiB NOTICE: BL2: FDT at 0xe632a648 NOTICE: BL2: v2.3(release):v2.3-779-geba02ef39 NOTICE: BL2: Built : 18:16:47, Oct 8 2020 NOTICE: BL2: Normal boot NOTICE: BL2: dst=0xe6328300 src=0x8180000 len=512(0x200) NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=6144(0x1800) NOTICE: rcar_file_len: len: 0x0003e000 NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=253952(0x3e000) NOTICE: rcar_file_len: len: 0x00100000 NOTICE: BL2: dst=0x50000000 src=0x8300000 len=1048576(0x100000) NOTICE: BL2: Booting BL31 U-Boot 2020.10-00535-gd0e9210a2f (Oct 08 2020 - 12:34:09 +0100) CPU: Renesas Electronics R8A774A1 rev 1.3 Model: HopeRun HiHope RZ/G2M with sub board DRAM: 3.9 GiB MMC: mmc@ee100000: 0, mmc@ee160000: 1 Loading Environment from MMC... OK In: serial@e6e88000 Out: serial@e6e88000 Err: serial@e6e88000 Net: eth0: ethernet@e6800000 Hit any key to stop autoboot: 0 Regards, Biju Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647

5 years, 5 months

2
20
0 0

Re: [TF-A] commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms.

by Ash Wilding

Hi Biju, Andre, > sctlr_el3 = 0x0000000030c5183a The MMU is still disabled since we're so early in BL31, so nothing preventing us from making an actual access to physical address 0x0. As Andre already noted: > x30 = 0x0000000000000000 > elr_el3 = 0x0000000000000000 > far_el3 = 0x0000000000000000 It looks like we do have an errant null pointer dereference here. If I had to guess, the I-side successfully fetches a 32-bit word from physical address 0x0, but then fails to decode that bit pattern as a valid opcode. This is reported as "unknown reason", like you're seeing: <quote Arm ARM DDI 0487E.a pp D13-2963> This EC code is used for all exceptions that are not covered by any other EC value. This includes exceptions that are generated in the following situations: - ... - Instruction encodings that are unallocated. - ... </quote> Hope that helps, Ash.

5 years, 5 months

2
1
0 0

Re: [TF-A] commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms.

by Ash Wilding

From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Ash Wilding via TF-A <TF-A(a)lists.trustedfirmware.org> Date: Sunday, 11 October 2020 at 18:53 <...> It looks like we do have an errant null pointer dereference here. <...> Just to clarify, when I say "null pointer dereference": - you may be trampling over your stack, causing you to pop 0x0 into LR and return there; - you may be trampling over your stack, causing you to pop 0x0 into a GPR that is then BLR'd to; - you may be trampling over some other region of memory containing a function pointer, causing you to load 0x0 into a GPR that is then BLR'd to; - etc. Cheers, Ash.

5 years, 5 months

1
0
0 0

Questions raised about Measured Boot + fTPM test case

by Javier Almansa Sobrino

Hello all, Following up the question raised yesterday during the TF-A Tech Forum with regards to any modification needed on the Linux Kernel to run the test case that I was presenting (Measured Boot + fTPM service), I double checked today and I ran some tests on system and I can confirm that the test case works with the mainline Linux Kernel, with no modification other than enabling the driver on the DTB. The modules involved on the interaction with the fTPM (for this particular example) are: * optee.ko: Allows communication between the REE (unsecure world), the Trusted OS (secure world) and the tee-supplicant (unsecure world). * tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a char device. This also includes the reference implementation used on the test case. In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM. I would also like to highlight the following points: A) The test case is only meant to test the ability of the Measured Boot Driver and a TPM 2.0 compliant device to interact with each other. As such, we are not providing an fTPM meant to be used on a production environment. Instead, we are using an existing reference implementation to which we added support for Measured Boot to fulfil our needs for the test and use it as a functional example. The implementation details on how to interact with a particular TPM device (either firmware or discrete) can differ from the ones used on the test case as those details can be platform dependent. For example, we use an OPTEE TA fTPM on this example, but other platforms might use a discrete TPM or an fTPM running on a different Trusted OS. B) As stated on the presentation, we are undergoing internal review of the contributions done for the fTPM service to make it compatible with Measured Boot. Once the review is completed and the changes merged into the TPM repo mainline, we will update the TF-A documentation with instructions on how to download and build all the components to run the tests manually. Please, let me know in case you have any more questions. Best regards, Javier

5 years, 5 months

1
0
0 0

Re: [TF-A] commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms.

by Alexei Fedorov

Hi Biju, As you work with Renesas platforms, have you also seen "Renesas rcar-gen3: cert_header_sa6 Compilation Issue" which I reported on the mailing list on 10/12/2018 and is still not fixed? tools\renesas\rcar_layout_create\sa6.c has #include <stdint.h> which causes compilation error on Yocto 3.13: | aarch64-poky-linux-gcc -DRCAR_SA0_SIZE=1 -DRCAR_SA6_TYPE=0 -I../../include/lib/stdlib -D=AARCH64 -c -o sa6.o sa6.c | In file included from sa6.c:7:0: | /home/alexei/Work/Yocto_3.13_20181205/build/tmp/work/h3ulcb-poky-linux/arm-tf/2.0+gitAUTOINC+19b56cf4a2_556d7d9e3b-r0/recipe-sysroot-native/usr/lib/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory | # include_next <stdint.h> | ^~~~~~~~~~ | compilation terminated. | <builtin>: recipe for target 'sa6.o' failed | make[1]: *** [sa6.o] Error 1 | plat/renesas/rcar/platform.mk:403: recipe for target 'rcar_layout_tool' failed | make: *** [rcar_layout_tool] Error 2 | ERROR: oe_runmake failed There's no compilation error with gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf tool chain, because compiler searches for <stdint.h> in \gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf\lib\gcc\aarch64-elf\8.2.1\include finding "stdint.h" with # include_next <stdint.h> and then getting "stdint.h" from gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf\aarch64-elf\include folder. Trusted Firmware-A Porting Guide reads that "To avoid subtle toolchain behavioral dependencies, the header files provided by the compiler are not used. The software is built with the ``-nostdinc`` flag to ensure no headers are included from the toolchain inadvertently. ", tools\renesas\rcar_layout_create\makefile has flags defined as: CFLAGS += ${DEFINES} CFLAGS += -I../../include/lib/stdlib and adding "-nostdinc" flag will make gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf compilation fail because ../../include/lib/stdlib is a wrong path (taken from Renesas ARM-TF version 1.5 "tools\dummy_create\makefile") to include\lib\libc\stdint.h for version ARM-TF version 2.0. This issue can be fixed by changing CFLAGS to CFLAGS += -nostdinc \ -I../../../include/lib/libc \ -I../../../include/lib/libc/aarch64 Regards. Alexei. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Biju Das via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 09 October 2020 08:12 To: Andre Przywara <Andre.Przywara(a)arm.com>; TF-A(a)lists.trustedfirmware.org <TF-A(a)lists.trustedfirmware.org>; Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com>; Joanna Farley <Joanna.Farley(a)arm.com> Cc: Marek Vasut <marek.vasut(a)gmail.com>; Chris Paterson <Chris.Paterson2(a)renesas.com>; Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj(a)bp.renesas.com> Subject: Re: [TF-A] commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms. Hi Andre, Thanks for the feedback. > Subject: Re: commit 75fab6496e5fce9a11 ("libc: memset: improve > performance by avoiding single byte writes") causing BL31 boot failure on > Renesas RZ/G2 platforms. > > On 08/10/2020 20:05, Biju Das wrote: > > Hi, > > > I am porting Renesas RZ/G2M[1] platform to TF-A Master > > branch(commitid: eeb77da646844) . Initially faced a compilation error [2] > which is fixed by using "#define" instead of "static const uint64_t". > > What is your exact fix? That compilation error sounds like a more serious > issue, I am scratching my head how such a change would really fix things? Looks like this issue is related to toolchain, I was using aarch64-linux-gcc-7 on U-buntu 18.04 Host toolchain. The compilation is error is fixed by the below changes. #define BL31_RO_BASE BL_CODE_BASE #define BL31_RO_LIMIT BL_CODE_END #define BL31_COHERENT_RAM_BASE BL_COHERENT_RAM_BASE #define BL31_COHERENT_RAM_LIMIT BL_COHERENT_RAM_END The warning fix should not lead to compilation error with the old toolchains. It should be backward compatible to the old toolchains right? Please share your views. > And do you see this with mainline? I tried: Yes > $ make bl31 PLAT=rcar LSI=M3 MBEDTLS_DIR=../mbedtls.git on origin/master > and it built just fine. Thanks for the hint, After using the toolchain[1], I got the same results as your's. it compiles successfully. So the issue is related to using older tool chains. [1] https://developer.arm.com/tools-and-software/open-source-software/developer… > > > Then on target, found that BL31 is failed to boot[3], which is fixed > > by reverting the commit 75fab6496e5fce9a11 > > ("libc: memset: improve performance by avoiding single byte writes"), see > the logs [3]. > > Mmmh, interesting. Can you build with "DEBUG=1" to get more output from > BL31? Sure Will do and provide feedback. > I see some calls to memset() from code in drivers/renesas/rcar. > Can you add some debug prints at the top of memset() to dump the > parameters on each call? To see what breaks it? OK. > Are you using memset on some I/O memory, by any chance? And that > doesn't support all access types, like 64-bit stores? Will check and let you know. Cheers, Biju Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 5 months

2
2
0 0

Forthcoming Trusted Firmware-A 2.4 release

by Manish Badarkhe

Hi, This is to notify that we are planning to target the Trusted Firmware-A 2.4 release during the second week of November 2020 as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.3 release. As part of this, a release candidate tag will be created and release activities will commence from Friday 30th Oct 2020 (code freeze date). Essentially we will not merge any major enhancements from this date until the release is made. Please ensure any Pull Requests (PR’s) desired to make the 2.4 release are submitted in good time, to be completed by Tuesday 27th Oct 2020. Any major enhancement PR’s still open after that date will not be merged until after the release Please note, there is no guarantee that all patches under review will be merged before the code freeze date. Any patches that don’t make the code freeze date will complete their review and merge post the release date. Thanks Manish Badarkhe

5 years, 5 months

1
0
0 0

Compilation error with commit "ca661a0092c8ead5ac7df57c55fffcc835d9c0b9"

by Biju Das

Hi All, I am getting compilation error with Mainline TFA on renesas platform for bl31 build. Build command: #make CROSS_COMPILE=aarch64-linux-gnu- bl31 PLAT=rcar LSI=M3 MBEDTLS_DIR=../mbedtls Q1) Have any one see this issue? Please correct me, if I am doing something wrong. On further investigation, the below commit introduced the issue [1] [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/plat/ren… It gives compilation error " error: initializer element is not constant" for BL_CODE_BASE [2] [2] https://elixir.bootlin.com/arm-trusted-firmware/latest/source/plat/renesas/… BL_CODE_BASE gets its value from linker in [3] [3] https://elixir.bootlin.com/arm-trusted-firmware/latest/source/include/commo… If you see [4], the initializer element is not constant [4] https://elixir.bootlin.com/arm-trusted-firmware/latest/source/include/lib/u… Error logs: biju@biju-VirtualBox:~/work/trusted-firmware-a$ CC plat/renesas/rcar/bl31_plat_setup.c plat/renesas/rcar/bl31_plat_setup.c:25:39: error: initializer element is not constant static const uint64_t BL31_RO_BASE = BL_CODE_BASE; ^~~~~~~~~~~~ plat/renesas/rcar/bl31_plat_setup.c:26:40: error: initializer element is not constant static const uint64_t BL31_RO_LIMIT = BL_CODE_END; ^~~~~~~~~~~ plat/renesas/rcar/bl31_plat_setup.c:29:48: error: initializer element is not constant static const uint64_t BL31_COHERENT_RAM_BASE = BL_COHERENT_RAM_BASE; ^~~~~~~~~~~~~~~~~~~~ plat/renesas/rcar/bl31_plat_setup.c:30:49: error: initializer element is not constant static const uint64_t BL31_COHERENT_RAM_LIMIT = BL_COHERENT_RAM_END; ^~~~~~~~~~~~~~~~~~~ Makefile:1109: recipe for target '/home/biju/work/trusted-firmware-a/build/rcar/release/bl31/bl31_plat_setup.o' failed make: *** [/home/biju/work/trusted-firmware-a/build/rcar/release/bl31/bl31_plat_setup.o] Error 1 Regards, Biju Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647

5 years, 5 months

1
1
0 0

Re: [TF-A] Query SPD/SPMD behavior with EHF

by Achin Gupta

Hi Sandeep, A few comments inline from a SW architecture/FF-A perspective. > On 5 Oct 2020, at 12:28, Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Olivier, > Appreciate the details. I have a different perception of G0 > interrupts and their relevance to RAS/ critical events. > Comments in line. > Thanks > Sandeep > > On Fri, Oct 2, 2020 at 6:47 PM Olivier Deprez <Olivier.Deprez(a)arm.com> wrote: >> >> Hi Sandeep, >> >> Here are a few more details. >> The reasoning differs when considering pre-Armv8.4 platforms (1) vs Armv8.4 platforms onwards with secure virtualization enabled (2). >> >> Case (1): >> >> EHF framework unifies EL3 exceptions delivered via different vectors and allows them to be handled in a common way. It is also allowing exception delegation handling to lower secure ELs. This framework although primarily used for RAS, is also used for SDEI and platform EL3 interrupts. EL3's role in this case is about trapping and routing the event to appropriate the component (when the interrupt/exception is not handled solely at EL3). >> >> The interoperability between EHF and a Trusted OS is not accurately defined apart from this guidance in EHF documentation: >> "In order for S-EL1 software to handle Non-secure interrupts while having EHF enabled, the dispatcher must adopt a model where Non-secure interrupts are received at EL3, but are then synchronously handled over to S-EL1." >> >> Until then for the specific RAS handling scenario, this was delegated to a StandaloneMM partition running at S-EL0 (through the SPM-MM implementation) and not necessarily delegated to a TOS. > > Reliability is provided by the feature of G0 interrupt that it can not > be masked by lower ELs. Such interrupt being handled at EL3 or being > delegated to other components does not impact the > reliable feature of G0 interrupt. Sure its handling must be offloaded > to other components to keep EL3 firmware light. But If it were just > about handling an interrupt then it could have been entirely handled > in each state without even requiring an EL3 interrupt type. Reliability in RAS is a different concept. RAS error interrupts do not provide reliability. They report unreliable operation. Routing RAS interrupts to EL3 is an implementation choice called Firmware First Handling (FFH). Indeed, the interrupts could be routed to a lower EL which is called Kernel first handling (KFH). For e.g. an implementation could decide to handle corrected errors Kernel first. Uncorrected errors could be routed to a platform controller instead of firmware or be routed to both. There is no single solution. With FFH, the main requirement is that an uncorrected error must be handled even if the Normal world is not in a position to do so. There are non-technical requirements too but lets not go there. So I don’t think there is a requirement that "no lower EL" should be able to mask the interrupt. EL3/S-EL1 and EL3/S-EL2 are at the same privilege level as far as access to the physical address space is concerned. G0 interrupts could be routed to EL3 but they can be disabled by S-EL1 or S-EL2 by programming the GIC distributor. The main point being that software in all privileged exception levels in the Secure world must be trusted to handle RAS errors in the Normal world. Routing G0 interrupts to EL3 is not a silver bullet. When support for FFH was added to TF-A, there was no use case to put software in S-EL1. This EL is owned by TF-A which deploys a simple shim layer. The EHF was developed with this assumption in mind. If your requirement is to put a Trusted OS in S-EL1 and continue doing RAS error handling, then the requirements of the Trusted OS w.r.t the interrupt routing model must be factored in. Hence, the question about what exactly are your requirements. I can understand the desire to reuse EHF but it cannot come at the cost of not meeting the TOS requirements. It needs a SW architecture discussion first. It might be possible to preempt S-EL1 and route RAS errors to EL3 in some cases. A cooperative model (2) between S-EL1 and EL3 (as Olivier described) is what most Trusted OSs implement today. It would be good to understand why that would not work for RAS. > >> >> In order to better help you, we would need more information on the scenario you intend to achieve, and the environment (Arm architecture version and extensions, GIC version). >> Or maybe your question was out of curiosity for the longer term approach (2) as described below? > > As per sbsa level III spec: sbsa non secure watchdog WS1 (reset) must > be targeted at EL3. The patch in review ref: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5495 > And we would want a watchdog interrupt to preempt all execution > context. I would expect the same with any RAS or SDEI critical prio > events. Thanks for pointing this out! SBSA applies to the Server segment. It was reasonable to assume that Secure firmware almost entirely resides in EL3. Hence the guidance. We will look at rewording this in a future release. The intent is that since it is a Non-secure Watchdog, the WS1 signal must not be masked by the Normal world. The BSA applies to all segments. It leaves routing of WS1 implementation defined as long as the Normal world cannot mask it. It could be routed to S-EL1 or S-EL2 if that fulfils the requirement. > Another misc application of our platform is to be able to forcefully > turn off/ halt/ just ping any core at any execution context (S/NS). > These motivated me to leverage EHF. But the idea of dropping EHF in > future designs makes me think now ! > > Our current system is pre Armv8.4. We will stick to case (1). Case > (2) ie SPMD was just my quoricity. However, I felt PSA-FFA may > replace TOS specific SPDs someday. > Making SPMD relevant in this discussion even with pre 8.4 systems. > Because at least the TOS will have to follow one policy. The SPMD is indeed meant to replace TOS specific SPDs. It is meant to cater for the RAS use case as well. From an FF-A perspective, a cooperative approach is simpler. I would like to understand why this would not work for RAS error interrupts as well. Reuse of EHF is an implementation level discussion and I don’t think that is off the table even with (2). > >> >> Case (2): >> >> As a general rule, it is preferred that EL3 reduces its footprint and minimises platform specific handling code. > > Agreed. Applies to case(1) aswell and heavy lifting to be delegated > to lower ELs in either security states. My concern is on 'Taking' the > interrupt handling (mjust)can be delegated. It would certainly be desirable to reuse the EHF. However, it is not possible to delegate the heavy lifting to preempted software in S-EL1 or S-EL2 without significantly increasing their complexity. This is not the current direction of travel of FF-A. > >> EHF framework would most probably not be enabled at all. >> The priority logic provided by the GIC PMR register to mask NS interrupts cannot really work as before because all of trusted EL3/S-EL2 and untrusted S-EL1 SPs can manipulate this register. > > This is a limitation. This can be taken care of by cooperative > software design. ie. S_EL2/S_EL1 will not set PMR out of its range. > And the platform defines what's EL3 priority range. > GIC_LOWEST_EL3_PRI. This falls under the solution space. It would be good to understand what is it you want to run on S-EL1/S-EL2 first. > >> Any secure/non-secure interrupt triggered while running SEL1/SEL0 is trapped first by the S-EL2 firmware (or the so-called SPMC). This translates into SCR_EL3.FIQ/IRQ=0 in the secure world. >> Group1NS interrupts are redirected to SPMD for routing to NWd. >> >> A Group0 interrupt is possibly redirected to a platform driver into an S-EL1 secure partition (e.g. a RAS handling service). >> Hence it does no longer hold true that Group0 interrupts are necessarily qualified as "EL3 interrupts". >> It is still possible to redirect Group0 interrupts from S-EL2 to EL3 and be handled there, but as said, this is a less preferred approach. >> >> Either way when NWd runs (with SCR_EL3.FIQ=1/IRQ=0), a Group1S/Group0 secure interrupt is trapped at EL3 and routed to SPMD then SPMC. >> The SPMC can take the decision to resume the secure partition which registered the corresponding secure INTID. >> >> This design does mean that SDEI interrupt handling would need SPMC and BL31 collaboration and this is something we are working on. > > I understood this scheme. But it means RAS interrupts and other > critical events will always have blackout periods even with proper > software design. RAS interrupts will have blackout periods even if a SMC is handled entirely in EL3. How is routing them to S-EL1 or S-EL2 any different? Afaiu, the RAS architecture spec does not lay down any time limits on by when an error must be reported. All RAS errors are not critical errors. Even critical errors e.g. uncontainable errors report something that has already happened. With unrecoverable errors, ESBs ensure that the problem is contained to a particular EL or Security state. Could you elaborate on what timing requirements you have and why a cooperative model would cause problems? > Whereas with the other routing model scheme the reliability of EHF > handlers can be retained with the constraint of PMR ranges. There may > be something > I am missing. I don’t think “reliability” is an argument here. It is about reusing the EHF in EL3. It is not off the table but we cannot overlook other evolutions in the software and hardware architecture since the EHF was written. Let me know what you think. Cheers, Achin > >> >> Hope this helps. >> >> Regards, >> Olivier. >> >> >> ________________________________________ >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Olivier Deprez via TF-A <tf-a(a)lists.trustedfirmware.org> >> Sent: 28 September 2020 14:01 >> To: Sandeep Tripathy; Soby Mathew >> Cc: tf-a(a)lists.trustedfirmware.org; nd >> Subject: Re: [TF-A] Query SPD/SPMD behavior with EHF >> >> Hi Sandeep, >> >> Your question is very valid and we're discussing options internally. >> >> We will come back to you with a consolidated answer shortly. >> >> Regards, >> Olivier. >> >> ________________________________________ >> From: Sandeep Tripathy >> Sent: Monday, September 28, 2020 05:28 >> To: Soby Mathew >> Cc: Dan Handley; tf-a(a)lists.trustedfirmware.org; nd; Olivier Deprez >> Subject: Re: [TF-A] Query SPD/SPMD behavior with EHF >> >> >> Thanks Soby and Dan for confirmation on TSPD. I can see a few more gaps >> in the related area. >> >> "The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast >> SMC i.e. any execution context for that matter ". >> This should apply to all SPDs including SPMD. However I learned from >> @Oliver that SPMD/SPMC design traps FIQs to S_EL2. >> >> In that case a RAS interrupt can be masked by S_EL2 software (eg: >> Hafnium). Probably by design it will be ensured that S_EL2 will never >> mask the physical FIQ ? >> >> S_EL2 FIQ handler will exit to EL3/SPMD by SMC call. And depending on >> the pending interrupt type either it can exit to NWd OR invoke el3 fiq >> vector handler synchronously ? >> >> Are there limitations if we trap fiq to EL3 instead ? >> >> Thanks >> Sandeep >> On Fri, Sep 18, 2020 at 6:26 PM Soby Mathew <Soby.Mathew(a)arm.com> wrote: >>> >>> Hi Sandeep >>> >>>> Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECUE);’ is in effect. Intention is to avoid NS interrupt preempt secure execution (Fast SMC). >>>> But I think that will also disable G0 interrupt as both NS interrupt and G0 interrupt are on FIQ. >>>> EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. >>>> This is my understanding from the code please confirm if this is correct. >>> >>> The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC. Hence the usage of GIC PMR to mask the NS interrupts. As Dan says, the TSP_NS_INTR_ASYNC_PREEMPT predates the EHF design and it seems there is a problem as you describe. >>> >>>> EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. >>>> This is my understanding from the code please confirm if this is correct. >>> >>> You are right. Routing model manipulation is not required when EL3 interrupts are present as GIC PMR manipulation should take care of the required behaviour for yielding vs atomic SMC. You also need to ensure it works as expected when EL3 interrupts are not enabled and when EHF is disabled. >>> >>> Best Regards >>> Soby Mathew >>> >>>> -----Original Message----- >>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep >>>> Tripathy via TF-A >>>> Sent: 17 September 2020 16:53 >>>> To: Dan Handley <Dan.Handley(a)arm.com> >>>> Cc: tf-a(a)lists.trustedfirmware.org >>>> Subject: Re: [TF-A] Query TSPD behavior with EHF >>>> >>>> Hi Dan, >>>> I am not sure if this is mentioned anywhere in any documents but I think >>>> EHF handlers should be able to preempt all execution contexts at lower ELs >>>> and lower ELs should never be able to mask such interrupts. >>>> If the behavioral expectation is set the implementation can be fixed. >>>> >>>> Thanks >>>> Sandeep >>>> >>>> On Thu, Sep 17, 2020 at 7:57 PM Dan Handley via TF-A <tf- >>>> a(a)lists.trustedfirmware.org> wrote: >>>>> >>>>> A correction... >>>>> >>>>>> -----Original Message----- >>>>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan >>>>>> Handley via TF-A >>>>>> Sent: 17 September 2020 15:14 >>>>>>>> >>>>>>>> I want to handle something similar in OP-TEED along with EHF >>>>>>>> depending on >>>>>>> what is the expected behavior. >>>>>>>> >>>>>> Hmm, I thought OP-TEED was more like the >>>> TSP_NS_INTR_ASYNC_PREEMPT=0 >>>>>> case, where NS interrupts are routed to S-EL1 while processing a >>>>>> yielding SMC in S- EL1? Perhaps that's a better TSPD config for you to >>>> follow? >>>>>> >>>>> Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are >>>> routed to EL3 first, but the TSPD re-enables NS interrupts before handing >>>> over to the TSP to handle yielding calls, via a call to >>>> ehf_allow_ns_preemption. >>>>> >>>> >>>> Right, that is the case for yielding SMC handling where both NS interrupts >>>> and EL3/G0 interrupts can preempt the S_EL1/S_EL2 context. >>>> But I would expect the same routing model even for 'Fast SMC' unlike what is >>>> happening in TSPD. >>>> >>>>> Dan. >>>>> >>>>> -- >>>>> 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 >> >> >> -- >> 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

5 years, 5 months

2
1
0 0

Re: [TF-A] Nailgun

by Joanna Farley

Hi Varun, The Arm security support pages provides official responses to questions related to security vulnerabilities. [https://developer.arm.com/support/arm-security-updates] Trustedfirmware.org provides Security Centre pages covering the security incident handling and vulnerability disclosure process for hosted projects. [https://developer.trustedfirmware.org/w/collaboration/security_center/] You can find information regarding Nailgun on the following Arm security support FAQ page [https://developer.arm.com/support/arm-security-updates/speculative-processo…]. If you have further questions then please email arm-security(a)arm.com<mailto:arm-security@arm.com> as mentioned in the Arm security support pages. Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Varun Wadekar <vwadekar(a)nvidia.com> Date: Monday, 28 September 2020 at 21:53 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Nailgun Hi, Recently, I learned about Nailgun [1] – leak information by snooping across privilege boundaries with the help of CoreSight. The proof of concept uses Raspberry Pi3 (uses Cortex A-53 CPUs) platform to demonstrate the exploit. Has anyone reviewed this attack and does it affect other Arm v8 CPUs too? Do we have support in TF-A to disable CoreSight to mitigate against such attacks? Are there any other mitigations against this attack? -Varun [1] https://github.com/ningzhenyu/nailgun

5 years, 5 months

2
1
0 0

TF-A LTS wiki page

by Varun Wadekar

Hello team, After the recent discussion in the tech forums for the need of a LTS release, I have create a wiki page [1] on tf.org to discuss how we should move forward. The page is expected to be a "live" document and the intention is to allow the community to capture current problems and expectations from the LTS version. Request you to review the page and provide feedback. Thanks, -Varun [1] https://developer.trustedfirmware.org/w/tf_a/lts_proposal/

5 years, 5 months

1
0
0 0

Re: [TF-A] BL31 as bootloader

by Alexei Fedorov

Hi Ravi, Have you tried to use RESET_TO_BL31 build option for your platform? Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 07 October 2020 17:01 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] BL31 as bootloader Hi, I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can specify this container image with both bl31.bin and a separate custom app at a give flash address. This is without any security requirements or dependencies. Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point 0x80020000 address ? Thanks in advance. Ravi -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 5 months

2
1
0 0

BL31 as bootloader

by rkohli2000 gmail

Hi, I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can specify this container image with both bl31.bin and a separate custom app at a give flash address. This is without any security requirements or dependencies. Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point 0x80020000 address ? Thanks in advance. Ravi

5 years, 5 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 8th October 2020 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 8th October 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: * Measured Boot Support in TF-A * Presented by Alexei Fedorov and Javier Almansa Sobrino * Update on the support for Measured Boot in TF-A along with an overview of test cases for integration with a TPM service * 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

5 years, 5 months

1
0
0 0

TF-A image construction

by rkohli2000 gmail

Hi, Sorry for the wide distribution and if this isn't the appropriate board. I'm interested in TF-A image construction for the i.MX8QM SoC platform and basic image construction instructions. I'd like to understand how to deploy a user application for the Cortex-A53 core and flash image construction. For example, how to deploy BL31.bin and launch a user app for the platform and what does the following TF-A console log imply for user apps: INFO: Entry point address = 0x80020000 INFO: SPSR = 0x3c9 Any intro info is appreciated. Thanks again. Regards Ravi

5 years, 5 months

1
0
0 0

Re: [TF-A] Query SPD/SPMD behavior with EHF

by Olivier Deprez

Hi Sandeep, Here are a few more details. The reasoning differs when considering pre-Armv8.4 platforms (1) vs Armv8.4 platforms onwards with secure virtualization enabled (2). Case (1): EHF framework unifies EL3 exceptions delivered via different vectors and allows them to be handled in a common way. It is also allowing exception delegation handling to lower secure ELs. This framework although primarily used for RAS, is also used for SDEI and platform EL3 interrupts. EL3's role in this case is about trapping and routing the event to appropriate the component (when the interrupt/exception is not handled solely at EL3). The interoperability between EHF and a Trusted OS is not accurately defined apart from this guidance in EHF documentation: "In order for S-EL1 software to handle Non-secure interrupts while having EHF enabled, the dispatcher must adopt a model where Non-secure interrupts are received at EL3, but are then synchronously handled over to S-EL1." Until then for the specific RAS handling scenario, this was delegated to a StandaloneMM partition running at S-EL0 (through the SPM-MM implementation) and not necessarily delegated to a TOS. In order to better help you, we would need more information on the scenario you intend to achieve, and the environment (Arm architecture version and extensions, GIC version). Or maybe your question was out of curiosity for the longer term approach (2) as described below? Case (2): As a general rule, it is preferred that EL3 reduces its footprint and minimises platform specific handling code. EHF framework would most probably not be enabled at all. The priority logic provided by the GIC PMR register to mask NS interrupts cannot really work as before because all of trusted EL3/S-EL2 and untrusted S-EL1 SPs can manipulate this register. Any secure/non-secure interrupt triggered while running SEL1/SEL0 is trapped first by the S-EL2 firmware (or the so-called SPMC). This translates into SCR_EL3.FIQ/IRQ=0 in the secure world. Group1NS interrupts are redirected to SPMD for routing to NWd. A Group0 interrupt is possibly redirected to a platform driver into an S-EL1 secure partition (e.g. a RAS handling service). Hence it does no longer hold true that Group0 interrupts are necessarily qualified as "EL3 interrupts". It is still possible to redirect Group0 interrupts from S-EL2 to EL3 and be handled there, but as said, this is a less preferred approach. Either way when NWd runs (with SCR_EL3.FIQ=1/IRQ=0), a Group1S/Group0 secure interrupt is trapped at EL3 and routed to SPMD then SPMC. The SPMC can take the decision to resume the secure partition which registered the corresponding secure INTID. This design does mean that SDEI interrupt handling would need SPMC and BL31 collaboration and this is something we are working on. Hope this helps. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Olivier Deprez via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 28 September 2020 14:01 To: Sandeep Tripathy; Soby Mathew Cc: tf-a(a)lists.trustedfirmware.org; nd Subject: Re: [TF-A] Query SPD/SPMD behavior with EHF Hi Sandeep, Your question is very valid and we're discussing options internally. We will come back to you with a consolidated answer shortly. Regards, Olivier. ________________________________________ From: Sandeep Tripathy Sent: Monday, September 28, 2020 05:28 To: Soby Mathew Cc: Dan Handley; tf-a(a)lists.trustedfirmware.org; nd; Olivier Deprez Subject: Re: [TF-A] Query SPD/SPMD behavior with EHF Thanks Soby and Dan for confirmation on TSPD. I can see a few more gaps in the related area. "The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC i.e. any execution context for that matter ". This should apply to all SPDs including SPMD. However I learned from @Oliver that SPMD/SPMC design traps FIQs to S_EL2. In that case a RAS interrupt can be masked by S_EL2 software (eg: Hafnium). Probably by design it will be ensured that S_EL2 will never mask the physical FIQ ? S_EL2 FIQ handler will exit to EL3/SPMD by SMC call. And depending on the pending interrupt type either it can exit to NWd OR invoke el3 fiq vector handler synchronously ? Are there limitations if we trap fiq to EL3 instead ? Thanks Sandeep On Fri, Sep 18, 2020 at 6:26 PM Soby Mathew <Soby.Mathew(a)arm.com> wrote: > > Hi Sandeep > > > Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECUE);’ is in effect. Intention is to avoid NS interrupt preempt secure execution (Fast SMC). > > But I think that will also disable G0 interrupt as both NS interrupt and G0 interrupt are on FIQ. > > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > > This is my understanding from the code please confirm if this is correct. > > The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC. Hence the usage of GIC PMR to mask the NS interrupts. As Dan says, the TSP_NS_INTR_ASYNC_PREEMPT predates the EHF design and it seems there is a problem as you describe. > > > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > > This is my understanding from the code please confirm if this is correct. > > You are right. Routing model manipulation is not required when EL3 interrupts are present as GIC PMR manipulation should take care of the required behaviour for yielding vs atomic SMC. You also need to ensure it works as expected when EL3 interrupts are not enabled and when EHF is disabled. > > Best Regards > Soby Mathew > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > > Tripathy via TF-A > > Sent: 17 September 2020 16:53 > > To: Dan Handley <Dan.Handley(a)arm.com> > > Cc: tf-a(a)lists.trustedfirmware.org > > Subject: Re: [TF-A] Query TSPD behavior with EHF > > > > Hi Dan, > > I am not sure if this is mentioned anywhere in any documents but I think > > EHF handlers should be able to preempt all execution contexts at lower ELs > > and lower ELs should never be able to mask such interrupts. > > If the behavioral expectation is set the implementation can be fixed. > > > > Thanks > > Sandeep > > > > On Thu, Sep 17, 2020 at 7:57 PM Dan Handley via TF-A <tf- > > a(a)lists.trustedfirmware.org> wrote: > > > > > > A correction... > > > > > > > -----Original Message----- > > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan > > > > Handley via TF-A > > > > Sent: 17 September 2020 15:14 > > > > > > > > > > > > I want to handle something similar in OP-TEED along with EHF > > > > > > depending on > > > > > what is the expected behavior. > > > > > > > > > > Hmm, I thought OP-TEED was more like the > > TSP_NS_INTR_ASYNC_PREEMPT=0 > > > > case, where NS interrupts are routed to S-EL1 while processing a > > > > yielding SMC in S- EL1? Perhaps that's a better TSPD config for you to > > follow? > > > > > > > Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are > > routed to EL3 first, but the TSPD re-enables NS interrupts before handing > > over to the TSP to handle yielding calls, via a call to > > ehf_allow_ns_preemption. > > > > > > > Right, that is the case for yielding SMC handling where both NS interrupts > > and EL3/G0 interrupts can preempt the S_EL1/S_EL2 context. > > But I would expect the same routing model even for 'Fast SMC' unlike what is > > happening in TSPD. > > > > > Dan. > > > > > > -- > > > 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 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 5 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. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 362943: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 362943: Insecure data handling (TAINTED_SCALAR) /common/fdt_fixup.c: 437 in fdt_adjust_gic_redist() 431 432 /* 433 * The redistributor is described in the second "reg" entry. 434 * So we have to skip one address and one size cell, then another 435 * address cell to get to the second size cell. 436 */ >>> CID 362943: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "sc * 4" to a tainted sink. 437 return fdt_setprop_inplace_namelen_partial(dtb, offset, "reg", 3, 438 (ac + sc + ac) * 4, 439 val, sc * 4); ** CID 362942: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /common/fdt_fixup.c: 428 in fdt_adjust_gic_redist() ________________________________________________________________________________________________________ *** CID 362942: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /common/fdt_fixup.c: 428 in fdt_adjust_gic_redist() 422 } 423 424 if (sc == 1) { 425 redist_size_32 = cpu_to_fdt32(nr_cores * gicr_frame_size); 426 val = &redist_size_32; 427 } else { >>> CID 362942: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "nr_cores * gicr_frame_size" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 428 redist_size_64 = cpu_to_fdt64(nr_cores * gicr_frame_size); 429 val = &redist_size_64; 430 } 431 432 /* 433 * The redistributor is described in the second "reg" entry. ** CID 362941: Integer handling issues (BAD_SHIFT) /mbedtls/library/bignum.c: 1713 in mbedtls_int_div_int() ________________________________________________________________________________________________________ *** CID 362941: Integer handling issues (BAD_SHIFT) /mbedtls/library/bignum.c: 1713 in mbedtls_int_div_int() 1707 * Normalize the divisor, d, and dividend, u0, u1 1708 */ 1709 s = mbedtls_clz( d ); 1710 d = d << s; 1711 1712 u1 = u1 << s; >>> CID 362941: Integer handling issues (BAD_SHIFT) >>> In expression "u0 >> 64UL - s", right shifting by more than 63 bits has undefined behavior. The shift amount, "64UL - s", is 64. 1713 u1 |= ( u0 >> ( biL - s ) ) & ( -(mbedtls_mpi_sint)s >> ( biL - 1 ) ); 1714 u0 = u0 << s; 1715 1716 d1 = d >> biH; 1717 d0 = d & uint_halfword_mask; 1718 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

5 years, 5 months

1
0
0 0

STM32MP1: Adding TF-A causes kernel errors

by Jan Kiszka

Hi Yann, not sure if TF-A is the one to blame, but it's the variable that triggers the following on the STM32MP15x eval board for me. I think I'm following tfa/docs/plat/stm32mp1.rst and u-boot/doc/board/st/stm32mp1.rst correctly. Working: - U-Boot 2020.07, stm32mp15_basic_defconfig - Linux 5.9-rc7 (or 5.4.x), defconfig [ 0.000000] Memory: 815540K/917500K available (13312K kernel code, 1800K rwdata, 5452K rodata, 2048K init, 407K bss, 36424K reserved, 65536K cma-reserved, 196604K highmem) Failing: - TF-A 2.3, PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 \ AARCH32_SP=sp_min STM32MP_SDMMC=1 STM32MP_EMMC=1 STM32MP_RAW_NAND=1 \ STM32MP_SPI_NAND=1 STM32MP_SPI_NOR=1 DTB_FILE_NAME=stm32mp157c-ev1.dtb - U-Boot 2020.07, stm32mp15_trusted_defconfig - Linux as above [ 0.000000] Memory: 881076K/917500K available (13312K kernel code, 1800K rwdata, 5452K rodata, 2048K init, 407K bss, 4294938184K reserved, 65536K cma-reserved, 262140K highmem) which causes issues like [ 0.047215] BUG: Bad page state in process swapper/0 pfn:fa000 [ 0.047236] page:(ptrval) refcount:0 mapcount:-128 mapping:00000000 index:0x1 pfn:0xfa000 [ 0.047249] flags: 0x80000000() CMA [ 0.047273] raw: 80000000 e7f29004 e7f49004 00000000 00000001 0000000b ffffff7f 00000000 [ 0.047281] page dumped because: nonzero mapcount [ 0.047287] Modules linked in: [ 0.047305] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc7 #1 [ 0.047314] Hardware name: STM32 (Device Tree Support) [ 0.047358] [<c0311708>] (unwind_backtrace) from [<c030b88c>] (show_stack+0x10/0x14) [ 0.047384] [<c030b88c>] (show_stack) from [<c0718a40>] (dump_stack+0xc8/0xdc) [ 0.047408] [<c0718a40>] (dump_stack) from [<c047b3c8>] (bad_page+0xdc/0x10c) [ 0.047426] [<c047b3c8>] (bad_page) from [<c047c060>] (__free_pages_ok+0x2e8/0x36c) [ 0.047447] [<c047c060>] (__free_pages_ok) from [<c1623a80>] (init_cma_reserved_pageblock+0x58/0x68) [ 0.047469] [<c1623a80>] (init_cma_reserved_pageblock) from [<c16266c8>] (cma_init_reserved_areas+0x170/0x1c8) [ 0.047491] [<c16266c8>] (cma_init_reserved_areas) from [<c0301ef8>] (do_one_initcall+0x54/0x22c) [ 0.047513] [<c0301ef8>] (do_one_initcall) from [<c160102c>] (kernel_init_freeable+0x188/0x1ec) [ 0.047537] [<c160102c>] (kernel_init_freeable) from [<c0f4a340>] (kernel_init+0x8/0x118) [ 0.047559] [<c0f4a340>] (kernel_init) from [<c03001a8>] (ret_from_fork+0x14/0x2c) [ 0.047570] Exception stack(0xe68b7fb0 to 0xe68b7ff8) [ 0.047584] 7fa0: 00000000 00000000 00000000 00000000 [ 0.047600] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 0.047614] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 0.047624] Disabling lock debugging due to kernel taint Still, the system boots, and I can login. That reserved value the kernel finds is obviously off. Does it come from TF-A, is U-Boot causing this in the presence of TF-A, or is the kernel itself getting it wrong? Or am I missing some switch that is not in the kernel defconfig? Thanks, Jan

5 years, 5 months

2
5
0 0

Re: [TF-A] Tests to verify BP_OPTION

by Alexei Fedorov

Hi, tf-a-tests\tftf\tests\extensions\pauth\test_pauth.c will test fvp-pauth-pac-ret-leaf-sdei,fvp-pauth-standard:fvp-tftf-fip.tftf-aemv8a.8_5-debug fvp-pauth-pac-ret-leaf-tsp-sdei,fvp-pauth-standard:fvp-tftf-fip.tftf-aemv8a.8_5-debug CI configurations. Alexei Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Kalyani Chidambaram Vaidyanathan via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 23 September 2020 18:25 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Tests to verify BP_OPTION Hi, Is there any test to verify the BP_OPTION feature set to “pac-ret+leaf” ? When BRANCH_PROTECTION is set to “3”, BP_OPTION is set to “pac-ret+leaf”. Reference code - https://github.com/ARM-software/arm-trusted-firmware/blob/master/Makefile Thanks, Kalyani

5 years, 5 months

2
2
0 0

a80x0_mcbin doesn't build with recommended mv-ddr-marvell

by Jan Kiszka

Hi all, docs/plat/marvell/armada/build.rst says that you should use branch mv_ddr-armada-atf-mainline from [1]. But that no longer works with tf-a master. The mv-ddr-devel branch builds fine (didn't run the result, though). make CROSS_COMPILE=aarch64-linux-gnu- PLAT=a80x0_mcbin \ USE_COHERENT_MEM=0 MV_DDR_PATH=.../mv-ddr-marvell/ \ SCP_BL2=.../mrvl_scp_bl2.img Are there plans to update the tf-a doc or rather refresh that branch? Jan [1] https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git

5 years, 5 months

2
2
0 0

Nailgun

by Varun Wadekar

Hi, Recently, I learned about Nailgun [1] - leak information by snooping across privilege boundaries with the help of CoreSight. The proof of concept uses Raspberry Pi3 (uses Cortex A-53 CPUs) platform to demonstrate the exploit. Has anyone reviewed this attack and does it affect other Arm v8 CPUs too? Do we have support in TF-A to disable CoreSight to mitigate against such attacks? Are there any other mitigations against this attack? -Varun [1] https://github.com/ningzhenyu/nailgun

5 years, 5 months

1
0
0 0

Re: [TF-A] Query SPD/SPMD behavior with EHF

by Olivier Deprez

Hi Sandeep, Your question is very valid and we're discussing options internally. We will come back to you with a consolidated answer shortly. Regards, Olivier. ________________________________________ From: Sandeep Tripathy Sent: Monday, September 28, 2020 05:28 To: Soby Mathew Cc: Dan Handley; tf-a(a)lists.trustedfirmware.org; nd; Olivier Deprez Subject: Re: [TF-A] Query SPD/SPMD behavior with EHF Thanks Soby and Dan for confirmation on TSPD. I can see a few more gaps in the related area. "The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC i.e. any execution context for that matter ". This should apply to all SPDs including SPMD. However I learned from @Oliver that SPMD/SPMC design traps FIQs to S_EL2. In that case a RAS interrupt can be masked by S_EL2 software (eg: Hafnium). Probably by design it will be ensured that S_EL2 will never mask the physical FIQ ? S_EL2 FIQ handler will exit to EL3/SPMD by SMC call. And depending on the pending interrupt type either it can exit to NWd OR invoke el3 fiq vector handler synchronously ? Are there limitations if we trap fiq to EL3 instead ? Thanks Sandeep On Fri, Sep 18, 2020 at 6:26 PM Soby Mathew <Soby.Mathew(a)arm.com> wrote: > > Hi Sandeep > > > Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECUE);’ is in effect. Intention is to avoid NS interrupt preempt secure execution (Fast SMC). > > But I think that will also disable G0 interrupt as both NS interrupt and G0 interrupt are on FIQ. > > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > > This is my understanding from the code please confirm if this is correct. > > The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC. Hence the usage of GIC PMR to mask the NS interrupts. As Dan says, the TSP_NS_INTR_ASYNC_PREEMPT predates the EHF design and it seems there is a problem as you describe. > > > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > > This is my understanding from the code please confirm if this is correct. > > You are right. Routing model manipulation is not required when EL3 interrupts are present as GIC PMR manipulation should take care of the required behaviour for yielding vs atomic SMC. You also need to ensure it works as expected when EL3 interrupts are not enabled and when EHF is disabled. > > Best Regards > Soby Mathew > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > > Tripathy via TF-A > > Sent: 17 September 2020 16:53 > > To: Dan Handley <Dan.Handley(a)arm.com> > > Cc: tf-a(a)lists.trustedfirmware.org > > Subject: Re: [TF-A] Query TSPD behavior with EHF > > > > Hi Dan, > > I am not sure if this is mentioned anywhere in any documents but I think > > EHF handlers should be able to preempt all execution contexts at lower ELs > > and lower ELs should never be able to mask such interrupts. > > If the behavioral expectation is set the implementation can be fixed. > > > > Thanks > > Sandeep > > > > On Thu, Sep 17, 2020 at 7:57 PM Dan Handley via TF-A <tf- > > a(a)lists.trustedfirmware.org> wrote: > > > > > > A correction... > > > > > > > -----Original Message----- > > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan > > > > Handley via TF-A > > > > Sent: 17 September 2020 15:14 > > > > > > > > > > > > I want to handle something similar in OP-TEED along with EHF > > > > > > depending on > > > > > what is the expected behavior. > > > > > > > > > > Hmm, I thought OP-TEED was more like the > > TSP_NS_INTR_ASYNC_PREEMPT=0 > > > > case, where NS interrupts are routed to S-EL1 while processing a > > > > yielding SMC in S- EL1? Perhaps that's a better TSPD config for you to > > follow? > > > > > > > Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are > > routed to EL3 first, but the TSPD re-enables NS interrupts before handing > > over to the TSP to handle yielding calls, via a call to > > ehf_allow_ns_preemption. > > > > > > > Right, that is the case for yielding SMC handling where both NS interrupts > > and EL3/G0 interrupts can preempt the S_EL1/S_EL2 context. > > But I would expect the same routing model even for 'Fast SMC' unlike what is > > happening in TSPD. > > > > > Dan. > > > > > > -- > > > 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

5 years, 5 months

1
0
0 0

Re: [TF-A] Query SPD/SPMD behavior with EHF

by Sandeep Tripathy

Thanks Soby and Dan for confirmation on TSPD. I can see a few more gaps in the related area. "The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC i.e. any execution context for that matter ". This should apply to all SPDs including SPMD. However I learned from @Oliver that SPMD/SPMC design traps FIQs to S_EL2. In that case a RAS interrupt can be masked by S_EL2 software (eg: Hafnium). Probably by design it will be ensured that S_EL2 will never mask the physical FIQ ? S_EL2 FIQ handler will exit to EL3/SPMD by SMC call. And depending on the pending interrupt type either it can exit to NWd OR invoke el3 fiq vector handler synchronously ? Are there limitations if we trap fiq to EL3 instead ? Thanks Sandeep On Fri, Sep 18, 2020 at 6:26 PM Soby Mathew <Soby.Mathew(a)arm.com> wrote: > > Hi Sandeep > > > Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECUE);’ is in effect. Intention is to avoid NS interrupt preempt secure execution (Fast SMC). > > But I think that will also disable G0 interrupt as both NS interrupt and G0 interrupt are on FIQ. > > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > > This is my understanding from the code please confirm if this is correct. > > The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC. Hence the usage of GIC PMR to mask the NS interrupts. As Dan says, the TSP_NS_INTR_ASYNC_PREEMPT predates the EHF design and it seems there is a problem as you describe. > > > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > > This is my understanding from the code please confirm if this is correct. > > You are right. Routing model manipulation is not required when EL3 interrupts are present as GIC PMR manipulation should take care of the required behaviour for yielding vs atomic SMC. You also need to ensure it works as expected when EL3 interrupts are not enabled and when EHF is disabled. > > Best Regards > Soby Mathew > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > > Tripathy via TF-A > > Sent: 17 September 2020 16:53 > > To: Dan Handley <Dan.Handley(a)arm.com> > > Cc: tf-a(a)lists.trustedfirmware.org > > Subject: Re: [TF-A] Query TSPD behavior with EHF > > > > Hi Dan, > > I am not sure if this is mentioned anywhere in any documents but I think > > EHF handlers should be able to preempt all execution contexts at lower ELs > > and lower ELs should never be able to mask such interrupts. > > If the behavioral expectation is set the implementation can be fixed. > > > > Thanks > > Sandeep > > > > On Thu, Sep 17, 2020 at 7:57 PM Dan Handley via TF-A <tf- > > a(a)lists.trustedfirmware.org> wrote: > > > > > > A correction... > > > > > > > -----Original Message----- > > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan > > > > Handley via TF-A > > > > Sent: 17 September 2020 15:14 > > > > > > > > > > > > I want to handle something similar in OP-TEED along with EHF > > > > > > depending on > > > > > what is the expected behavior. > > > > > > > > > > Hmm, I thought OP-TEED was more like the > > TSP_NS_INTR_ASYNC_PREEMPT=0 > > > > case, where NS interrupts are routed to S-EL1 while processing a > > > > yielding SMC in S- EL1? Perhaps that's a better TSPD config for you to > > follow? > > > > > > > Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are > > routed to EL3 first, but the TSPD re-enables NS interrupts before handing > > over to the TSP to handle yielding calls, via a call to > > ehf_allow_ns_preemption. > > > > > > > Right, that is the case for yielding SMC handling where both NS interrupts > > and EL3/G0 interrupts can preempt the S_EL1/S_EL2 context. > > But I would expect the same routing model even for 'Fast SMC' unlike what is > > happening in TSPD. > > > > > Dan. > > > > > > -- > > > 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

5 years, 5 months

1
0
0 0

When to implement plat_sdei_validate_entry_point?

by Jan Kiszka

Hi, I'm adding basic SDEI support to the zynqmp platform (just private event 0 for now), and I'm wondering what to do with plat_sdei_validate_entry_point(). Looking around what other SDEI implementations did, neither tegra nor the recently added imx8mm implement this and rather rely on the empty stub from plat/common/aarch64/plat_common.c. As zynqmp also pulls in plat/arm/common/arm_common.c and doesn't find any arm_validate_ns_entrypoint, my search started. Is there anything that makes the check for tegra and imx8mm unneeded? Or are they both broken and should better use plat_sdei_validate_entry_point from plat/arm/common/arm_common.c? Thanks, Jan

5 years, 5 months

2
3
0 0

Re: [TF-A] TF-A warm reboot question

by Soby Mathew

Hi Maxim, There could be some terminology mixup that needs to be clarified. These are the typical words related to boot in TF-A: 1. cold boot : This is the first boot after a power cycle. Typically a single CPU is powered up and executed the entire boot flow upto linux 2. Warm boot: The Cold boot has completed and transitioned into Linux kernel and then the kernel invokes PSCI_CPU_ON to power up the secondary CPUs. This is the CPU `hotplug` operation from linux side. The figure you referred to mentions these boot scenarios. Now reboot is system reset + cold boot. Ideally if QEMU has to support reboot, it needs to be able to reset the system (CPUs and peripherals) from software. The flow you suggest for QEMU could work but if the CPU and the peripherals are not reset properly, you could encounter errors later on because software could assume reset values for some registers and hence may not initialize it. Also there are registers that are 1 time write and cannot be written to again without proper reset cycle, and these could problems during execution. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Maxim > Uvarov via TF-A > Sent: 24 September 2020 13:27 > To: Maxim Uvarov <maxim.uvarov(a)linaro.org> > Cc: tf-a(a)lists.trustedfirmware.org; Ilias Apalodimas > <ilias.apalodimas(a)linaro.org>; Arnd Bergmann <arnd(a)linaro.org> > Subject: Re: [TF-A] TF-A warm reboot question > > sorry, wrong email thread. > > Another way around is to not support "hot reset" in ATF, but make qemu > reboot is implement some watchdog for qemu virt platform. That also works > for me with quick implementation with lhe link which I sent in the previous > email. > > Maxim. > > On Thu, 24 Sep 2020 at 15:16, Maxim Uvarov via TF-A <tf- > a(a)lists.trustedfirmware.org> wrote: > > > > I.e. that implementation works for me: > > > https://github.com/muvarov/qemu/commit/f5e3fb83170613a9eed46b87358 > ab2e > > 37de260a2 > > > > On Mon, 21 Sep 2020 at 18:16, Maxim Uvarov <maxim.uvarov(a)linaro.org> > wrote: > > > > > > Hello, > > > > > > I'm trying to understand why "warm reboot" is not currently > > > implemented in TF-A for qemu targets. I.e. in case of qemu armv8 > > > boot > > > atf->optee->uboot->linux and then reboot, cpu jumps to BL31 > > > qemu_system_reset() function which just calls panic(). I'm wondering > > > why loading images from this stage is not happening? Something > > > similar to bl2_load_images()->load_image() to load uboot and optee > > > os again and run them with bl31_main()? > > > > > > If I understand "CPU reset" spec [1] correctly, warm boot from reset > > > vector in BL31 again to Non-Secure world has to work. > > > > > > [1] > > > https://github.com/ARM-software/arm-trusted- > firmware/blob/master/doc > > > s/design/reset-design.rst > > > > > > Best regards, > > > Maxim. > > -- > > 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

5 years, 5 months

2
1
0 0

Re: [TF-A] TF-A warm reboot question

by Maxim Uvarov

sorry, wrong email thread. Another way around is to not support "hot reset" in ATF, but make qemu reboot is implement some watchdog for qemu virt platform. That also works for me with quick implementation with lhe link which I sent in the previous email. Maxim. On Thu, 24 Sep 2020 at 15:16, Maxim Uvarov via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > I.e. that implementation works for me: > https://github.com/muvarov/qemu/commit/f5e3fb83170613a9eed46b87358ab2e37de2… > > On Mon, 21 Sep 2020 at 18:16, Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote: > > > > Hello, > > > > I'm trying to understand why "warm reboot" is not currently > > implemented in TF-A for qemu targets. I.e. in case of qemu armv8 boot > > atf->optee->uboot->linux and then reboot, cpu jumps to BL31 > > qemu_system_reset() function which just calls panic(). I'm wondering > > why loading images from this stage is not happening? Something > > similar to bl2_load_images()->load_image() to load uboot and optee os > > again and run them with bl31_main()? > > > > If I understand "CPU reset" spec [1] correctly, warm boot from reset > > vector in BL31 again to Non-Secure world has to work. > > > > [1] https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/desig… > > > > Best regards, > > Maxim. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 5 months

1
0
0 0

TF-A warm reboot question

by Maxim Uvarov

Hello, I'm trying to understand why "warm reboot" is not currently implemented in TF-A for qemu targets. I.e. in case of qemu armv8 boot atf->optee->uboot->linux and then reboot, cpu jumps to BL31 qemu_system_reset() function which just calls panic(). I'm wondering why loading images from this stage is not happening? Something similar to bl2_load_images()->load_image() to load uboot and optee os again and run them with bl31_main()? If I understand "CPU reset" spec [1] correctly, warm boot from reset vector in BL31 again to Non-Secure world has to work. [1] https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/desig… Best regards, Maxim.

5 years, 5 months

1
1
0 0

Cancelled event with note: TF-A Tech Forum @ Thu 24 Sep 2020 16:00 - 17:00 (BST) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: "Due to conflicts with Linaro Connect this week we are cancelling this week’s TF-A Techforum on Thursday, 24th September 2020 at 16:00 – 17:00 BST. The next meeting will now be Thursday, 8th October 2020 at 16:00 – 17:00 BST" Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 24 Sep 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 5 months

1
0
0 0

Linaro Connect Sessions of Interest

by Don Harbin

Hi All, As Linaro Connect starts tomorrow, here are some pointers to sessions that will be of interest related to trustedfirmware.org. - *PSA Secure Partitions in OP-TEE* - Tuesday, September 22nd (1:25-1:50pm UTC) - Speaker: Miklos Balint - Slides available here <https://static.sched.com/hosted_files/lvc20/9a/LVC20-112_PSA_Secure_Partiti…> - *Trusted Firmware Project update* - Tuesday, Sept. 22nd (2:00-2:25pm UTC) - Spreaders: Matteo Carlini, Shebu Kuriakose - Slides available here <https://static.sched.com/hosted_files/lvc20/1e/LVC20-113-Trusted-Firmware-p…> - *Scalable Security Using Trusted Firmware-M Profiles* - Wednesday September 23rd (11.45am – 12.10pm UTC) - Speakers: Shebu Kuiakose, David Want - Slides available here <https://static.sched.com/hosted_files/lvc20/d0/ScalableSecurityUsingTrusted…> - *Enable UEFI Secure Boot using OP-TEE as Secure Partition* - Thursday September 24th (3.45-4.10pm UTC) - Speakers: Sahil Malhotra, Ilias Apalodimas - *Secure Partition Manager (SEL2 firmware) for Arm A-class devices* - Thursday September 24th (4.15-4.40pm UTC) - Speaker: Olivier Deprez - Slides are available here <https://static.sched.com/hosted_files/lvc20/09/LVC20-305-secure-partition-m…> Some general pointers to sessions of potential interest: - Security related topics can be viewed here - Boot architecture topics can be viewed here As a reminder, sign up for tomorrow's event is at Linaro Connect Registration <https://connect.linaro.org/> and is free, so feel free to forward this information on. :) The overall schedule is available at the same link as registration in case you may be interested in other sessions. Best regards, Don

5 years, 5 months

1
0
0 0

TF-A TechForum 24th Sept Cancelled

by Joanna Farley

Due to conflicts this week I am cancelling this week’s TF-A Techforum on Thursday, 24th September 2020 at 16:00 – 17:00 BST. The next meeting will now be Thursday, 8th October 2020 at 16:00 – 17:00 BST Apologies all. Joanna

5 years, 5 months

1
0
0 0

Re: [TF-A] Tests to verify BP_OPTION

by Alexei Fedorov

Hi, Yes, there are fvp-pauth-pac-ret-leaf-sdei,fvp-pauth-standard:fvp-tftf-fip.tftf-aemv8a.8_5-debug fvp-pauth-pac-ret-leaf-tsp-sdei,fvp-pauth-standard:fvp-tftf-fip.tftf-aemv8a.8_5-debug configs in platform-ci/group/tftf-l2-fvp introduced by https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/5393 Alexei ________________________________ 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: 17 September 2020 19:18 To: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Tests to verify BP_OPTION <Bump to get this email through> From: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com> Sent: Wednesday, September 16, 2020 11:54 AM To: tf-a(a)lists.trustedfirmware.org Cc: Varun Wadekar <vwadekar(a)nvidia.com> Subject: Tests to verify BP_OPTION Hi, Is there any test to verify the BP_OPTION feature set to “pac-ret+leaf” ? When BRANCH_PROTECTION is set to “3”, BP_OPTION is set to “pac-ret+leaf”. Reference code - https://github.com/ARM-software/arm-trusted-firmware/blob/master/Makefile Thanks, Kalyani

5 years, 5 months

2
2
0 0

Re: [TF-A] Query TSPD behavior with EHF

by Soby Mathew

Hi Sandeep > Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECUE);’ is in effect. Intention is to avoid NS interrupt preempt secure execution (Fast SMC). > But I think that will also disable G0 interrupt as both NS interrupt and G0 interrupt are on FIQ. > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > This is my understanding from the code please confirm if this is correct. The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC. Hence the usage of GIC PMR to mask the NS interrupts. As Dan says, the TSP_NS_INTR_ASYNC_PREEMPT predates the EHF design and it seems there is a problem as you describe. > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > This is my understanding from the code please confirm if this is correct. You are right. Routing model manipulation is not required when EL3 interrupts are present as GIC PMR manipulation should take care of the required behaviour for yielding vs atomic SMC. You also need to ensure it works as expected when EL3 interrupts are not enabled and when EHF is disabled. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > Tripathy via TF-A > Sent: 17 September 2020 16:53 > To: Dan Handley <Dan.Handley(a)arm.com> > Cc: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] Query TSPD behavior with EHF > > Hi Dan, > I am not sure if this is mentioned anywhere in any documents but I think > EHF handlers should be able to preempt all execution contexts at lower ELs > and lower ELs should never be able to mask such interrupts. > If the behavioral expectation is set the implementation can be fixed. > > Thanks > Sandeep > > On Thu, Sep 17, 2020 at 7:57 PM Dan Handley via TF-A <tf- > a(a)lists.trustedfirmware.org> wrote: > > > > A correction... > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan > > > Handley via TF-A > > > Sent: 17 September 2020 15:14 > > > > > > > > > > I want to handle something similar in OP-TEED along with EHF > > > > > depending on > > > > what is the expected behavior. > > > > > > > > Hmm, I thought OP-TEED was more like the > TSP_NS_INTR_ASYNC_PREEMPT=0 > > > case, where NS interrupts are routed to S-EL1 while processing a > > > yielding SMC in S- EL1? Perhaps that's a better TSPD config for you to > follow? > > > > > Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are > routed to EL3 first, but the TSPD re-enables NS interrupts before handing > over to the TSP to handle yielding calls, via a call to > ehf_allow_ns_preemption. > > > > Right, that is the case for yielding SMC handling where both NS interrupts > and EL3/G0 interrupts can preempt the S_EL1/S_EL2 context. > But I would expect the same routing model even for 'Fast SMC' unlike what is > happening in TSPD. > > > Dan. > > > > -- > > 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

5 years, 6 months

1
0
0 0

Re: [TF-A] Build failure in OpenCI

by Joanna Farley

FYI we are trying to get the OpenCI to use a different label (Validation-Bot-Review) which is not part our of day to day workflow for patch approvals but standard plugins being used don't seem to support non standard labels so they are working on an alternative approach. Hopefully it will be fixed soon so we don't have to manually remove the OpenCI bot setting on the CR label. Joanna On 18/09/2020, 09:30, "TF-A on behalf of Yann GAUTIER via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Olivier, Thanks for your answer. I was not particularly worried when I saw what the error was. And I understand it can take time to stabilize such infrastructure. It is nice that we can have access to it now. Regards, Yann -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: vendredi 18 septembre 2020 10:22 To: tf-a(a)lists.trustedfirmware.org; Yann GAUTIER <yann.gautier(a)st.com> Subject: Re: Build failure in OpenCI Hi Yann, The OpenCI is under enablement/works, and I think you can safely ignore those CR-1/Verified-1 from the bot. Current CI strategy is still about maintainers applying Allow-CI+1/2 (resulting in Verified+1 on success). Sorry for the trouble it causes presently. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Yann GAUTIER via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 September 2020 09:33 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Build failure in OpenCI Hi, I've pushed some series of patches this morning, but none of them passes the OpenCI builds and tests. For all of them, the error is the same, Lava cannot find a file: http://ci.trustedfirmware.org/job/tf-a-builder//ws/custom_lava_job_definiti…<http://ci.trustedfirmware.org/job/tf-a-builder/ws/custom_lava_job_definitio…> See for example: https://ci.trustedfirmware.org/job/post-build-lava/3941/console Do you know what's wrong with this file? And if it will be corrected soon? Thanks, Yann -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 6 months

1
0
0 0

Re: [TF-A] Build failure in OpenCI

by Olivier Deprez

Hi Yann, The OpenCI is under enablement/works, and I think you can safely ignore those CR-1/Verified-1 from the bot. Current CI strategy is still about maintainers applying Allow-CI+1/2 (resulting in Verified+1 on success). Sorry for the trouble it causes presently. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Yann GAUTIER via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 September 2020 09:33 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Build failure in OpenCI Hi, I’ve pushed some series of patches this morning, but none of them passes the OpenCI builds and tests. For all of them, the error is the same, Lava cannot find a file: http://ci.trustedfirmware.org/job/tf-a-builder//ws/custom_lava_job_definiti…<http://ci.trustedfirmware.org/job/tf-a-builder/ws/custom_lava_job_definitio…> See for example: https://ci.trustedfirmware.org/job/post-build-lava/3941/console Do you know what’s wrong with this file? And if it will be corrected soon? Thanks, Yann

5 years, 6 months

2
1
0 0

Build failure in OpenCI

by Yann GAUTIER

Hi, I've pushed some series of patches this morning, but none of them passes the OpenCI builds and tests. For all of them, the error is the same, Lava cannot find a file: http://ci.trustedfirmware.org/job/tf-a-builder//ws/custom_lava_job_definiti…<http://ci.trustedfirmware.org/job/tf-a-builder/ws/custom_lava_job_definitio…> See for example: https://ci.trustedfirmware.org/job/post-build-lava/3941/console Do you know what's wrong with this file? And if it will be corrected soon? Thanks, Yann

5 years, 6 months

1
0
0 0

Tests to verify BP_OPTION

by Kalyani Chidambaram Vaidyanathan

Hi, Is there any test to verify the BP_OPTION feature set to "pac-ret+leaf" ? When BRANCH_PROTECTION is set to "3", BP_OPTION is set to "pac-ret+leaf". Reference code - https://github.com/ARM-software/arm-trusted-firmware/blob/master/Makefile Thanks, Kalyani

5 years, 6 months

2
1
0 0

Re: [TF-A] Query TSPD behavior with EHF

by Sandeep Tripathy

Hi Dan, I am not sure if this is mentioned anywhere in any documents but I think EHF handlers should be able to preempt all execution contexts at lower ELs and lower ELs should never be able to mask such interrupts. If the behavioral expectation is set the implementation can be fixed. Thanks Sandeep On Thu, Sep 17, 2020 at 7:57 PM Dan Handley via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > A correction... > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan Handley > > via TF-A > > Sent: 17 September 2020 15:14 > > > > > > > > I want to handle something similar in OP-TEED along with EHF > > > > depending on > > > what is the expected behavior. > > > > > > Hmm, I thought OP-TEED was more like the TSP_NS_INTR_ASYNC_PREEMPT=0 case, > > where NS interrupts are routed to S-EL1 while processing a yielding SMC in S- > > EL1? Perhaps that's a better TSPD config for you to follow? > > > Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are routed to EL3 first, but the TSPD re-enables NS interrupts before handing over to the TSP to handle yielding calls, via a call to ehf_allow_ns_preemption. > Right, that is the case for yielding SMC handling where both NS interrupts and EL3/G0 interrupts can preempt the S_EL1/S_EL2 context. But I would expect the same routing model even for 'Fast SMC' unlike what is happening in TSPD. > Dan. > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 6 months

1
0
0 0

Re: [TF-A] Query TSPD behavior with EHF

by Dan Handley

A correction... > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan Handley > via TF-A > Sent: 17 September 2020 15:14 > > > > > > I want to handle something similar in OP-TEED along with EHF > > > depending on > > what is the expected behavior. > > > > Hmm, I thought OP-TEED was more like the TSP_NS_INTR_ASYNC_PREEMPT=0 case, > where NS interrupts are routed to S-EL1 while processing a yielding SMC in S- > EL1? Perhaps that's a better TSPD config for you to follow? > Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are routed to EL3 first, but the TSPD re-enables NS interrupts before handing over to the TSP to handle yielding calls, via a call to ehf_allow_ns_preemption. Dan.

5 years, 6 months

1
0
0 0

Re: [TF-A] Query TSPD behavior with EHF

by Dan Handley

Hi Sandeep > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > Tripathy via TF-A > > > > EHF activates the routing model for ‘INTR_TYPE_EL3’ CSS = 0 , TEL3 = 1 > ie FIQ trapped to EL3 and not visible and not mask-able to lower ELs. > > > > Which means G0 interrupts (all EHF interrupts) expected to preempt any > > execution context. And secure state cannot mask such interrupts > > > > eg: critical error interrupts. Sort of NMI behavior. > > > > However from TSPD code I see ‘TSP_NS_INTR_ASYNC_PREEMPT’ enforces a > slightly different behavior. G0 interrupt cannot preempt a fast smc handler > in SPD. > > > > Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECURE);’ > is in effect. Intention is to avoid NS interrupt preempt secure execution > (Fast SMC). > > But I think that will also disable G0 interrupt as both NS interrupt and G0 > interrupt are on FIQ. I haven't double checked but that sounds correct. > > EHF already ensures this by GIC PMR adjustment. So disabling routing model > seems unnecessary in this case. > > This is my understanding from the code please confirm if this is correct. > > The TSPD's TSP_NS_INTR_ASYNC_PREEMPT functionality predates the EHF, which probably explains why NS interrupts are disabled in 2 ways in this config (i.e. when both TSP_NS_INTR_ASYNC_PREEMPT and EL3_EXCEPTION_HANDLING equal 1). I guess it's possible that the call to disable the routing model can be safely removed in this config but it would require some thorough code review and testing. I'm not sure if this config is tested much at all. > > > > > > Do we think it is not aligned with G0 interrupt preemption rule. Or do we > treat Fast SMC at S_EL1/EL2 as non interruptible. > > I think G0 interrupts should be handled in this case but I'm not sure if this is easy to fix in the TSPD. > > > > > > I want to handle something similar in OP-TEED along with EHF depending on > what is the expected behavior. > > Hmm, I thought OP-TEED was more like the TSP_NS_INTR_ASYNC_PREEMPT=0 case, where NS interrupts are routed to S-EL1 while processing a yielding SMC in S-EL1? Perhaps that's a better TSPD config for you to follow? Regards Dan.

5 years, 6 months

1
0
0 0

Re: [TF-A] Query TSPD behavior with EHF

by Sandeep Tripathy

Updated.. On Wed, Sep 16, 2020 at 10:51 AM Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi, > > EHF activates the routing model for ‘INTR_TYPE_EL3’ CSS = 0 , TEL3 = 1 ie FIQ trapped to EL3 and not visible and not mask-able to lower ELs. > > Which means G0 interrupts (all EHF interrupts) expected to preempt any execution context. And secure state cannot mask such interrupts > > eg: critical error interrupts. Sort of NMI behavior. > > > > However from TSPD code I see ‘TSP_NS_INTR_ASYNC_PREEMPT’ enforces a slightly different behavior. G0 interrupt cannot preempt a fast smc handler in SPD. > > Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECURE);’ is in effect. Intention is to avoid NS interrupt preempt secure execution (Fast SMC). > But I think that will also disable G0 interrupt as both NS interrupt and G0 interrupt are on FIQ. > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > This is my understanding from the code please confirm if this is correct. > > > > Do we think it is not aligned with G0 interrupt preemption rule. Or do we treat Fast SMC at S_EL1/EL2 as non interruptible. > > > > I want to handle something similar in OP-TEED along with EHF depending on what is the expected behavior. > > > > Thanks > > Sandeep > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 6 months

1
0
0 0

Query TSPD behavior with EHF

by Sandeep Tripathy

Hi, EHF activates the routing model for ‘INTR_TYPE_EL3’ CSS = 0 , TEL3 = 1 ie FIQ trapped to EL3 and not visible and not mask-able to lower ELs. Which means G0 interrupts (all EHF interrupts) expected to preempt any execution context. And secure state cannot mask such interrupts eg: critical error interrupts. Sort of NMI behavior. However from TSPD code I see ‘TSP_NS_INTR_ASYNC_PREEMPT’ enforces a slightly different behavior. G0 interrupt cannot preempt a fast smc handler in SPD. Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECURE);’ is in effect. Intention is to avoid NS interrupt preempt secure execution (Fast SMC). But I think that will also disable G0 interrupt as both NS interrupt and G0 interrupt are on FIQ. This is my understanding from the code please confirm if this is correct. Do we think it is not aligned with G0 interrupt preemption rule. Or do we treat Fast SMC at S_EL1/EL2 as non interruptible. I want to handle something similar in OP-TEED along with EHF depending on what is the expected behavior. Thanks Sandeep

5 years, 6 months

1
0
0 0

ATF currently does not use proper printf format specifiers for fixed width types

by Scott Branden

Hello, ATF currently uses non-portable printf format specifiers for fixed width types defined in stdint.h In addition, ATF redefines types defined in gcc for stdint.h with its own custom types causing additional issues. This causes compilation issues when porting code to/from ATF. AND, generates coverity parse errors as int64_t and uint64_t are incorrectly defined in ATF vs. gcc for aarch64. The printf format specifiers in inttypes.h are to be used for the proper format specifiers. And, uint64_t/int64_t should be defined the same as in gcc. I tried fixing up all the instances of int64 printf format specifiers by introducing inttypes.h and redefined the stdint types correctly here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5437 We have checked the change into our local tree so that everything compiles and runs in our system. Please accept change upstream. Regards, Scott

5 years, 6 months

1
0
0 0

Re: [TF-A] ATF LTS version

by François Ozog

On Thu, 11 Jun 2020 at 23:42, Varun Wadekar via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Hello Matteo, > > Apologies for still using an outdated term. I have trained myself to get > used to "TF-A" - looks like I am still not there. > > >> The idea has also been just raised to the Trusted Firmware project > Board for initial consideration and we will be all very keen to understand > how much interest there is from the wider TF-A community of adopters and > external (non-Arm) maintainers > > That is good to hear. For the exact scope, I think we can assume the usual > expectations from any LTS software stack - stability, performance, > security, bug fixes along with maintenance support. We are open to > discussing the cadence and any other operational commitments. > > @Francois, from the description of Trusted Substrate looks like you also > expect the sub-projects to provide LTS versions for the project as a whole > to succeed (?) > > Yes. I assume relevant tf.org projects decide to branch LTSes so that we can extend the scope to selected OP-TEE TAs for the Trusted Substrate LTS and may be extend duration of support for the tf.org LTSes. (just to make sure: this is just early open thinking to understand what it would mean to build such a service on the Linaro side should there be tf.org LTSes). -Varun > > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Matteo > Carlini via TF-A > Sent: Thursday, June 11, 2020 4:25 AM > To: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] ATF LTS version > > External email: Use caution opening links or attachments > > > Hi Francois, > > > I'd be happy to know more about what you see as TFA LTS: exact scope, > number of versions, duration, operational commitments (zero-day...). > > Do you have other firmware LTS needs? > > Agree. That’s precisely what I was hinting to Varun, when mentioning > concrete requirements for the LTS scheme. > > > Trusted Substrate is the aggregation of { TFA, OP-TEE, some TEE apps > such as firmwareTPM, U-Boot }. > > Trusted Substrate effort is led by Linaro members and is going to be set > up as a more open project. > > First time I heard about it. Good to know, but I guess we'll need to > discuss the intersection and collaboration with the Trusted Firmware > project at some point. > Having a LTS versioning scheme for the Trusted Firmware hosted projects > should be theoretically either in the scope of the Project itself or, if > the Board agrees, appointed to some other project/entity. > > > Our end goal is to enable unified, transactional, robust (anti-bricking, > anti rollback) UEFI OTA on both U-Boot and EDK2. > > Fair, but IMHO this has little to do with Arm Secure world software LTS > releases (TF-A/Hafnium/OP-TEE/TAs, TF-M)...probably best to discuss aside, > this is not in scope of what Varun is raising. > > Thanks > Matteo > > -- > 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 > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

5 years, 6 months

2
2
0 0

Test message please ignore

by Bill Fletcher

.

5 years, 6 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 10th September 2020 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 10th September 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: * Proposal for a LTS (Long Term Support) Release Option for TF-A * Presented by Varun Wadekar * Long-term support is a lifecycle management policy in which a stable release is maintained for a period of time * 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

5 years, 6 months

1
0
0 0

Re: [TF-A] GCC compiler option to support "xpaci" instruction

by Olivier Deprez

Hi again, After further check, it looks gcc 9.2 already supports the appropriate option. Maybe you missed ARM_ARCH_MINOR on the build command line depending on whether you need PAuth (Armv8.3) and/or BTI (Armv8.5). BRANCH_PROTECTION=2 or 3 => need ARM_ARCH_MINOR=3 (at least) BRANCH_PROTECTION=1 or 4 => need ARM_ARCH_MINOR=5 Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Olivier Deprez via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 03 September 2020 09:47 To: Kalyani Chidambaram Vaidyanathan; tf-a(a)lists.trustedfirmware.org; Varun Wadekar Subject: Re: [TF-A] GCC compiler option to support "xpaci" instruction Hi Kalyani, According to https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/build-op… you need a compiler supporting the -mbranch-protection option. This seems to be the case from gcc 9.3 onwards: https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/AArch64-Options.html#AArch64-O… Notice a GCC10.2 cross-compiler release is planned by end of this year according to this page: https://community.arm.com/developer/tools-software/tools/b/tools-software-i… 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: 03 September 2020 04:08 To: Kalyani Chidambaram Vaidyanathan; tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] GCC compiler option to support "xpaci" instruction <Dummy response to get the email through to the mailing list> From: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com> Sent: Wednesday, September 2, 2020 3:43 PM To: tf-a(a)lists.trustedfirmware.org Cc: Varun Wadekar <vwadekar(a)nvidia.com> Subject: GCC compiler option to support "xpaci" instruction Hi, We are using gcc-arm-9.2 toolchain and see that this is not supporting the “xpaci” instruction. Is there any compiler flag that has to be included to support this? Reference code that uses “xpaci” when PAUTH is enabled - https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl31/aarch… Thanks, Kalyani -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 6 months

1
0
0 0

Re: [TF-A] GCC compiler option to support "xpaci" instruction

by Olivier Deprez

Hi Kalyani, According to https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/build-op… you need a compiler supporting the -mbranch-protection option. This seems to be the case from gcc 9.3 onwards: https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/AArch64-Options.html#AArch64-O… Notice a GCC10.2 cross-compiler release is planned by end of this year according to this page: https://community.arm.com/developer/tools-software/tools/b/tools-software-i… 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: 03 September 2020 04:08 To: Kalyani Chidambaram Vaidyanathan; tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] GCC compiler option to support "xpaci" instruction <Dummy response to get the email through to the mailing list> From: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com> Sent: Wednesday, September 2, 2020 3:43 PM To: tf-a(a)lists.trustedfirmware.org Cc: Varun Wadekar <vwadekar(a)nvidia.com> Subject: GCC compiler option to support "xpaci" instruction Hi, We are using gcc-arm-9.2 toolchain and see that this is not supporting the “xpaci” instruction. Is there any compiler flag that has to be included to support this? Reference code that uses “xpaci” when PAUTH is enabled - https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl31/aarch… Thanks, Kalyani

5 years, 6 months

1
0
0 0

Re: [TF-A] GCC compiler option to support "xpaci" instruction

by Varun Wadekar

<Dummy response to get the email through to the mailing list> From: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com> Sent: Wednesday, September 2, 2020 3:43 PM To: tf-a(a)lists.trustedfirmware.org Cc: Varun Wadekar <vwadekar(a)nvidia.com> Subject: GCC compiler option to support "xpaci" instruction Hi, We are using gcc-arm-9.2 toolchain and see that this is not supporting the "xpaci" instruction. Is there any compiler flag that has to be included to support this? Reference code that uses "xpaci" when PAUTH is enabled - https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl31/aarch… Thanks, Kalyani

5 years, 6 months

1
0
0 0

List of issues with Cactus as SPMC on pre-8.4 CPUs

by Varun Wadekar

Hi @Olivier<mailto:Olivier.Deprez@arm.com>, We have been trying to use Cactus as SPMC on Tegra194 (pre 8.4) platforms and have faced the following issues. 1. Cactus_main.c - During cold boot, Cactus checks if the ffa-id for the instance of Cactus == SPM_VM_ID_FIRST. It issues FFA_ID_GET SMC to TF-A which returns the spmc_id in return. But on pre-8.4 platforms the value does not match SPM_VM_ID_FIRST and so the system assumes that the device is running on a post-8.4 CPU. The problem is that TF-A returns the spmc_id for this SMC, which seems incorrect. I don't understand why Cactus needs to know its own VM_ID on pre-8.4 CPUs. Can we assume that only one SPMC can run on pre-8.4? 2. Cactus_ffa_tests.c - The ` ffa_partition_info_get_test` incorrectly queries the partition info for secondary and tertiary VMs on pre-8.4 CPUs. 3. In general the boot tests that execute within Cactus seem incorrect to me. Some tests expect the presence of a non-secure world payload, which is not available at this point in the boot. This leads to numerous crashes and asserts during boot. 4. Cactus incorrectly uses a hard-coded address 0x7300000 as the RX/TX memory base. It should be using a platform defined value instead. We do not support this memory address on Tegra194. 5. The debug UART in Cactus needs rework too. Right now, it only supports PL011 as the UART driver. 6. TF-A SPMD forwards some SMCs to the non-secure world without checking if a non-secure world payload exists. This causes crashes during cold boot. Please let me know if you have commits for any or all of these issues. We have some WIP commits that we can push to gerrit for review, if required. Thoughts? -Varun

5 years, 6 months

2
2
0 0

question about tf-a spec

by chen feng

Hello arm expects, While reading the tf-a spec about the section "3.5.1 Register state". It described that "The MMU must be disabled for a partition that does not run in S-EL0". Does this mean that the S-EL1 SP need to create their own page table and enable the MMU itself. I wonder in this way, it is not very friendly to a SP developer. Since the SP can be a verify simple binary, maybe a single driver which can benefited from the isolation from other partitions. So in the pointer of developing a single driver. I think it do not need to care about the MMU configuration. It will be more friendly to be as easy as developing a user-land binary. The SPMC(SEL2) can do this configure for the SEL1's page-tables and enable MMU for SEL1 before jump into the SP. So I want to discuss here to understand the meaning behind it. Cheers, Feng

5 years, 6 months

3
8
0 0

Re: [TF-A] [query] sbsa level 3 spec: non secure watchdog WS1 handling at EL3

by Sandeep Tripathy

Hi Dan, On Thu, Aug 27, 2020 at 8:31 PM Dan Handley via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Sandeep > > > > Arm development platforms that have an SBSA secure watchdog like N1SDP do not register an interrupt handler for the WS0 signal. They simply wait for the WS1 signal, which is fed to a higher agent (in this case the System Control Processor), which resets the platform. > There is no explicit watchdog interrupt handling functionality in TF-A. > what happens to non secure sbsa WS1 ? That is the case for Secure sbsa WS1. NS WS0 ----> EL1 X (optional) but linux already implements it . NS WS1 ----> EL3 X TF-A Do not handle it. Hence the patch. Not handling it altogether is not an option I guess. S WS0 -------> EL3 X (optional) . Platform might want to log this condition. S WS1 ----------------------------------------> handled by a higher agent. > > > If your platform does not have a higher agent that handles WS1 then I guess you could add a handler in TF-A as you suggest in your code snippet, though I'm not sure if the maintainers would want this in generic SBSA code. Also, I don't see why you need both callback(s) and the explicit call to psci_systrem_reset2(), when presumably the callback(s) would do the latter. > Platform callback can optionally do more things like some logging. Ultimately 'system_reset2' seems to be the thing everyone would like to do as part of action. Then to reduce duplicate code we can have at one place. > > > > Q1- What happens if core is stuck and interrupts are not taken. > > It's rare for EL3 interrupts not to be taken when the core is stuck, unless an EL3 exception handler itself is stuck, in which case I'm not sure there's much you can do. That's why it's good to have a higher agent. > The rare lockup of core where it's not able to respond (not the software ones) requires some other agent to detect and reset/recover the system. Linux watchdog (ns sbsa WS1) will go unnoticed in such cases. ie. even if the watchdog hardware detected the lockup and indicated by WS0 then WS1 .. both were not acted upon. If it were the secure watchdog then no issues. > > > > Or it has to be registered as a RAS priority exception. > > I don't think that would help, unless the system was flooded with higher priority exceptions that prevented the watchdog handler from running. > > > > Regards > > > Dan. > > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep Tripathy via TF-A > Sent: 27 August 2020 12:14 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] [query] sbsa level 3 spec: non secure watchdog WS1 handling at EL3 > > > > Hi, > > Based on sbsa spec for level-3 firmware specification watchdog signals NS WS1 and S WS0 to be handled at EL3 firmware. > > I have some query on how TF-A plans to implement this. > > > > Ref: Excerpt DEN0029D_SBSA_6.0 https://developer.arm.com/documentation/den0029/d/?lang=en > > 3.2.3 Watchdogs The required behavior of watchdog signal 1 of the Non-secure watchdog is modified in level 3– firmware and is required to be routed as an SPI to the GIC. It is expected that this SPI be configured as an EL3 interrupt, directly targeting a single PE. A system compatible with level 3- firmware must implement a second watchdog, and is referred to as the Secure watchdog. It must have both its register frames mapped in the Secure memory address space and must not be aliased to the Non-secure address space. Watchdog Signal 0 of the Secure watchdog must be routed as an SPI to the GIC and it is expected this will be configured as an EL3 interrupt, directly targeting a single PE. > > > > Q1- What happens if core is stuck and interrupts are not taken. Non-secure watchdog will expire and ultimately results in a WS1 which is also not taken as the core is not responding. > > If WS1 were to another subsystem (eg: SCP) then it would take action. > > In current scheme is it the secure sbsa wdg expected to detect such hang ? > > > > Q2- How to handle sbsa watchdog interrupt at EL3. Please suggest if I should make a patch in following approach to start with. Or it has to be registered as a RAS priority exception. > > > > diff --git a/drivers/arm/sbsa/sbsa.c b/drivers/arm/sbsa/sbsa.c > > index 79c6f26..9683ef8 100644 > > --- a/drivers/arm/sbsa/sbsa.c > > +++ b/drivers/arm/sbsa/sbsa.c > > @@ -40,3 +40,26 @@ > > + > > +#define weak plat_sbsa_nt_wdog_ws1_handle > > +#define weak plat_sbsa_t_wdog_ws0_handle > > +void sbsa_wdog_handler(int id) > > +{ > > + if (id == SBSA_NT_WDG_WS1_INT) { > > + /* PUBLISH_EVENT */ > > + plat_sbsa_nt_wdog_ws1_handle(); > > + } else if (id == SBSA_T_WDG_WS0_INT) { > > + /* PUBLISH_EVENT */ > > + plat_sbsa_t_wdog_ws0_handle(); > > + } > > + /* EOI and reset , log what else */ > > + psci_systrem_reset2(); > > +} > > + > > +void sbsa_wdog_hander_init(void) > > +{ > > +#if EXCEPTION_HANDLING_FRAMEWORK > > + ehf_register_priority_handler(SBSA_WDG_PRI, sbsa_wdog_handler); > > +#endif > > +} > > > > Thanks > > Sandeep > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a Thanks Sandeep

5 years, 6 months

2
1
0 0

Re: [TF-A] [query] sbsa level 3 spec: non secure watchdog WS1 handling at EL3

by Dan Handley

Hi Sandeep Arm development platforms that have an SBSA secure watchdog like N1SDP do not register an interrupt handler for the WS0 signal. They simply wait for the WS1 signal, which is fed to a higher agent (in this case the System Control Processor), which resets the platform. There is no explicit watchdog interrupt handling functionality in TF-A. If your platform does not have a higher agent that handles WS1 then I guess you could add a handler in TF-A as you suggest in your code snippet, though I'm not sure if the maintainers would want this in generic SBSA code. Also, I don't see why you need both callback(s) and the explicit call to psci_systrem_reset2(), when presumably the callback(s) would do the latter. > Q1- What happens if core is stuck and interrupts are not taken. It's rare for EL3 interrupts not to be taken when the core is stuck, unless an EL3 exception handler itself is stuck, in which case I'm not sure there's much you can do. That's why it's good to have a higher agent. > Or it has to be registered as a RAS priority exception. I don't think that would help, unless the system was flooded with higher priority exceptions that prevented the watchdog handler from running. Regards Dan. From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep Tripathy via TF-A Sent: 27 August 2020 12:14 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] [query] sbsa level 3 spec: non secure watchdog WS1 handling at EL3 Hi, Based on sbsa spec for level-3 firmware specification watchdog signals NS WS1 and S WS0 to be handled at EL3 firmware. I have some query on how TF-A plans to implement this. Ref: Excerpt DEN0029D_SBSA_6.0 https://developer.arm.com/documentation/den0029/d/?lang=en 3.2.3 Watchdogs The required behavior of watchdog signal 1 of the Non-secure watchdog is modified in level 3– firmware and is required to be routed as an SPI to the GIC. It is expected that this SPI be configured as an EL3 interrupt, directly targeting a single PE. A system compatible with level 3- firmware must implement a second watchdog, and is referred to as the Secure watchdog. It must have both its register frames mapped in the Secure memory address space and must not be aliased to the Non-secure address space. Watchdog Signal 0 of the Secure watchdog must be routed as an SPI to the GIC and it is expected this will be configured as an EL3 interrupt, directly targeting a single PE. Q1- What happens if core is stuck and interrupts are not taken. Non-secure watchdog will expire and ultimately results in a WS1 which is also not taken as the core is not responding. If WS1 were to another subsystem (eg: SCP) then it would take action. In current scheme is it the secure sbsa wdg expected to detect such hang ? Q2- How to handle sbsa watchdog interrupt at EL3. Please suggest if I should make a patch in following approach to start with. Or it has to be registered as a RAS priority exception. diff --git a/drivers/arm/sbsa/sbsa.c b/drivers/arm/sbsa/sbsa.c index 79c6f26..9683ef8 100644 --- a/drivers/arm/sbsa/sbsa.c +++ b/drivers/arm/sbsa/sbsa.c @@ -40,3 +40,26 @@ + +#define weak plat_sbsa_nt_wdog_ws1_handle +#define weak plat_sbsa_t_wdog_ws0_handle +void sbsa_wdog_handler(int id) +{ + if (id == SBSA_NT_WDG_WS1_INT) { + /* PUBLISH_EVENT */ + plat_sbsa_nt_wdog_ws1_handle(); + } else if (id == SBSA_T_WDG_WS0_INT) { + /* PUBLISH_EVENT */ + plat_sbsa_t_wdog_ws0_handle(); + } + /* EOI and reset , log what else */ + psci_systrem_reset2(); +} + +void sbsa_wdog_hander_init(void) +{ +#if EXCEPTION_HANDLING_FRAMEWORK + ehf_register_priority_handler(SBSA_WDG_PRI, sbsa_wdog_handler); +#endif +} Thanks Sandeep

5 years, 6 months

1
0
0 0

[query] sbsa level 3 spec: non secure watchdog WS1 handling at EL3

by Sandeep Tripathy

Hi, Based on sbsa spec for level-3 firmware specification watchdog signals NS WS1 and S WS0 to be handled at EL3 firmware. I have some query on how TF-A plans to implement this. Ref: Excerpt DEN0029D_SBSA_6.0 https://developer.arm.com/documentation/den0029/d/?lang=en 3.2.3 Watchdogs The required behavior of watchdog signal 1 of the Non-secure watchdog is modified in level 3– firmware and is required to be routed as an SPI to the GIC. It is expected that this SPI be configured as an EL3 interrupt, directly targeting a single PE. A system compatible with level 3- firmware must implement a second watchdog, and is referred to as the Secure watchdog. It must have both its register frames mapped in the Secure memory address space and must not be aliased to the Non-secure address space. Watchdog Signal 0 of the Secure watchdog must be routed as an SPI to the GIC and it is expected this will be configured as an EL3 interrupt, directly targeting a single PE. Q1- What happens if core is stuck and interrupts are not taken. Non-secure watchdog will expire and ultimately results in a WS1 which is also not taken as the core is not responding. If WS1 were to another subsystem (eg: SCP) then it would take action. In current scheme is it the secure sbsa wdg expected to detect such hang ? Q2- How to handle sbsa watchdog interrupt at EL3. Please suggest if I should make a patch in following approach to start with. Or it has to be registered as a RAS priority exception. diff --git a/drivers/arm/sbsa/sbsa.c b/drivers/arm/sbsa/sbsa.c index 79c6f26..9683ef8 100644 --- a/drivers/arm/sbsa/sbsa.c +++ b/drivers/arm/sbsa/sbsa.c @@ -40,3 +40,26 @@ + +#define weak plat_sbsa_nt_wdog_ws1_handle +#define weak plat_sbsa_t_wdog_ws0_handle +void sbsa_wdog_handler(int id) +{ + if (id == SBSA_NT_WDG_WS1_INT) { + /* PUBLISH_EVENT */ + plat_sbsa_nt_wdog_ws1_handle(); + } else if (id == SBSA_T_WDG_WS0_INT) { + /* PUBLISH_EVENT */ + plat_sbsa_t_wdog_ws0_handle(); + } + /* EOI and reset , log what else */ + psci_systrem_reset2(); +} + +void sbsa_wdog_hander_init(void) +{ +#if EXCEPTION_HANDLING_FRAMEWORK + ehf_register_priority_handler(SBSA_WDG_PRI, sbsa_wdog_handler); +#endif +} Thanks Sandeep

5 years, 6 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. 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 361485: Integer handling issues (SIGN_EXTENSION) /plat/qti/common/src/spmi_arb.c: 54 in wait_for_done() ________________________________________________________________________________________________________ *** CID 361485: Integer handling issues (SIGN_EXTENSION) /plat/qti/common/src/spmi_arb.c: 54 in wait_for_done() 48 49 static int wait_for_done(uint16_t apid) 50 { 51 unsigned int timeout = 100; 52 53 while (timeout-- != 0U) { >>> CID 361485: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "apid" with type "uint16_t" (16 bits, unsigned) is promoted in "207618056 + 65536 * apid" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "207618056 + 65536 * apid" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 54 uint32_t status = mmio_read_32(REG_ARB_STATUS(apid)); 55 if ((status & ARB_STATUS_DONE) != 0U) { 56 if ((status & ARB_STATUS_FAILURE) != 0U || 57 (status & ARB_STATUS_DENIED) != 0U || 58 (status & ARB_STATUS_DROPPED) != 0U) { 59 return status & 0xff; ** CID 361484: Integer handling issues (SIGN_EXTENSION) /plat/qti/common/src/spmi_arb.c: 72 in arb_command() ________________________________________________________________________________________________________ *** CID 361484: Integer handling issues (SIGN_EXTENSION) /plat/qti/common/src/spmi_arb.c: 72 in arb_command() 66 return ARB_FAKE_STATUS_TIMEOUT; 67 } 68 69 static void arb_command(uint16_t apid, uint8_t opcode, uint32_t addr, 70 uint8_t bytes) 71 { >>> CID 361484: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "apid" with type "uint16_t" (16 bits, unsigned) is promoted in "207618048 + 65536 * apid" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "207618048 + 65536 * apid" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 72 mmio_write_32(REG_ARB_CMD(apid), (uint32_t)opcode << 27 | 73 (addr & 0xff) << 4 | (bytes - 1)); 74 } 75 76 int spmi_arb_read8(uint32_t addr) 77 { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

5 years, 6 months

1
0
0 0

Re: [TF-A] TF-A Gerrit access permissions currently broken.

by Joanna Farley

Things should be back to normal. Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Joanna Farley <Joanna.Farley(a)arm.com> Date: Wednesday, 26 August 2020 at 12:51 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] TF-A Gerrit access permissions currently broken. Just to inform project contributors that people may find their gerrit access rights may be broken at this time. I have raised a support request with the trustedfirmware.org support team. Joanna

5 years, 6 months

1
0
0 0

TF-A Gerrit access permissions currently broken.

by Joanna Farley

Just to inform project contributors that people may find their gerrit access rights may be broken at this time. I have raised a support request with the trustedfirmware.org support team. Joanna

5 years, 6 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 27th August 2020 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 27th August 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: * TF-A Errata Process – Presented by Bipin Ravi * Bug Review Committee (BRC) & Categorization of Errata * Software Developers Errata Notice (SDEN) & Product Errata Notice (PEN) * What TF-A Implements * How TF-A Implements * Testing 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

5 years, 6 months

1
0
0 0

Re: [TF-A] [RFC] Api to power down all cores

by Varun Wadekar

<Cc alias> -----Original Message----- From: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com> Sent: Tuesday, August 25, 2020 8:59 AM To: Varun Wadekar <vwadekar(a)nvidia.com>; Soby Mathew <Soby.Mathew(a)arm.com> Subject: RE: [TF-A] [RFC] Api to power down all cores Thanks, I will use callback as param to get rid of the 'plat*'. 'void psci_stop_other_cores(void (*stop_func)(uregister_t mpidr))' Platform can call like .. psci_stop_other_cores(ipi_send_stop); I will update the patch tomorrow. This api is not invoked by psci generic functions. So I think that should suffice your concern. Anyways I will take care any other suggestions. IPI implementation is under flag 'IPI_SUPPORT'. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5323/ Thanks Sandeep > -----Original Message----- > From: Varun Wadekar [mailto:vwadekar@nvidia.com] > Sent: Tuesday, August 25, 2020 9:11 AM > To: Soby Mathew; Sandeep Tripathy > Subject: RE: [TF-A] [RFC] Api to power down all cores > > Hi, > > In addition to the suggestions already posted, we should provide a > build flag or dynamic knob to allow platforms to disable this feature. > > -Varun > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby > Mathew via TF-A > Sent: Friday, August 21, 2020 3:57 AM > To: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com> > Cc: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] [RFC] Api to power down all cores > > External email: Use caution opening links or attachments > > > Hi Sandeep, > Thanks for the clarification. I too think this has general utility and > since you need access to internal PSCI data to perform the > functionality , exporting a utility function from PSCI for platforms > to invoke seems the right thing to do. > The small concern I have is using the `plat_*` namespace as this is a > utility function invoked by the platform and another porting layer > beneath it seems out of place. > > I would suggest to add a parameter to stop_other_cores(), this could > be either the IPI number or a callback function to trigger the IPI. > This allows to provide the platform specific details without `plat_*` > API. > > Best Regards > Soby Mathew > > > -----Original Message----- > > From: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com> > > Sent: 21 August 2020 07:17 > > To: Soby Mathew <Soby.Mathew(a)arm.com> > > Cc: tf-a(a)lists.trustedfirmware.org > > Subject: RE: [TF-A] [RFC] Api to power down all cores > > > > Hi Soby, > > I realize using term 'PSCI API' in rfc tag is misleading like Achin > > mentioned in gerrit. > > > > Here I wanted to have a generic API to 'stop_other_cores' in > > secure world. > > The usage is platform firmware specific. > > Implementation of 'stop_other_cores' depends on a generic 'IPI' > > support > (1). > > It leverages the existing EHF. So I feel it is not adding and > > complexity or overhead in normal execution path. > > > > 'stop_other_cores' API implementation depends on some psci private > > functions to traverse the pd nodes and extract MPIDRs for target pe > > list. That was the reason to put the function within psci lib. So > > there are > two things. > > 1- Does this idea of 'stop_other_core' api qualify to be generic > > 2- Does a generic IPI layer make sense > > > > Thanks > > Sandeep > > > -----Original Message----- > > > From: Soby Mathew [mailto:Soby.Mathew@arm.com] > > > Sent: Thursday, August 20, 2020 8:54 PM > > > To: Sandeep Tripathy > > > Cc: tf-a(a)lists.trustedfirmware.org > > > Subject: RE: [TF-A] [RFC] psci: api to power down all cores > > > > > > Hi Sandeep, > > > Just to understand better, if there is a secure side > > > panic/watchdog interrupt, then the secure side is already able to > > > do such an intervention without the availability of a PSCI API to the NS side. > > > > > > In case the NS world has crashed, then PSCI_SYSTEM_RESET and > > > PSCI_SYSTEM_OFF APIs can be invoked which then does the > > > appropriate actions. From my reading, the PSCI specification > > > doesn't prevent firmware implementation of the reset and off API's > > > from doing the kind of implementation as per your proposal. > > > > I intend to do 'stop_other_cores' in platform extension of > > 'plat_system_resetx()', secure side watchdog expiry/ > > plat_panic_handler(). > > > > > > > > Best Regards > > > Soby Mathew > > > > > > > -----Original Message----- > > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > > > Sandeep > > > > Tripathy via TF-A > > > > Sent: 19 August 2020 16:42 > > > > To: tf-a(a)lists.trustedfirmware.org > > > > Subject: [TF-A] [RFC] psci: api to power down all cores > > > > > > > > Hi, > > > > I am proposing to have a generic api in psci lib which can be > > > > used to > > > force > > > > power down all other cores from any initiating core analogous to > > > > 'smp_cpu_stop' in linux. It is immune to interrupt lock by > > > > EL1/EL2 software. > > > > > > > > Platforms may use this api in case of secure side panic, secure > > > > watchdog interrupt handling or if required in certain types of > > > > warm resets. The usage > > > is > > > > platform dependent. > > > > > > > > This depends on a generic implementation of secure IPI (1) which > > > > uses EHF > > > to > > > > handle IPI at platform defined priority. We probably require > > > > more types of secure IPIs. > > > > > > > > Please review the series > > > > Ref: > > > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5 > > > > 32 > > > > 4 > > > > > > > > diff --git a/lib/psci/psci_system_off.c > > > > b/lib/psci/psci_system_off.c index > > > > 141d69e..011aaa6 100644 > > > > --- a/lib/psci/psci_system_off.c > > > > +++ b/lib/psci/psci_system_off.c > > > > @@ -10,10 +10,44 @@ > > > > #include <arch_helpers.h> > > > > #include <common/debug.h> > > > > #include <drivers/console.h> > > > > +#include <drivers/delay_timer.h> > > > > #include <plat/common/platform.h> > > > > > > > > #include "psci_private.h" > > > > > > > > +#ifndef PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS #define > > > > +PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > > > > + > > > > +#if IMAGE_BL31 > > > > +void psci_stop_other_cores(void) { #define > > > > +PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > > > > + > > > > +#if IMAGE_BL31 > > > > +void psci_stop_other_cores(void) { > > > > + int idx, this_cpu_idx, cnt; > > > > + > > > > + this_cpu_idx = plat_my_core_pos(); > > > > + > > > > + /* Raise G0 IPI cpustop to all cores but self */ > > > > + for (idx = 0; idx < psci_plat_core_count; idx++) { > > > > + if ((idx != this_cpu_idx) && > > > > + (psci_get_aff_info_state_by_idx(idx) == > > > > AFF_STATE_ON)) { > > > > + > > > > plat_ipi_send_cpu_stop(psci_cpu_pd_nodes[idx].mpidr); > > > > + } > > > > + } > > > > + > > > > + /* Wait for others cores to shutdown */ > > > > + for (cnt = 0; cnt < PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS; > > > > + cnt++) > > > { > > > > + if (psci_is_last_on_cpu()) > > > > + break; > > > > + mdelay(1); > > > > + } > > > > + > > > > + if (!psci_is_last_on_cpu()) { > > > > + WARN("Failed to stop all cores!\n"); > > > > + psci_print_power_domain_map(); > > > > + } > > > > +} > > > > +#endif > > > > + > > > > > > > > (1) > > > > RFC: ipi: add ipi feature > > > > Ref: > > > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware- > > > a/+/5323/1 > > > > > > > > Thanks > > > > Sandeep > > > > -- > > > > 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

5 years, 6 months

1
0
0 0

[Request for review] Downstream patches from Tegra repos

by Varun Wadekar

Hello team, Requesting reviews for the latest patches [1] form our internal repos for Tegra platforms. I have updated the verification steps for each patch in the comments to help answer some questions. Thanks in advance. -Varun [1] https://review.trustedfirmware.org/q/topic:%22tegra-downstream-08252020%22+…

5 years, 6 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. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 361456: Memory - illegal accesses (NEGATIVE_RETURNS) /services/std_svc/spmd/spmd_main.c: 49 in spmd_get_context_by_mpidr() ________________________________________________________________________________________________________ *** CID 361456: Memory - illegal accesses (NEGATIVE_RETURNS) /services/std_svc/spmd/spmd_main.c: 49 in spmd_get_context_by_mpidr() 43 44 /******************************************************************************* 45 * SPM Core context on CPU based on mpidr. 46 ******************************************************************************/ 47 spmd_spm_core_context_t *spmd_get_context_by_mpidr(uint64_t mpidr) 48 { >>> CID 361456: Memory - illegal accesses (NEGATIVE_RETURNS) >>> Using variable "plat_core_pos_by_mpidr(mpidr)" as an index to array "spm_core_context". 49 return &spm_core_context[plat_core_pos_by_mpidr(mpidr)]; 50 } 51 52 /******************************************************************************* 53 * SPM Core context on current CPU get helper. 54 ******************************************************************************/ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

5 years, 6 months

1
0
0 0

Re: [TF-A] [RFC] Api to power down all cores

by Sandeep Tripathy

Hi Soby, I realize using term 'PSCI API' in rfc tag is misleading like Achin mentioned in gerrit. Here I wanted to have a generic API to 'stop_other_cores' in secure world. The usage is platform firmware specific. Implementation of 'stop_other_cores' depends on a generic 'IPI' support (1). It leverages the existing EHF. So I feel it is not adding and complexity or overhead in normal execution path. 'stop_other_cores' API implementation depends on some psci private functions to traverse the pd nodes and extract MPIDRs for target pe list. That was the reason to put the function within psci lib. So there are two things. 1- Does this idea of 'stop_other_core' api qualify to be generic 2- Does a generic IPI layer make sense Thanks Sandeep > -----Original Message----- > From: Soby Mathew [mailto:Soby.Mathew@arm.com] > Sent: Thursday, August 20, 2020 8:54 PM > To: Sandeep Tripathy > Cc: tf-a(a)lists.trustedfirmware.org > Subject: RE: [TF-A] [RFC] psci: api to power down all cores > > Hi Sandeep, > Just to understand better, if there is a secure side panic/watchdog > interrupt, > then the secure side is already able to do such an intervention without > the > availability of a PSCI API to the NS side. > > In case the NS world has crashed, then PSCI_SYSTEM_RESET and > PSCI_SYSTEM_OFF APIs can be invoked which then does the appropriate > actions. From my reading, the PSCI specification doesn't prevent firmware > implementation of the reset and off API's from doing the kind of > implementation as per your proposal. I intend to do 'stop_other_cores' in platform extension of 'plat_system_resetx()', secure side watchdog expiry/ plat_panic_handler(). > > Best Regards > Soby Mathew > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > Sandeep > > Tripathy via TF-A > > Sent: 19 August 2020 16:42 > > To: tf-a(a)lists.trustedfirmware.org > > Subject: [TF-A] [RFC] psci: api to power down all cores > > > > Hi, > > I am proposing to have a generic api in psci lib which can be used to > force > > power down all other cores from any initiating core analogous to > > 'smp_cpu_stop' in linux. It is immune to interrupt lock by EL1/EL2 > > software. > > > > Platforms may use this api in case of secure side panic, secure watchdog > > interrupt handling or if required in certain types of warm resets. The > > usage > is > > platform dependent. > > > > This depends on a generic implementation of secure IPI (1) which uses > > EHF > to > > handle IPI at platform defined priority. We probably require more types > > of > > secure IPIs. > > > > Please review the series > > Ref: > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5324 > > > > diff --git a/lib/psci/psci_system_off.c b/lib/psci/psci_system_off.c > > index > > 141d69e..011aaa6 100644 > > --- a/lib/psci/psci_system_off.c > > +++ b/lib/psci/psci_system_off.c > > @@ -10,10 +10,44 @@ > > #include <arch_helpers.h> > > #include <common/debug.h> > > #include <drivers/console.h> > > +#include <drivers/delay_timer.h> > > #include <plat/common/platform.h> > > > > #include "psci_private.h" > > > > +#ifndef PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS #define > > +PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > > + > > +#if IMAGE_BL31 > > +void psci_stop_other_cores(void) > > +{ > > +#define PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > > + > > +#if IMAGE_BL31 > > +void psci_stop_other_cores(void) > > +{ > > + int idx, this_cpu_idx, cnt; > > + > > + this_cpu_idx = plat_my_core_pos(); > > + > > + /* Raise G0 IPI cpustop to all cores but self */ > > + for (idx = 0; idx < psci_plat_core_count; idx++) { > > + if ((idx != this_cpu_idx) && > > + (psci_get_aff_info_state_by_idx(idx) == > > AFF_STATE_ON)) { > > + > > plat_ipi_send_cpu_stop(psci_cpu_pd_nodes[idx].mpidr); > > + } > > + } > > + > > + /* Wait for others cores to shutdown */ > > + for (cnt = 0; cnt < PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS; cnt++) > { > > + if (psci_is_last_on_cpu()) > > + break; > > + mdelay(1); > > + } > > + > > + if (!psci_is_last_on_cpu()) { > > + WARN("Failed to stop all cores!\n"); > > + psci_print_power_domain_map(); > > + } > > +} > > +#endif > > + > > > > (1) > > RFC: ipi: add ipi feature > > Ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware- > a/+/5323/1 > > > > Thanks > > Sandeep > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 6 months

2
1
0 0

Re: [TF-A] [RFC] psci: api to power down all cores

by Soby Mathew

Hi Sandeep, Just to understand better, if there is a secure side panic/watchdog interrupt, then the secure side is already able to do such an intervention without the availability of a PSCI API to the NS side. In case the NS world has crashed, then PSCI_SYSTEM_RESET and PSCI_SYSTEM_OFF APIs can be invoked which then does the appropriate actions. From my reading, the PSCI specification doesn't prevent firmware implementation of the reset and off API's from doing the kind of implementation as per your proposal. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > Tripathy via TF-A > Sent: 19 August 2020 16:42 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] [RFC] psci: api to power down all cores > > Hi, > I am proposing to have a generic api in psci lib which can be used to force > power down all other cores from any initiating core analogous to > 'smp_cpu_stop' in linux. It is immune to interrupt lock by EL1/EL2 software. > > Platforms may use this api in case of secure side panic, secure watchdog > interrupt handling or if required in certain types of warm resets. The usage is > platform dependent. > > This depends on a generic implementation of secure IPI (1) which uses EHF to > handle IPI at platform defined priority. We probably require more types of > secure IPIs. > > Please review the series > Ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5324 > > diff --git a/lib/psci/psci_system_off.c b/lib/psci/psci_system_off.c index > 141d69e..011aaa6 100644 > --- a/lib/psci/psci_system_off.c > +++ b/lib/psci/psci_system_off.c > @@ -10,10 +10,44 @@ > #include <arch_helpers.h> > #include <common/debug.h> > #include <drivers/console.h> > +#include <drivers/delay_timer.h> > #include <plat/common/platform.h> > > #include "psci_private.h" > > +#ifndef PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS #define > +PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > + > +#if IMAGE_BL31 > +void psci_stop_other_cores(void) > +{ > +#define PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > + > +#if IMAGE_BL31 > +void psci_stop_other_cores(void) > +{ > + int idx, this_cpu_idx, cnt; > + > + this_cpu_idx = plat_my_core_pos(); > + > + /* Raise G0 IPI cpustop to all cores but self */ > + for (idx = 0; idx < psci_plat_core_count; idx++) { > + if ((idx != this_cpu_idx) && > + (psci_get_aff_info_state_by_idx(idx) == AFF_STATE_ON)) { > + plat_ipi_send_cpu_stop(psci_cpu_pd_nodes[idx].mpidr); > + } > + } > + > + /* Wait for others cores to shutdown */ > + for (cnt = 0; cnt < PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS; cnt++) { > + if (psci_is_last_on_cpu()) > + break; > + mdelay(1); > + } > + > + if (!psci_is_last_on_cpu()) { > + WARN("Failed to stop all cores!\n"); > + psci_print_power_domain_map(); > + } > +} > +#endif > + > > (1) > RFC: ipi: add ipi feature > Ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5323/1 > > Thanks > Sandeep > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 6 months

1
0
0 0

[RFC] psci: api to power down all cores

by Sandeep Tripathy

Hi, I am proposing to have a generic api in psci lib which can be used to force power down all other cores from any initiating core analogous to 'smp_cpu_stop' in linux. It is immune to interrupt lock by EL1/EL2 software. Platforms may use this api in case of secure side panic, secure watchdog interrupt handling or if required in certain types of warm resets. The usage is platform dependent. This depends on a generic implementation of secure IPI (1) which uses EHF to handle IPI at platform defined priority. We probably require more types of secure IPIs. Please review the series Ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5324 diff --git a/lib/psci/psci_system_off.c b/lib/psci/psci_system_off.c index 141d69e..011aaa6 100644 --- a/lib/psci/psci_system_off.c +++ b/lib/psci/psci_system_off.c @@ -10,10 +10,44 @@ #include <arch_helpers.h> #include <common/debug.h> #include <drivers/console.h> +#include <drivers/delay_timer.h> #include <plat/common/platform.h> #include "psci_private.h" +#ifndef PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS +#define PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 +#endif + +#if IMAGE_BL31 +void psci_stop_other_cores(void) +{ +#define PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 +#endif + +#if IMAGE_BL31 +void psci_stop_other_cores(void) +{ + int idx, this_cpu_idx, cnt; + + this_cpu_idx = plat_my_core_pos(); + + /* Raise G0 IPI cpustop to all cores but self */ + for (idx = 0; idx < psci_plat_core_count; idx++) { + if ((idx != this_cpu_idx) && + (psci_get_aff_info_state_by_idx(idx) == AFF_STATE_ON)) { + plat_ipi_send_cpu_stop(psci_cpu_pd_nodes[idx].mpidr); + } + } + + /* Wait for others cores to shutdown */ + for (cnt = 0; cnt < PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS; cnt++) { + if (psci_is_last_on_cpu()) + break; + mdelay(1); + } + + if (!psci_is_last_on_cpu()) { + WARN("Failed to stop all cores!\n"); + psci_print_power_domain_map(); + } +} +#endif + (1) RFC: ipi: add ipi feature Ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5323/1 Thanks Sandeep

5 years, 7 months

1
0
0 0

Re: [TF-A] [Hafnium] Fw: Automate generation of Partition's specific configuration

by Joao Alves

Hi Raghu, Thank you very much for your feedback! It seems like a good idea to automate it and the approach looks fine to me. Is my understanding correct that the generated *dtsi* files will need to be included in the *dts* files once and the hope is if there is a change, the dts files need not change since the dtsi files will be regenerated every time during build? Yes, your understanding is correct. The other way this could be done is that the tool can generate dts files which have nodes that change at build time, which can then be compiled and added as dtb files, added to the FIP. That way fvp_tb_fw_config.dts and fvp_spmc_manifest.dts will remain the same and not have any dependency on a changing dtsi file. I’d prefer that dts files that change frequently like in this case be autogenerated entirely and as separate files. That _seems_ cleaner but may not work out so in practice. I agree with you that the approach you described above would make the whole process a bit cleaner. One way this could be done is by passing the *.pre.dts files (generated after the initial processing from dtc) to the script that are part of the patch. Last time I worked on this, I added the possibility to generate the nodes structure to an already existing dts file. Thus, expanding the previous configuration with the values of the new nodes. However, this work needs further testing. Alternatively, the python package I am using in the script can parse and generate dtb instead of dts. I was thinking to add the option to the dts_gen.py script (maybe rename it as well) to operate over the dtb format. So, making sure that "in-place" changes are working , and adding the option to operate over dtb files should allow for the cleaner approach that you referred. As is and making the referred changes, most of the script's logic should be preserved, so I don't think there will be a lot of changes to the current implementation, which is good. Please let me know if I was not very clear, or if you have any other comments. Also thanks @Gyorgy Szing<mailto:Gyorgy.Szing@arm.com> for the feedback on the current state of the patch, I appreciate it. Let me know if anyone has questions, or any other comments to the scripts and/or current discussion. I will notify once the work progresses. Best regards, João Alves ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Friday, August 7, 2020 5:54 PM To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: Re: [Hafnium] [TF-A] Fw: Automate generation of Partition's specific configuration Hi, It seems like a good idea to automate it and the approach looks fine to me. Is my understanding correct that the generated *dtsi* files will need to be included in the *dts* files once and the hope is if there is a change, the dts files need not change since the dtsi files will be regenerated every time during build? The other way this could be done is that the tool can generate dts files which have nodes that change at build time, which can then be compiled and added as dtb files, added to the FIP. That way fvp_tb_fw_config.dts and fvp_spmc_manifest.dts will remain the same and not have any dependency on a changing dtsi file. I’d prefer that dts files that change frequently like in this case be autogenerated entirely and as separate files. That _seems_ cleaner but may not work out so in practice. Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joao Alves via TF-A Sent: Monday, August 3, 2020 10:08 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Fw: Automate generation of Partition's specific configuration Hi all, Forwarding email below as the referred work may be useful/relevant for other parts of the TF-A project as well. Best regards, João Alves _____ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org <mailto:hafnium-bounces@lists.trustedfirmware.org> > on behalf of Joao Alves via Hafnium <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Sent: Monday, August 3, 2020 5:59 PM To: hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Subject: [Hafnium] Automate generation of Partition's specific configuration Hello all, I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium. There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions: hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "cactus-primary"; load_address = <0x7000000>; }; vm2 { is_ffa_partition; debug_name = "cactus-secondary"; load_address = <0x7100000>; vcpu_count = <2>; mem_size = <1048576>; }; }; Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address". If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files. In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files. Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150. The implementation is divided between two scripts: * "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files. * "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration. Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation. The above files contain a lot of comments on how to use them, and also describing the implementation. If the obtained feedback is good, I can work on integrating this in TF-A's build-system. Let me know if anyone has questions. Best regards, João Alves -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org <mailto:Hafnium@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/hafnium -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

5 years, 7 months

1
0
0 0

Cancelled event with note: TF-A Tech Forum @ Thu 13 Aug 2020 16:00 - 17:00 (BST) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: " Next TF-A Tech Forum is now scheduled for 26th August" Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 13 Aug 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 7 months

1
0
0 0

TF-A Tech Forum CANCELLED @ Thr 13th August 2020 16:00-1700 BST

by Joanna Farley

Apologies everyone, I need to cancel this week’s TF-A Tech Forum as presenters for our next subjects are all on vacation or have yet to complete preparation of the necessary material. As a reminder we have a scheduling page https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ If anybody has subjects they are willing to present please reach out to me so we can find you an appropriate slot. Next TF-A Tech Forum is now scheduled for 26th August. Thanks Joanna

5 years, 7 months

1
0
0 0

Missing properties from cactus dts

by Varun Wadekar

Hello Olivier, Hope you are doing well. As you already know, we are trying to test FF-A, using Cactus, on pre-8.4 Tegra platforms. While doing so, we saw that cactus.dts was missing the following properties 1. maj_ver 2. min_ver 3. spmc_id plat_spm_core_manifest_load() expects these values in the core manifest file. i.e. cactus.dts. What would be the right path forward? Do we add these fields to the dts file? Or modify plat_spmd_manifest.c file? -Varun

5 years, 7 months

2
1
0 0

Re: [TF-A] Fw: Automate generation of Partition's specific configuration

by raghu.ncstate＠icloud.com

Hi, It seems like a good idea to automate it and the approach looks fine to me. Is my understanding correct that the generated *dtsi* files will need to be included in the *dts* files once and the hope is if there is a change, the dts files need not change since the dtsi files will be regenerated every time during build? The other way this could be done is that the tool can generate dts files which have nodes that change at build time, which can then be compiled and added as dtb files, added to the FIP. That way fvp_tb_fw_config.dts and fvp_spmc_manifest.dts will remain the same and not have any dependency on a changing dtsi file. I’d prefer that dts files that change frequently like in this case be autogenerated entirely and as separate files. That _seems_ cleaner but may not work out so in practice. Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joao Alves via TF-A Sent: Monday, August 3, 2020 10:08 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Fw: Automate generation of Partition's specific configuration Hi all, Forwarding email below as the referred work may be useful/relevant for other parts of the TF-A project as well. Best regards, João Alves _____ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org <mailto:hafnium-bounces@lists.trustedfirmware.org> > on behalf of Joao Alves via Hafnium <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Sent: Monday, August 3, 2020 5:59 PM To: hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Subject: [Hafnium] Automate generation of Partition's specific configuration Hello all, I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium. There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions: hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "cactus-primary"; load_address = <0x7000000>; }; vm2 { is_ffa_partition; debug_name = "cactus-secondary"; load_address = <0x7100000>; vcpu_count = <2>; mem_size = <1048576>; }; }; Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address". If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files. In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files. Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150. The implementation is divided between two scripts: * "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files. * "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration. Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation. The above files contain a lot of comments on how to use them, and also describing the implementation. If the obtained feedback is good, I can work on integrating this in TF-A's build-system. Let me know if anyone has questions. Best regards, João Alves -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org <mailto:Hafnium@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/hafnium

5 years, 7 months

1
0
0 0

[Request for review] Tegra platform changes

by Varun Wadekar

Hi Team, Can you please help review the changes [1] posted for Tegra platforms? These were pushed on 07/09 and I would like to make progress. Several other changes are blocked on this merge. Thanks, Varun [1] https://review.trustedfirmware.org/q/topic:%22tegra-downstream-07092020%22+…

5 years, 7 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. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 361221: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 361221: (TAINTED_SCALAR) /plat/arm/board/arm_fpga/fpga_bl31_setup.c: 196 in fpga_prepare_dtb() 190 if (err) { 191 ERROR("Could not set command line: %d\n", err); 192 } 193 } 194 } 195 >>> CID 361221: (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 196 err = fdt_pack(fdt); 197 if (err < 0) { 198 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, err); 199 } 200 201 clean_dcache_range((uintptr_t)fdt, fdt_blob_size(fdt)); /plat/arm/board/arm_fpga/fpga_bl31_setup.c: 196 in fpga_prepare_dtb() 190 if (err) { 191 ERROR("Could not set command line: %d\n", err); 192 } 193 } 194 } 195 >>> CID 361221: (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 196 err = fdt_pack(fdt); 197 if (err < 0) { 198 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, err); 199 } 200 201 clean_dcache_range((uintptr_t)fdt, fdt_blob_size(fdt)); /plat/arm/board/arm_fpga/fpga_bl31_setup.c: 196 in fpga_prepare_dtb() 190 if (err) { 191 ERROR("Could not set command line: %d\n", err); 192 } 193 } 194 } 195 >>> CID 361221: (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 196 err = fdt_pack(fdt); 197 if (err < 0) { 198 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, err); 199 } 200 201 clean_dcache_range((uintptr_t)fdt, fdt_blob_size(fdt)); /plat/arm/board/arm_fpga/fpga_bl31_setup.c: 196 in fpga_prepare_dtb() 190 if (err) { 191 ERROR("Could not set command line: %d\n", err); 192 } 193 } 194 } 195 >>> CID 361221: (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 196 err = fdt_pack(fdt); 197 if (err < 0) { 198 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, err); 199 } 200 201 clean_dcache_range((uintptr_t)fdt, fdt_blob_size(fdt)); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

5 years, 7 months

1
0
0 0

Re: [TF-A] Erroneous speculative AT workaround

by Varun Wadekar

Hi, I guess I'm late for the party. But I have some questions. Looking at the initial email from Andrew, these two points stood out. --8<-- 1. Whilst looking at the speculative AT workaround in KVM, I compared it against the workaround in TF-A and noticed an inconsistency whereby TF-A **breaks** KVM's workaround. 2. TF-A will also have to be compatible with whatever workaround the EL2 software is using -->8-- Some questions about the unwanted dependency that this fix in TF-A creates. 1. Does KVM team always announce all the dependencies, along with their version numbers, that consumers should use? 2. With the fix in TF-A, are we forcing consumers to upgrade their TF-A blobs? Is this normal practice for consumers? 3. How do we plan to make the upgrade from TF-A side easier? Runtime detection of the feature (similar to the Spectre and Meltdown fixes) comes to mind. -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Manish Badarkhe via TF-A Sent: Thursday, July 30, 2020 10:48 PM To: tf-a(a)lists.trustedfirmware.org Cc: Will Deacon <willdeacon(a)google.com>; android-kvm(a)google.com; Marc Zyngier <mzyngier(a)google.com>; James Morse <James.Morse(a)arm.com>; Andrew Scull <ascull(a)google.com> Subject: Re: [TF-A] Erroneous speculative AT workaround External email: Use caution opening links or attachments Hi All As per discussion over mailing list, we implemented workaround for AT speculative behaviour. If anybody interested they can look into the changes posted here: https://review.trustedfirmware.org/q/topic:%22at_errata_fix%22+(status:open… These changes are currently under review. Thanks Manish Badarkhe On 03/07/2020, 14:43, "TF-A on behalf of Soby Mathew via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > -----Original Message----- > From: Will Deacon <willdeacon(a)google.com> > Sent: 02 July 2020 15:47 > To: Soby Mathew <Soby.Mathew(a)arm.com> > Cc: Andrew Scull <ascull(a)google.com>; Raghu K > <raghu.ncstate(a)icloud.com>; android-kvm(a)google.com; Marc Zyngier > <mzyngier(a)google.com>; James Morse <James.Morse(a)arm.com>; tf- > a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] Erroneous speculative AT workaround > > On Thu, Jul 02, 2020 at 02:15:47PM +0000, Soby Mathew wrote: > > So the fix as we currently understand would involve the following > > sequence > > : > > > > a. On Entry to EL3, save the incoming SCTLR_EL1.M and TCR_EL1.EPDx > bits and set them (ensure TCR_EL1.EPDx =1 prior to SCTLR_EL1.M =1 using > isb()) > > b. Prior to Exit from EL3, after the target context is restored, restore > the SCTLR_EL1.M and TCR_EL1.EPDx bits. > > > > The above sequence now means that any use of AT instruction targeted > > at lower EL from EL3 that require PTW will fault. So prior to use of > > AT, ensure the PTW are re-enabled and disabled back again after the AT > > instructions. > > > > If the above sequence is agreed upon to resolve the errata, then we > > can work on a patch for the same. I suspect current el1 register save > > and restore sequence in TF-A is a bit unwieldy and we may need to > > analyze all the entry points to EL3 to ensure we cover everything. > > Looks good to me, but there's still one niggle that I don't know how to solve. > If EL2 has been audited not to have any executable AT instructions, it may > not have a software workaround. However, if a secure interrupt is taken > from EL2 to EL3 while EL2 is the middle of a world switch, then there is a > small window where an AT instruction present at EL3 cold be speculatively > executed before you've had a chance to mess with SCTLR_EL1. > > Fun! Maybe it's worth documenting this somewhere? Hi Will, Good point, this effectively means every EL2 software must implement the fix similar to KVM for this workaround to be effective (or else EL3 should also be audited to not to have any executable AT instruction). This needs to be communicated. Since this is crossing TF-A boundary and need wider communication, I can initiate some internal discussion on how to communicate this properly. Best Regards Soby Mathew > > Will -- 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

5 years, 7 months

3
4
0 0

Fw: Automate generation of Partition's specific configuration

by Joao Alves

Hi all, Forwarding email below as the referred work may be useful/relevant for other parts of the TF-A project as well. Best regards, João Alves ________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Joao Alves via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Monday, August 3, 2020 5:59 PM To: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org> Subject: [Hafnium] Automate generation of Partition's specific configuration Hello all, I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium. There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions: hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "cactus-primary"; load_address = <0x7000000>; }; vm2 { is_ffa_partition; debug_name = "cactus-secondary"; load_address = <0x7100000>; vcpu_count = <2>; mem_size = <1048576>; }; }; Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address". If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files. In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files. Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150. The implementation is divided between two scripts: * "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files. * "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration. Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation. The above files contain a lot of comments on how to use them, and also describing the implementation. If the obtained feedback is good, I can work on integrating this in TF-A's build-system. Let me know if anyone has questions. Best regards, João Alves -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

5 years, 7 months

1
0
0 0

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

by Varun Wadekar

Hello Olivier, What are your thoughts on keeping Cactus alive for verifying FF-A tests on pre-8.4 Tegra platforms? -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, July 28, 2020 2:27 PM To: Olivier Deprez <Olivier.Deprez(a)arm.com>; Matteo Carlini <Matteo.Carlini(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] cactus and ivy on Tegra194 External email: Use caution opening links or attachments Hi, >> [OD] The scenario we have in TF-A for pre-Armv8.4, is booting OP-TEE as the SPMC (or in other words a colocated SP+SPMC)., but that's a bare SPMD/SPMC boot case without exercising full fledged FF-A (only few direct message exchanges at the moment). [VW] I think it makes sense to keep cactus alive for pre-8.4 in tfa-tests repo. Using cactus would help us verify the initial boot expectations without having to port OP-TEE. I guess, successful handling of the FFA_VERSION call would be a good milestone for us. >> There is another OSS team you may interact with for the pre-Armv8.4 + FF-A story. @Matteo may provide pointers? [VW] Good to know. -Varun -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Tuesday, July 28, 2020 9:09 AM To: Varun Wadekar <vwadekar(a)nvidia.com>; Matteo Carlini <Matteo.Carlini(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org Subject: Re: cactus and ivy on Tegra194 External email: Use caution opening links or attachments Hi Varun, See inline [OD] Regards, Olivier. ________________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: 27 July 2020 18:28 To: Olivier Deprez; tf-a(a)lists.trustedfirmware.org Subject: RE: cactus and ivy on Tegra194 Hi Olivier, Thanks for your response. Looks like Ivy is still getting built in the tree and the fixes I have made are for the UART console driver - so can still be pushed upstream. [OD] It is built although it has no usage in any of TF-A CI test AFAIK. It is still using the former SPCI Alpha SPRT which is now deprecated. I should have mentioned earlier - Tegra194 is based off Arm v8.2. So, we cannot run Hafnium on that platform. The intent is to test the SPMD/SPMC and FF-A interface, before Hafnium comes along. So, the question is, can you please post instructions for pre-8.4 platforms? [OD] The scenario we have in TF-A for pre-Armv8.4, is booting OP-TEE as the SPMC (or in other words a colocated SP+SPMC)., but that's a bare SPMD/SPMC boot case without exercising full fledged FF-A (only few direct message exchanges at the moment). There is another OSS team you may interact with for the pre-Armv8.4 + FF-A story. @Matteo may provide pointers? The dual-cactus use case is interesting. Can we try that on pre-8.4 platforms too? [OD] Cactus was re-purposed only for being used as S-EL1 partitions on top of SPMC/Hafnium. So unfortunately no, you cannot immediately re-use this without S-EL2. There is no plan to let Cactus run at secure physical FF-A instance, although maybe that may work with some adaptation. The dual cactus case, is about instantiating two SPs (or VMs...) on top of Hafnium in the secure side. This is eventually the same binary payload run in two different sandboxes (differentiated by their FF-A id), to which direct message request can be emitted from TFTF to the corresponding FF-A id. -Varun -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Monday, July 27, 2020 1:36 AM To: tf-a(a)lists.trustedfirmware.org; Varun Wadekar <vwadekar(a)nvidia.com> Subject: Re: cactus and ivy on Tegra194 External email: Use caution opening links or attachments 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. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 7 months

2
7
0 0

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

by Alexei Fedorov

I've created https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5153 which should fix the issue. Please review and test. Regards. Alexei ________________________________ 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: 31 July 2020 10:22 To: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; Lauren Wehrmeister <Lauren.Wehrmeister(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Hi, Could you replace .word platform_normal_stacks with .quad platform_normal_stacks in plat\common\aarch64\platform_mp_stack.S and check if it fixes the issue? Regards. Alexei ________________________________ From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Sent: 30 July 2020 23:55 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE +tf-a mailing list. Merging Lauren’s email. Hi Lauren, What command did you use to build TSP? I used the same command line from my original email and added SPD=tspd and I was able to get it to compile with Alexei’s fix. Thanks Raghu ________________________________ Hi, I also came across this issue as I'm trying to create test configurations for compiling BL31/TSP/BL2_AT_EL3 as PIEs, the fix suggested by Alexei worked for BL2_AT_EL3, but it did not work for TSP. I am getting the same error message as Raghu: "./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". Any suggestions? Thanks, Lauren From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Sent: Thursday, July 30, 2020 9:15 AM To: 'Alexei Fedorov' <Alexei.Fedorov(a)arm.com>; 'Olivier Deprez' <Olivier.Deprez(a)arm.com> Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Thanks I’ll try with GCC 11.0. What happens when you run a build without platform_normal_stacks? Does it even boot for you or does it crash in linux?? Trying to understand how you figured this was an issue and what prompted you to fix this by adding the adrp/.word. -Raghu From: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Sent: Thursday, July 30, 2020 9:02 AM To: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Yes. I'm using ENABLE_PIE=1, but the same behaviour will be observed with ENABLE_PIE=0 (except that the linker error won't be reported). I'm isning GCC 11.0.0. Regards. Alexei ________________________________ From: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>> Sent: 30 July 2020 16:50 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Thanks. Are you using ENABLE_PIE=1? I’m using ENABLE_PIE=1 and I don’t see it in bl31.dump file with or without the “.word platform_normal_stacks” statement. However, when I do run FVP to linux without the statement, I see secondary a crash in EL3 with unhandled exception. So it is definitely required. Just trying to pin point what exactly is causing the crash. Thanks Raghu From: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Sent: Thursday, July 30, 2020 8:43 AM To: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE With "platform_normal_stacks": bl31.dump 0000000004015280 l stacks 0000000000000000 platform_normal_stacks bl31.map: stacks 0x0000000004015280 0x4000 *(tzfw_normal_stacks) tzfw_normal_stacks 0x0000000004015280 0x4000 ./build/fvp/debug/bl31/platform_mp_stack.o 0x0000000004019280 __STACKS_END__ = . Without: platform_normal_stacks is missing from bl31.dump, bl31.map: stacks 0x0000000004015270 0x2d90 0x0000000004015270 __STACKS_START__ = . *(tzfw_normal_stacks) 0x0000000004018000 __STACKS_END__ = . Alexei ________________________________ From: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>> Sent: 30 July 2020 15:58 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Makes sense. Thanks. I just tried both debug and release builds, but I don’t see it being _removed_ by the linker. In either case I don’t see symbol information for platform_normal_stacks and only see symbol information for __STACK_START__. So what exactly are you referring to when the linker removes “declare_stack …” ? Also what build configuration? -Raghu From: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Sent: Thursday, July 30, 2020 7:43 AM To: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Having platform_normal_stacks referenced prevents linker from removal of declare_stack platform_normal_stacks, tzfw_normal_stacks, \ PLATFORM_STACK_SIZE, PLATFORM_CORE_COUNT, \ CACHE_WRITEBACK_GRANULE Regards. Alexei ________________________________ From: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com>> Sent: 30 July 2020 15:31 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>>; Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Thanks Olivier, Alexei. >> Is it a copy/paste typo? [RK]Yes. >> Replace .word platform_normal_stacks with adrp x0, platform_normal_stacks [RK]Sure. I can do that. But why does “.word platform_normal_stacks” exist there in the first place? Not sure I understand that line’s purpose. What does replacing it with adrp x0, platform_normal_stacks do? The instruction is after a ret and looks like it will not be executed. I am using aarch64-non-elf- as the toolchain. Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Alexei Fedorov via TF-A Sent: Thursday, July 30, 2020 6:58 AM To: Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Replace .word platform_normal_stacks with adrp x0, platform_normal_stacks Regards. Alexei. ________________________________ From: Olivier Deprez <Olivier.Deprez(a)arm.com<mailto:Olivier.Deprez@arm.com>> Sent: 30 July 2020 14:17 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE 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<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Alexei Fedorov via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 30 July 2020 14:53 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-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<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 30 July 2020 02:44 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 7 months

3
6
0 0

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

by raghu.ncstate＠icloud.com

+tf-a mailing list. Merging Lauren's email. Hi Lauren, What command did you use to build TSP? I used the same command line from my original email and added SPD=tspd and I was able to get it to compile with Alexei's fix. Thanks Raghu _____ Hi, I also came across this issue as I'm trying to create test configurations for compiling BL31/TSP/BL2_AT_EL3 as PIEs, the fix suggested by Alexei worked for BL2_AT_EL3, but it did not work for TSP. I am getting the same error message as Raghu: "./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". Any suggestions? Thanks, Lauren From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Sent: Thursday, July 30, 2020 9:15 AM To: 'Alexei Fedorov' <Alexei.Fedorov(a)arm.com>; 'Olivier Deprez' <Olivier.Deprez(a)arm.com> Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Thanks I'll try with GCC 11.0. What happens when you run a build without platform_normal_stacks? Does it even boot for you or does it crash in linux?? Trying to understand how you figured this was an issue and what prompted you to fix this by adding the adrp/.word. -Raghu From: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com> > Sent: Thursday, July 30, 2020 9:02 AM To: raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> ; Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> > Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Yes. I'm using ENABLE_PIE=1, but the same behaviour will be observed with ENABLE_PIE=0 (except that the linker error won't be reported). I'm isning GCC 11.0.0. Regards. Alexei _____ From: raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> > Sent: 30 July 2020 16:50 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com> >; Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> > Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Thanks. Are you using ENABLE_PIE=1? I'm using ENABLE_PIE=1 and I don't see it in bl31.dump file with or without the ".word platform_normal_stacks" statement. However, when I do run FVP to linux without the statement, I see secondary a crash in EL3 with unhandled exception. So it is definitely required. Just trying to pin point what exactly is causing the crash. Thanks Raghu From: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com> > Sent: Thursday, July 30, 2020 8:43 AM To: raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> ; Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> > Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE With "platform_normal_stacks": bl31.dump 0000000004015280 l stacks 0000000000000000 platform_normal_stacks bl31.map: stacks 0x0000000004015280 0x4000 *(tzfw_normal_stacks) tzfw_normal_stacks 0x0000000004015280 0x4000 ./build/fvp/debug/bl31/platform_mp_stack.o 0x0000000004019280 __STACKS_END__ = . Without: platform_normal_stacks is missing from bl31.dump, bl31.map: stacks 0x0000000004015270 0x2d90 0x0000000004015270 __STACKS_START__ = . *(tzfw_normal_stacks) 0x0000000004018000 __STACKS_END__ = . Alexei _____ From: raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> > Sent: 30 July 2020 15:58 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com> >; Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> > Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Makes sense. Thanks. I just tried both debug and release builds, but I don't see it being _removed_ by the linker. In either case I don't see symbol information for platform_normal_stacks and only see symbol information for __STACK_START__. So what exactly are you referring to when the linker removes "declare_stack ." ? Also what build configuration? -Raghu From: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com> > Sent: Thursday, July 30, 2020 7:43 AM To: raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> ; Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> > Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Having platform_normal_stacks referenced prevents linker from removal of declare_stack platform_normal_stacks, tzfw_normal_stacks, \ PLATFORM_STACK_SIZE, PLATFORM_CORE_COUNT, \ CACHE_WRITEBACK_GRANULE Regards. Alexei _____ From: raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> <raghu.ncstate(a)icloud.com <mailto:raghu.ncstate@icloud.com> > Sent: 30 July 2020 15:31 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com> >; Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> > Subject: RE: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Thanks Olivier, Alexei. >> Is it a copy/paste typo? [RK]Yes. >> Replace .word platform_normal_stacks with adrp x0, platform_normal_stacks [RK]Sure. I can do that. But why does ".word platform_normal_stacks" exist there in the first place? Not sure I understand that line's purpose. What does replacing it with adrp x0, platform_normal_stacks do? The instruction is after a ret and looks like it will not be executed. I am using aarch64-non-elf- as the toolchain. Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org> > On Behalf Of Alexei Fedorov via TF-A Sent: Thursday, July 30, 2020 6:58 AM To: Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> >; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE Replace .word platform_normal_stacks with adrp x0, platform_normal_stacks Regards. Alexei. _____ From: Olivier Deprez <Olivier.Deprez(a)arm.com <mailto:Olivier.Deprez@arm.com> > Sent: 30 July 2020 14:17 To: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> >; Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com> > Subject: Re: [TF-A] Linker error on integration branch for FVP with ENABLE_PIE 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- build.html#performing-an-initial-build> https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/initial-b uild.html#performing-an-initial-build 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 < <mailto:tf-a-bounces@lists.trustedfirmware.org> tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Alexei Fedorov via TF-A < <mailto:tf-a@lists.trustedfirmware.org> tf-a(a)lists.trustedfirmware.org> Sent: 30 July 2020 14:53 To: <mailto:tf-a@lists.trustedfirmware.org> 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 < <mailto:tf-a-bounces@lists.trustedfirmware.org> tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via TF-A < <mailto:tf-a@lists.trustedfirmware.org> tf-a(a)lists.trustedfirmware.org> Sent: 30 July 2020 02:44 To: <mailto:tf-a@lists.trustedfirmware.org> tf-a(a)lists.trustedfirmware.org < <mailto:tf-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> 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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 7 months

2
1
0 0

Re: [TF-A] Erroneous speculative AT workaround

by Manish Badarkhe

Hi All As per discussion over mailing list, we implemented workaround for AT speculative behaviour. If anybody interested they can look into the changes posted here: https://review.trustedfirmware.org/q/topic:%22at_errata_fix%22+(status:open… These changes are currently under review. Thanks Manish Badarkhe On 03/07/2020, 14:43, "TF-A on behalf of Soby Mathew via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > -----Original Message----- > From: Will Deacon <willdeacon(a)google.com> > Sent: 02 July 2020 15:47 > To: Soby Mathew <Soby.Mathew(a)arm.com> > Cc: Andrew Scull <ascull(a)google.com>; Raghu K > <raghu.ncstate(a)icloud.com>; android-kvm(a)google.com; Marc Zyngier > <mzyngier(a)google.com>; James Morse <James.Morse(a)arm.com>; tf- > a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] Erroneous speculative AT workaround > > On Thu, Jul 02, 2020 at 02:15:47PM +0000, Soby Mathew wrote: > > So the fix as we currently understand would involve the following > > sequence > > : > > > > a. On Entry to EL3, save the incoming SCTLR_EL1.M and TCR_EL1.EPDx > bits and set them (ensure TCR_EL1.EPDx =1 prior to SCTLR_EL1.M =1 using > isb()) > > b. Prior to Exit from EL3, after the target context is restored, restore > the SCTLR_EL1.M and TCR_EL1.EPDx bits. > > > > The above sequence now means that any use of AT instruction targeted > > at lower EL from EL3 that require PTW will fault. So prior to use of > > AT, ensure the PTW are re-enabled and disabled back again after the AT > > instructions. > > > > If the above sequence is agreed upon to resolve the errata, then we > > can work on a patch for the same. I suspect current el1 register save > > and restore sequence in TF-A is a bit unwieldy and we may need to > > analyze all the entry points to EL3 to ensure we cover everything. > > Looks good to me, but there's still one niggle that I don't know how to solve. > If EL2 has been audited not to have any executable AT instructions, it may > not have a software workaround. However, if a secure interrupt is taken > from EL2 to EL3 while EL2 is the middle of a world switch, then there is a > small window where an AT instruction present at EL3 cold be speculatively > executed before you've had a chance to mess with SCTLR_EL1. > > Fun! Maybe it's worth documenting this somewhere? Hi Will, Good point, this effectively means every EL2 software must implement the fix similar to KVM for this workaround to be effective (or else EL3 should also be audited to not to have any executable AT instruction). This needs to be communicated. Since this is crossing TF-A boundary and need wider communication, I can initiate some internal discussion on how to communicate this properly. Best Regards Soby Mathew > > Will -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 7 months

1
0
0 0

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

by Lauren Wehrmeister

Hi, I also came across this issue as I'm trying to create test configurations for compiling BL31/TSP/BL2_AT_EL3 as PIEs, the fix suggested by Alexei worked for BL2_AT_EL3, but it did not work for TSP. I am getting the same error message as Raghu: "./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". Any suggestions? Thanks, Lauren

5 years, 7 months

1
0
0 0

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

5 years, 7 months

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

5 years, 7 months

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

5 years, 7 months

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.

5 years, 7 months

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

5 years, 7 months

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 >

5 years, 7 months

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

5 years, 7 months

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.

5 years, 7 months

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

5 years, 7 months

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

5 years, 7 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. 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…

5 years, 7 months

1
0
0 0

Re: [TF-A] [PATCH] Add support for ARMv8.3-SPE

by Olivier Deprez

Hi Wei Li, Thanks for your change which looks correct. Can you possibly submit it to review.trustedfirmware.org? We can follow up with the review from the gerrit interface. Thanks, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Wei Li via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 22 July 2020 14:25 To: tf-a(a)lists.trustedfirmware.org Cc: huawei.libin(a)huawei.com; guohanjun(a)huawei.com Subject: [TF-A] [PATCH] Add support for ARMv8.3-SPE When ARMv8.3-SPE is implemented, ID_AA64DFR0_EL1.PMSVer is read as 0b0010, update the version check to support ARMv8.3-SPE or higher. Signed-off-by: Wei Li <liwei391(a)huawei.com> --- lib/extensions/spe/spe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/extensions/spe/spe.c b/lib/extensions/spe/spe.c index 78876c66b..aa0bcd8ea 100644 --- a/lib/extensions/spe/spe.c +++ b/lib/extensions/spe/spe.c @@ -25,7 +25,7 @@ bool spe_supported(void) uint64_t features; features = read_id_aa64dfr0_el1() >> ID_AA64DFR0_PMS_SHIFT; - return (features & ID_AA64DFR0_PMS_MASK) == 1U; + return (features & ID_AA64DFR0_PMS_MASK) != 0U; } void spe_enable(bool el2_unused) -- 2.17.1 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 7 months

1
0
0 0

[PATCH] Add support for ARMv8.3-SPE

by Wei Li

When ARMv8.3-SPE is implemented, ID_AA64DFR0_EL1.PMSVer is read as 0b0010, update the version check to support ARMv8.3-SPE or higher. Signed-off-by: Wei Li <liwei391(a)huawei.com> --- lib/extensions/spe/spe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/extensions/spe/spe.c b/lib/extensions/spe/spe.c index 78876c66b..aa0bcd8ea 100644 --- a/lib/extensions/spe/spe.c +++ b/lib/extensions/spe/spe.c @@ -25,7 +25,7 @@ bool spe_supported(void) uint64_t features; features = read_id_aa64dfr0_el1() >> ID_AA64DFR0_PMS_SHIFT; - return (features & ID_AA64DFR0_PMS_MASK) == 1U; + return (features & ID_AA64DFR0_PMS_MASK) != 0U; } void spe_enable(bool el2_unused) -- 2.17.1

5 years, 7 months

1
0
0 0

Re: [TF-A] [Hafnium] Debugging page table creation in Hafnium

by Madhukar Pappireddy

Hi Raghu and Andrew, Thanks for the inputs. I have added the mm_vm_dump() call to the mm_init() function but nothing was dumped to uart log. I guess I am missing something trivial. It looks like mm_root_table_count() returns 0. Any suggestions? diff --git a/src/mm.c b/src/mm.c index 2e352e9..7c56a09 100644 --- a/src/mm.c +++ b/src/mm.c @@ -1041,5 +1041,7 @@ bool mm_init(struct mpool *ppool) mm_identity_map(stage1_locked, layout_data_begin(), layout_data_end(), MM_MODE_R | MM_MODE_W, ppool); + mm_vm_dump(&ptable); + return arch_mm_init(ptable.root); } Thanks, Madhukar -----Original Message----- From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Walbran via Hafnium Sent: Friday, July 17, 2020 6:10 AM To: Raghu K <raghu.ncstate(a)icloud.com> Cc: hafnium(a)lists.trustedfirmware.org Subject: Re: [Hafnium] Debugging page table creation in Hafnium Yep, mm_vm_dump sounds like what you're looking for. You can add a call where you like and it will go to the log UART. On Thu, 16 Jul 2020 at 19:14, Raghu K via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Quick search indicates mm_vm_dump() and the functions it calls in > src/mm.c should do what you want. i've not tried it or don't know the > format, but this may be what you are looking for. > > -Raghu > > On 7/16/20 11:03 AM, Madhukar Pappireddy via Hafnium wrote: > > Hi, > > > > I was wondering if there is support in Hafnium to dump page tables > > to a > log file. I am new to the Hafnium project and would appreciate any help. > Below is an example from TF-A which provides such provision. > > > > ......<snip> > > VERBOSE: Translation tables state: > > VERBOSE: Xlat regime: EL3 > > VERBOSE: Max allowed PA: 0xfffffffff > > VERBOSE: Max allowed VA: 0xfffffffff > > VERBOSE: Max mapped PA: 0x2f1fffff > > VERBOSE: Max mapped VA: 0x2f1fffff > > VERBOSE: Initial lookup level: 1 > > VERBOSE: Entries @initial lookup level: 64 > > VERBOSE: Used 3 sub-tables out of 5 (spare: 2) > > [LV1] VA:0x0 size:0x40000000 > > [LV2] VA:0x0 size:0x200000 > > [LV3] VA:0x0 PA:0x0 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x1000 PA:0x1000 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x2000 PA:0x2000 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x3000 PA:0x3000 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x4000 PA:0x4000 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x5000 PA:0x5000 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x6000 PA:0x6000 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x7000 PA:0x7000 size:0x1000 MEM-RO-EXEC-S > > [LV3] VA:0x8000 PA:0x8000 size:0x1000 MEM-RO-XN-S > > [LV3] VA:0x9000 PA:0x9000 size:0x1000 MEM-RO-XN-S > > [LV3] VA:0xa000 PA:0xa000 size:0x1000 MEM-RO-XN-S > > [LV3] VA:0xb000 size:0x1000 > > [LV3] (500 invalid descriptors omitted) > > [LV2] VA:0x200000 size:0x200000 > > [LV2] (30 invalid descriptors omitted) > > [LV2] VA:0x4000000 size:0x200000 ..... <snip> > > > > Thanks, > > Madhukar > > > > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/hafnium >

5 years, 8 months

2
3
0 0

Re: [TF-A] Pointer Authentication keys

by Soby Mathew

Hi Varun, AIU, Usually 2 keys are used to protect 2 different software contexts for enforcing the security boundary between them. This is the case for kernel and userspace. In TF-A, every BL image is allowed to choose the IA key to use, hence every BL image can have a separate IA key. Each BL image is executing within a single security domain and hence there is less use create a boundary within the BL image by using the 2nd key registers. The Compiler by default selects either IA or IB instruction key register to use by default. It cannot automatically make use of both key registers and it doesn't support the use of DA or DB yet I think. There are some function attributes which allow to use a different key at a function level, but the functions need to be marked out manually. But the requirement for creating the sub-domain within a BL image by specifying a different key for certain functions has not yet been seen AFAIK. Best Regards Soby Mathew From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A Sent: 13 July 2020 22:20 To: tf-a(a)lists.trustedfirmware.org Cc: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com> Subject: [TF-A] Pointer Authentication keys Hi, >From the initial read of the Arm ARM, there are multiple keys (instruction, data) provided for authenticating pointers. But the current implementation only writes IA key [1]. I would like to understand the thought process behind programming only one key here. AFAIU, we should enable all keys - IA, IB, DA, DB. -Varun [1] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/…

5 years, 8 months

2
1
0 0

Re: [TF-A] Announcing some changes around the code review label in Gerrit

by Joanna Farley

Hi Julius, Sandrine is away on vacation so I thought I would follow up as we had a chat in one of our team meetings about the point below. > On 07/07/2020, 23:05, "TF-A on behalf of Julius Werner via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: >> IOW, you're fine with both options but you'd prefer to have different >> people setting MR+1 and COR+1 (or CR+1 in the special cases mentioned >> above), right? Just want to double-check I understood your position. >Right. So when we had +1/+2 CR before these changes we endeavoured to ensure that these were done by different people and if a maintainer gave a +1 they resisted also giving a +2 as we recognise having multiple eyes is always advantageous. So the general feeling was that this should be the recommended best practice. However, the feeling was also that this specific recommendation should not be strictly enforced by gerrit checking as on occasions it is possible to give both on simple patches and maintainers and code owners in this case can be trusted to make the correct choice. The enforcing of them in Gerrit should be viewed as an aid to try and avoid mistakes rather than strict control for as you say we don't expect people to intentionally break the rules. Perhaps a warning in this case can be made to remind folks what's best practice here. For now though as mentioned as we practice the new rules and recommendations we will use an honour system rather than strict enforcement along with updating the documented rules and recomendations. Thanks Joanna

5 years, 8 months

2
1
0 0

Re: [TF-A] Deadlock in SGI RAS handling

by Soby Mathew

Hi Raghu, The Exception Handling framework (EHF) was designed to provide prioritization between the EL3 interrupts and EA although EA will always have highest priority since it cannot be blocked. In the case you describe, the driver in EL3 which is handling the RAS errors would need to ensure serialization of the events delivered to the S-EL0 payload somehow. This could be either via holding the event in a queue in EL3 till EL0 is done with processing the first event or the EL0 payload is capable of re-entry and can manage a queue internally. In case of MM, I suppose re-entry is not an option and hence a holding queue in EL3 driver needs to be implemented. The current implementation in sgi_ras.c doesn't do this currently as this was a PoC to showcase the RAS flow. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghu K > via TF-A > Sent: 13 July 2020 22:28 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Deadlock in SGI RAS handling > > Hi All, > > I was going through some code in sgi_ras.c and was wondering if the > situation mentioned below could cause a deadlock or if i'm missing > something. It seems like it is possible to deadlock if we enter MM in S- > EL0(say through an MM_COMMUNICATE SMC or perhaps an initial RAS > interrupt) followed by a SYNC EA or ASYNC EA on the same core. sgi_ras.c > seems like it registers the same handler for both interrupts and aborts. > While interrupts can be blocked/masked, SYNC EA's cannot be blocked(not > that i know of), and i don't see SErrors being blocked on the path to the EA > handler and entry to MM. If this situation does occur, it seems like we could > deadlock when the EA attempts to enter MM again in the interrupt handler. > Is there something that would prevent this situation from happening? > > > Thanks > Raghu > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 8 months

1
0
0 0

Deadlock in SGI RAS handling

by Raghu K

Hi All, I was going through some code in sgi_ras.c and was wondering if the situation mentioned below could cause a deadlock or if i'm missing something. It seems like it is possible to deadlock if we enter MM in S-EL0(say through an MM_COMMUNICATE SMC or perhaps an initial RAS interrupt) followed by a SYNC EA or ASYNC EA on the same core. sgi_ras.c seems like it registers the same handler for both interrupts and aborts. While interrupts can be blocked/masked, SYNC EA's cannot be blocked(not that i know of), and i don't see SErrors being blocked on the path to the EA handler and entry to MM. If this situation does occur, it seems like we could deadlock when the EA attempts to enter MM again in the interrupt handler. Is there something that would prevent this situation from happening? Thanks Raghu

5 years, 8 months

1
0
0 0

Pointer Authentication keys

by Varun Wadekar

Hi, >From the initial read of the Arm ARM, there are multiple keys (instruction, data) provided for authenticating pointers. But the current implementation only writes IA key [1]. I would like to understand the thought process behind programming only one key here. AFAIU, we should enable all keys - IA, IB, DA, DB. -Varun [1] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/…

5 years, 8 months

1
0
0 0

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

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 16th 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: * Secure EL2 SPM (Secure Partition Manager) Hafnium-based * In this TF-A Tech Forum session we present the status and open roadmap for the Secure Partition Manager firmware development. The TF-A SPM is the reference open source implementation for the PSA FF-A (Platform Security Architecture Firmware Framework for A-class) specification in the Secure world. It leverages the Armv8.4-Secure EL2 extension bringing virtualization technology in the Secure world (S-EL2 exception level). The development derives originally from the Google Hafnium project, which has been recently transitioned to https://www.trustedfirmware.org/ under the BSD 3-Clause license. * 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

5 years, 8 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. 4 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 4 of 4 defect(s) ** 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: 249 in rpi4_prepare_dtb() 243 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 244 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 245 246 offs = fdt_path_offset(dtb, "/chosen"); 247 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 248 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 249 ret = fdt_pack(dtb); 250 if (ret < 0) 251 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 252 253 clean_dcache_range((uintptr_t)dtb, dtb_size(dtb)); 254 INFO("Changed device tree to advertise PSCI.\n"); /plat/rpi/rpi4/rpi4_bl31_setup.c: 220 in rpi4_prepare_dtb() 214 int ret, offs; 215 216 /* Return if no device tree is detected */ 217 if (fdt_check_header(dtb) != 0) 218 return; 219 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->totalsize" to a tainted sink. 220 ret = fdt_open_into(dtb, dtb, 0x100000); 221 if (ret < 0) { 222 ERROR("Invalid Device Tree at %p: error %d\n", dtb, ret); 223 return; 224 } 225 /plat/rpi/rpi4/rpi4_bl31_setup.c: 249 in rpi4_prepare_dtb() 243 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 244 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 245 246 offs = fdt_path_offset(dtb, "/chosen"); 247 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 248 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 249 ret = fdt_pack(dtb); 250 if (ret < 0) 251 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 252 253 clean_dcache_range((uintptr_t)dtb, dtb_size(dtb)); 254 INFO("Changed device tree to advertise PSCI.\n"); /plat/rpi/rpi4/rpi4_bl31_setup.c: 249 in rpi4_prepare_dtb() 243 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 244 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 245 246 offs = fdt_path_offset(dtb, "/chosen"); 247 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 248 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 249 ret = fdt_pack(dtb); 250 if (ret < 0) 251 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 252 253 clean_dcache_range((uintptr_t)dtb, dtb_size(dtb)); 254 INFO("Changed device tree to advertise PSCI.\n"); /plat/rpi/rpi4/rpi4_bl31_setup.c: 249 in rpi4_prepare_dtb() 243 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 244 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 245 246 offs = fdt_path_offset(dtb, "/chosen"); 247 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 248 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 249 ret = fdt_pack(dtb); 250 if (ret < 0) 251 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 252 253 clean_dcache_range((uintptr_t)dtb, dtb_size(dtb)); 254 INFO("Changed device tree to advertise PSCI.\n"); /plat/rpi/rpi4/rpi4_bl31_setup.c: 220 in rpi4_prepare_dtb() 214 int ret, offs; 215 216 /* Return if no device tree is detected */ 217 if (fdt_check_header(dtb) != 0) 218 return; 219 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_strings" to a tainted sink. 220 ret = fdt_open_into(dtb, dtb, 0x100000); 221 if (ret < 0) { 222 ERROR("Invalid Device Tree at %p: error %d\n", dtb, ret); 223 return; 224 } 225 ** 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: 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: 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->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); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 8 months

1
0
0 0

Re: [TF-A] Announcing some changes around the code review label in Gerrit

by Joanna Farley

+1 for re-introduction of 'Code-Review' label in addition to 'Code-Owner-Review' label. I would like to see the enforcement of authors of patches not being allowed to self review eventually for all labels. Hopefully we can enable maintainers who are not the author of deadlocked patches to allow the setting of all required +1's to labels is situations where this is necessary for admin purposes after due consideration. I agree though while this process is settling down an honour system is appropriate. Cheers Joanna On 01/07/2020, 08:56, "TF-A on behalf of Sandrine Bailleux via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Julius, On 7/1/20 2:13 AM, Julius Werner wrote: > Hi Sandrine, > > Sounds like good changes in general! I'm curious what the ACLs are for > Code-Owner-Review? Is it tied to docs/about/maintainers.rst or just > based on the honor system? (I notice that I seem to be able to give a > +1 for code I'm not owning, but maybe that's because I am a > maintainer?) Right now, the ACLs are not tied to docs/about/maintainers.rst (any registered user could vote on this label) and it is just based on the honor system. However, I'd like this to be enforced in the future, we just haven't had the time to put the right tooling in place for that. Also we did not want to spend time on developing such scripts before we tried out these process changes in practice. If they proved too heavy or inconvenient, part of this work would have gone to waste. BTW, any help for the tooling is welcome! If you've got plugin configuration files or scripts we could reuse (with an appropriate license) or even tips on how to best set this up, please feel free to share these. > Also, are code owners allowed to +1 themselves (I think > we said we didn't want maintainers to do that, but for code owners I > could see how we might want to allow it since there are usually not > that many)? What do we do when someone uploads the first patch for a > new platform, do they just COR+1 themselves (since there is no code > owner yet)? That is indeed a grey area. As you say, many modules have a single code owner and we need to agree on how we would like such code reviews to be conducted. Thanks for starting this discussion! One option as you say would be to allow code owners to self-review their patches but I am not convinced we would gain anything out of this. It sounds like a tick-box exercise to me, an admin overhead just to get the patch through the system and I would like to avoid that as much as possible. It is likely that a patch submitter has already self-reviewed his code before posting a patch anyway. The alternative we've been discussing in the team is to call out another reviewer in these situations. I think that there is still value in having a second fresh pair of eyes on a patch. Even if the reviewer has no particular expertise on this specific module, they can still catch potential logic problems or structural issues in the code. The latter would be my preference. What do others think? > I think it might still be useful to retain the existing Code-Review as > a +1/-1 label next to the two new ones, just to allow other interested > parties to record their opinion (without it having any enforcing > effect on the merge). In other Gerrit instances I have used people > often like to give CR+1 as a "I'm not the one who needs to approve > this but I have looked at it and think it's fine" or a CR-1 as a "I > can't stop you from doing this but I still want to be clear that I > don't think it's a good idea". It allows people outside the official > approval process a clearer way to participate and can aid the official > approvers in their decisions (e.g. when I am reviewing a patch as a > maintainer that already has a CR-1 from someone else I know to pay > extra attention to their concerns, and it's more visible than just > some random comment further up in the list). What do you think? That's a very good idea, thanks! It also aligns with Javier's concerns, which sound perfectly valid to me. I think your proposal of having 3 distinct labels is better than having code owners and non-code owners voting on the same generic 'Code-Review' label, which is what Javier was suggesting. It clarifies further the intent of each label and as you say allows us to configure different rules for each (i.e. make the generic 'Code-Review' label informative/optional, while making the 'Code-Owner-Review' label mandatory for patch submission). I am gonna wait for others' opinions on this before changing the configuration in Gerrit again. I see Raghu agrees with this approach. If nobody disagrees by the end of the week, I'll do these changes on Monday. In the meantime, as discussed above, any registered user can vote on the new 'Code-Owner-Review' label so let's continue to use that for the rest of this week. Regards, Sandrine -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 8 months

3
5
0 0

Re: [TF-A] Announcing some changes around the code review label in Gerrit

by Varun Wadekar

Hello Sandrine, IMO, the code review process has now evolved from the previous version. I am not too clear on the final outcome. Does it make sense to add a "lifecycle of a review" section to the initial proposal? -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandrine Bailleux via TF-A Sent: Monday, July 6, 2020 1:53 AM To: Julius Werner <jwerner(a)chromium.org> Cc: tf-a <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Announcing some changes around the code review label in Gerrit External email: Use caution opening links or attachments Hi Julius and all, As agreed and announced last week, I've now reintroduced the Code-Review label in addition to the Code-Owner-Review and Maintainer-Review ones. The Code-Review label is purely informational and won't influence whether a patch is submittable in Gerrit. Anyone should be able to vote on this label, if you face any issue please let me know. On 7/1/20 11:12 PM, Julius Werner wrote: >> BTW, any help for the tooling is welcome! If you've got plugin >> configuration files or scripts we could reuse (with an appropriate >> license) or even tips on how to best set this up, please feel free to >> share these. > > The Chromium Gerrit has an owners-enforcement system but I'm not > familiar with how exactly they set it up. I think they're using this > plugin > https://gerrit.googlesource.com/plugins/find-owners/+/refs/heads/maste > r and this is where it's integrated into Gerrit submission rules: > https://chromium.googlesource.com/chromiumos/+/refs/meta/config/rules. > pl . It works by having a file called OWNERS in certain directories > which sets the owners for the subtree below it, so we would have to > rewrite the current code owner list in that format if we wanted to use > it. This "find-owners" plugin sounds promising! Thanks for the pointers. I notice the "reviewers" plugin [1] is installed on review.tf.org but it does not sound as configurable as "find-owners". Rewriting the current code owners list to use the OWNERS format does not sound like a big task to me (just a dull one... could be scripted, though) so this approach definitely sounds worth investigating to me. [1] https://review.trustedfirmware.org/plugins/reviewers/Documentation/index.ht… > There also seems to be this completely separate plugin that claims to > do roughly the same thing, I have no idea where the difference is > between the two: > https://gerrit.googlesource.com/plugins/owners/+/refs/heads/master I notice the "find-owners" plugin documentation mentions that "this plugin works with Gerrit projects that use Android or Chromium compatible OWNERS files" so maybe they started off from the generic "owners" plugin and customized it for Android/Chromium's needs? Just a guess. Anyway, worth a look as well, thanks! [2] https://gerrit.googlesource.com/plugins/find-owners/+/refs/heads/master/src… >> One option as you say would be to allow code owners to self-review their >> patches but I am not convinced we would gain anything out of this. It >> sounds like a tick-box exercise to me, an admin overhead just to get the >> patch through the system and I would like to avoid that as much as >> possible. It is likely that a patch submitter has already self-reviewed >> his code before posting a patch anyway. >> >> The alternative we've been discussing in the team is to call out another >> reviewer in these situations. I think that there is still value in >> having a second fresh pair of eyes on a patch. Even if the reviewer has >> no particular expertise on this specific module, they can still catch >> potential logic problems or structural issues in the code. > > I definitely did not mean to suggest that these patches should not be > reviewed at all -- I was just talking about the Code-Owner-Review > label. There would still be a maintainer review, of course, and it > seems like a good idea to get additional reviews from other people > too. They just couldn't set the COR+1 bit once we start ACLing it. Right, I see (and agree with you). > Basically, each of these bits have their own purpose, and I would see > the purpose of the COR+1 bit to be that the person most familiar with > that particular piece of code has made sure that it fits in and > doesn't cause unexpected problems with certain quirky configurations > or something like that. That's important when, say, I make a generic > refactoring that touches a platform I'm unfamiliar with, but if the > code owner adds to their own platform that's probably already a given > and they are likely still the best person to judge that, even for > their own code. Yes, that makes sense to me. > That all code gets reviewed by people other than the author I would > see as a somewhat orthogonal concern that should be checked > independently. So maybe the rule could be that if the code owner sets > COR+1 for themselves, there needs to be at least one Code-Review+1 (if > we reintroduce that label) from another person (who is also not the > one setting Maintainer-Review+1) to make sure the minimum amount of > reviews stays the same. Or maybe these should all be completely > independent checks so every patch needs a Code-Owner-Review+1 (can be > from the author), a Maintainer-Review+1 (not from the author) and at > least two Code-Review+1 from people other than the author -- with the > normal expectation that when a maintainer or code owner reviews a > patch, they would also set Code-Review+1 (as a general sign that they > reviewed the patch) in addition to their special meaning flag. I still don't see the benefit of code owners setting COR+1 for themselves. I would think that a patch owner already reviews his own patch before posting it for review so a self COR+1 is just reinstating the obvious in my eyes. Your first suggestion (i.e. having at least one CR+1 from another person when a patch author cannot find another code owner to review their patches) sounds aligned with what I proposed earlier. Your second suggestion sounds a bit too heavy to me. The fact that people would have to replay their vote on several labels sounds like an admin overhead to me. I guess this would simplify the ACL configuration but I would prefer to avoid this if we can. So I suggest the following. We could have 2 ways to get a patch approved. 1) For patches that have multiple code owners: * COR+1 (not from patch owner) * MR+1 (not from patch owner, not from the person setting COR+1) 2) For patches that a have single code owner: * CR+1 (not from patch owner) * MR+1 (not from patch owner, not from the person setting CR+1) In 2), I like your suggestion of mandating 2 CR+1 but I fear this might be difficult to achieve in practice (simply because we might not have enough reviewers for this). Note that in some cases, we would need to mix both policies. If a patch modifies several modules, some of them having multiple code owners and others having a single code owner, we would apply one or the other policy for each module. How does that sound? Also, 1) assumes we always want different individuals doing the code-owner review and the maintainer review. I personally don't feel strongly about this split and I would be fine with the same person doing both types of review, as they are typically looking at different criteria. What do others think? Regards, Sandrine -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 8 months

2
1
0 0

Re: [TF-A] Erroneous speculative AT workaround

by Soby Mathew

Thanks Andrew for raising the issue and Marc and Raghu for your inputs. The effect of stage 2 when Stage 1 is disabled is something that was overlooked in the workaround implementation. After some discussions this is what we currently understand regarding the problem. 1. EL3 does not modify the EL2 stage 1 translations and hence any speculative execution of AT execution in EL3 and resulting PTW and TLB caching should not be a problem as we always return to the same context in EL2. TF-A in EL3 need not worry about this. Also, we expect that future CPUs having v8.4 extensions for S-EL2 will have already corrected this errata. 2. Whenever the EL1/0 Stage 1 translations are switched in EL3 as part of switching the worlds, it should take Stage 2 into account. Hence disabling the Stage 1 MMU is not effective, as Marc pointed out, because speculative PTW can still take place using Stage 2 identity mapping. After discussion with James, we also realized that flipping the SCR_EL3.NS bit could take Stage 2 out of context (Stage 2 is not valid in secure world) leaving Stage 1 pointing to invalid translations. As discussed in previous emails, on Entry to EL3, if TCR_EL1.EPDx = 1 and SCTLR_EL3.M = 1, any speculative AT PTWs for EL1 context can be prevented (including Stage 2). So the fix as we currently understand would involve the following sequence : a. On Entry to EL3, save the incoming SCTLR_EL1.M and TCR_EL1.EPDx bits and set them (ensure TCR_EL1.EPDx =1 prior to SCTLR_EL1.M =1 using isb()) b. Prior to Exit from EL3, after the target context is restored, restore the SCTLR_EL1.M and TCR_EL1.EPDx bits. The above sequence now means that any use of AT instruction targeted at lower EL from EL3 that require PTW will fault. So prior to use of AT, ensure the PTW are re-enabled and disabled back again after the AT instructions. If the above sequence is agreed upon to resolve the errata, then we can work on a patch for the same. I suspect current el1 register save and restore sequence in TF-A is a bit unwieldy and we may need to analyze all the entry points to EL3 to ensure we cover everything. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew > Scull via TF-A > Sent: 02 July 2020 09:20 > To: Raghu K <raghu.ncstate(a)icloud.com> > Cc: android-kvm(a)google.com; willdeacon(a)google.com; Marc Zyngier > <mzyngier(a)google.com>; tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] Erroneous speculative AT workaround > > On Wed, Jul 01, 2020 at 05:47:00PM -0700, Raghu K wrote: > > This is interesting. It appears that there is no way on entry to EL3 > > to guarantee that the out-of-context(el2 and el1) translation regimes > > are in a consistent state and on every entry into EL3, we have to > > conservatively assume that it is in an inconsistent state. This is > > because of the situation Andrew mentioned(interrupts to EL3 can occur at any > time). > > > > If this is the case, on EL3 entry: > > 1) For EL1, we will need to save SCTLR_EL1, set SCTLR_EL1.M = 1,.EPDx > > = 0 > > This would still be racing against any potential speculative execution of an AT > instruction upon the switch to EL3, IIUC. The window would be much smaller > but not entirely eliminated. > > For KVM, this would be enough as KVM will have already applied this > workaround (with Marc's corrections) whenever it is going to enter an > inconsistent state. However, other EL2 software may choose to handle the > errata differently, possibly going to the lengths of ensuring that no AT > instruction is ever mapped executable. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 8 months

4
4
0 0

Re: [TF-A] Erroneous speculative AT workaround

by Raghu K

5 years, 8 months

1
0
0 0

Re: [TF-A] Erroneous speculative AT workaround

by Raghu K

5 years, 8 months

1
0
0 0

Re: [TF-A] Erroneous speculative AT workaround

by Raghu K

This is interesting. It appears that there is no way on entry to EL3 to guarantee that the out-of-context(el2 and el1) translation regimes are in a consistent state and on every entry into EL3, we have to conservatively assume that it is in an inconsistent state. This is because of the situation Andrew mentioned(interrupts to EL3 can occur at any time). If this is the case, on EL3 entry: 1) For EL1, we will need to save SCTLR_EL1, set SCTLR_EL1.M = 1,.EPDx = 0 2) Set whatever bits we need to for EL2 and S2 translations to not succeed(What are these?) 3) DSB, to ensure no speculative AT can be issued until completion of DSB, so any AT that occurs will not fill the TLB with bad translations. On exit(right before ERET), we need to restore the registers saved on entry, and have the ERET followed by a DSB so that there can be no speculative execution of AT instructions. Thanks Raghu On 7/1/20 5:54 AM, Marc Zyngier via TF-A wrote: > Hi Manish, > > On Wed, 1 Jul 2020 at 13:14, Manish Badarkhe <Manish.Badarkhe(a)arm.com> wrote: >> Hi Andrew, >> >> As per current implementation, in “el1_sysregs_context_restore” routine do below things: >> >> 1. TCR_EL1.EPD0 = 1 >> 2. TCR_EL1.EPD1 = 1 >> 3. SCTR_EL1.M = 0 >> 4. Isb >> Code snippet: >> mrs x9, tcr_el1 >> orr x9, x9, #TCR_EPD0_BIT >> orr x9, x9, #TCR_EPD1_BIT >> msr tcr_el1, x9 >> mrs x9, sctlr_el1 >> bic x9, x9, #SCTLR_M_BIT >> msr sctlr_el1, x9 >> isb >> This is to avoid PTW through while updating system registers at step 5 > Unfortunately, this doesn't prevent anything. > > If SCTLR_EL1.M is clear, TCR_EL1.EPDx don't mean much (S1 MMU is > disabled, no S1 page table walk), and you can still have S2 PTWs > (using an idmap for S1) and creating TLB corruption if these entry > alias with any S1 mapping that exists at EL1. > > Which is why KVM does *set* SCTLR_EL1.M, which prevents the use of a > 1:1 mapping at S1, and at which point the TCR_EL1.EPDx bits are > actually useful in preventing a PTW. > >> 5. Restore all system registers for El1 except SCTLR_EL1 and TCR_EL1 >> 6. isb() >> 7. restore SCTLR_EL1 and TCR_EL1 >> Code Snippet: >> ldr x9, [x0, #CTX_SCTLR_EL1] -> saved value from "el2_sysregs_context_save" >> msr sctlr_el1, x9 >> ldr x9, [x0, #CTX_TCR_EL1] >> msr tcr_el1, x9 >> >> As per above steps. SCTLR_EL1 get restored back with actual settings at step 7. >> Similar flow is present for “el2_sysregs_context_restore” to restore SCTLR_EL1 register. >> >> In conclusion, this routine temporarily clear M bit of SCTLR_EL1 to avoid speculation but restored it back >> to its original setting while leaving back to its caller. Please let us know whether this align with KVM >> workaround for speculative AT erratum. > It doesn't, unfortunately. I believe this code actively creates > problems on a system that is affected by speculative AT execution. > > I don't understand your rationale for touching SCTLR_EL2.M either if > you are not context-switching the EL2 S1 state: as far as I understand > no affected cores have S-EL2, so no switch should happen at this > stage. > > Thanks, > > M.

5 years, 8 months

3
2
0 0

Re: [TF-A] Erroneous speculative AT workaround

by Manish Badarkhe

Hi Andrew, As per current implementation, in “el1_sysregs_context_restore” routine do below things: 1. TCR_EL1.EPD0 = 1 2. TCR_EL1.EPD1 = 1 3. SCTR_EL1.M = 0 4. Isb Code snippet: mrs x9, tcr_el1 orr x9, x9, #TCR_EPD0_BIT orr x9, x9, #TCR_EPD1_BIT msr tcr_el1, x9 mrs x9, sctlr_el1 bic x9, x9, #SCTLR_M_BIT msr sctlr_el1, x9 isb This is to avoid PTW through while updating system registers at step 5 5. Restore all system registers for El1 except SCTLR_EL1 and TCR_EL1 6. isb() 7. restore SCTLR_EL1 and TCR_EL1 Code Snippet: ldr x9, [x0, #CTX_SCTLR_EL1] -> saved value from "el2_sysregs_context_save" msr sctlr_el1, x9 ldr x9, [x0, #CTX_TCR_EL1] msr tcr_el1, x9 As per above steps. SCTLR_EL1 get restored back with actual settings at step 7. Similar flow is present for “el2_sysregs_context_restore” to restore SCTLR_EL1 register. In conclusion, this routine temporarily clear M bit of SCTLR_EL1 to avoid speculation but restored it back to its original setting while leaving back to its caller. Please let us know whether this align with KVM workaround for speculative AT erratum. Thanks Manish Badarkhe On 01/07/2020, 17:02, "TF-A on behalf of Joanna Farley via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Thanks Andrew for the notification. We will look into it and get back to this thread. Thanks Joanna On 01/07/2020, 10:16, "TF-A on behalf of Andrew Scull via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Whilst looking at the speculative AT workaround in KVM, I compared it against the workaround in TF-A and noticed an inconsistency whereby TF-A **breaks** KVM's workaround. In `el1_sysregs_context_restore`, the M bit of SCTRL_EL1 is cleared however Linux requires this to be set for its workaround to be correct. If an exception is taken to EL3 partway through a VM context switch, e.g. a secure interrupt, causing a switch to the secure world, TF-A will reintroduce the possibility of TLB corruption. The above explains how it is broken for Linux's chosen workaround however TF-A will also have to be compatible with whatever workaround the EL2 software is using. Starting this thread with the issue identified and we can add more details as needed. Thanks Andrew -- 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

5 years, 8 months

2
1
0 0

Re: [TF-A] Erroneous speculative AT workaround

by Manish Badarkhe

+Updated comment for SCTLR_EL2 register restoration. On 01/07/2020, 17:45, "TF-A on behalf of Manish Badarkhe via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Andrew, As per current implementation, in “el1_sysregs_context_restore” routine do below things: 1. TCR_EL1.EPD0 = 1 2. TCR_EL1.EPD1 = 1 3. SCTR_EL1.M = 0 4. Isb Code snippet: mrs x9, tcr_el1 orr x9, x9, #TCR_EPD0_BIT orr x9, x9, #TCR_EPD1_BIT msr tcr_el1, x9 mrs x9, sctlr_el1 bic x9, x9, #SCTLR_M_BIT msr sctlr_el1, x9 isb This is to avoid PTW through while updating system registers at step 5 5. Restore all system registers for El1 except SCTLR_EL1 and TCR_EL1 6. isb() 7. restore SCTLR_EL1 and TCR_EL1 Code Snippet: ldr x9, [x0, #CTX_SCTLR_EL1] -> saved value from "el2_sysregs_context_save" msr sctlr_el1, x9 ldr x9, [x0, #CTX_TCR_EL1] msr tcr_el1, x9 As per above steps. SCTLR_EL1 get restored back with actual settings at step 7. Similar flow is present for “el2_sysregs_context_restore” to restore SCTLR_EL2 register. In conclusion, this routine temporarily clear M bit of SCTLR_EL1 to avoid speculation but restored it back to its original setting while leaving back to its caller. Please let us know whether this align with KVM workaround for speculative AT erratum. Thanks Manish Badarkhe On 01/07/2020, 17:02, "TF-A on behalf of Joanna Farley via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Thanks Andrew for the notification. We will look into it and get back to this thread. Thanks Joanna On 01/07/2020, 10:16, "TF-A on behalf of Andrew Scull via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Whilst looking at the speculative AT workaround in KVM, I compared it against the workaround in TF-A and noticed an inconsistency whereby TF-A **breaks** KVM's workaround. In `el1_sysregs_context_restore`, the M bit of SCTRL_EL1 is cleared however Linux requires this to be set for its workaround to be correct. If an exception is taken to EL3 partway through a VM context switch, e.g. a secure interrupt, causing a switch to the secure world, TF-A will reintroduce the possibility of TLB corruption. The above explains how it is broken for Linux's chosen workaround however TF-A will also have to be compatible with whatever workaround the EL2 software is using. Starting this thread with the issue identified and we can add more details as needed. Thanks Andrew -- 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 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 8 months

1
0
0 0

Re: [TF-A] Erroneous speculative AT workaround

by Joanna Farley

Thanks Andrew for the notification. We will look into it and get back to this thread. Thanks Joanna On 01/07/2020, 10:16, "TF-A on behalf of Andrew Scull via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Whilst looking at the speculative AT workaround in KVM, I compared it against the workaround in TF-A and noticed an inconsistency whereby TF-A **breaks** KVM's workaround. In `el1_sysregs_context_restore`, the M bit of SCTRL_EL1 is cleared however Linux requires this to be set for its workaround to be correct. If an exception is taken to EL3 partway through a VM context switch, e.g. a secure interrupt, causing a switch to the secure world, TF-A will reintroduce the possibility of TLB corruption. The above explains how it is broken for Linux's chosen workaround however TF-A will also have to be compatible with whatever workaround the EL2 software is using. Starting this thread with the issue identified and we can add more details as needed. Thanks Andrew -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 8 months

1
0
0 0

Erroneous speculative AT workaround

by Andrew Scull

Whilst looking at the speculative AT workaround in KVM, I compared it against the workaround in TF-A and noticed an inconsistency whereby TF-A **breaks** KVM's workaround. In `el1_sysregs_context_restore`, the M bit of SCTRL_EL1 is cleared however Linux requires this to be set for its workaround to be correct. If an exception is taken to EL3 partway through a VM context switch, e.g. a secure interrupt, causing a switch to the secure world, TF-A will reintroduce the possibility of TLB corruption. The above explains how it is broken for Linux's chosen workaround however TF-A will also have to be compatible with whatever workaround the EL2 software is using. Starting this thread with the issue identified and we can add more details as needed. Thanks Andrew

5 years, 8 months

1
0
0 0

Re: [TF-A] Announcing some changes around the code review label in Gerrit

by Julius Werner

Hi Sandrine, Sounds like good changes in general! I'm curious what the ACLs are for Code-Owner-Review? Is it tied to docs/about/maintainers.rst or just based on the honor system? (I notice that I seem to be able to give a +1 for code I'm not owning, but maybe that's because I am a maintainer?) Also, are code owners allowed to +1 themselves (I think we said we didn't want maintainers to do that, but for code owners I could see how we might want to allow it since there are usually not that many)? What do we do when someone uploads the first patch for a new platform, do they just COR+1 themselves (since there is no code owner yet)? I think it might still be useful to retain the existing Code-Review as a +1/-1 label next to the two new ones, just to allow other interested parties to record their opinion (without it having any enforcing effect on the merge). In other Gerrit instances I have used people often like to give CR+1 as a "I'm not the one who needs to approve this but I have looked at it and think it's fine" or a CR-1 as a "I can't stop you from doing this but I still want to be clear that I don't think it's a good idea". It allows people outside the official approval process a clearer way to participate and can aid the official approvers in their decisions (e.g. when I am reviewing a patch as a maintainer that already has a CR-1 from someone else I know to pay extra attention to their concerns, and it's more visible than just some random comment further up in the list). What do you think? Best regards, Julius

5 years, 8 months

2
1
0 0

Re: [TF-A] Announcing some changes around the code review label in Gerrit

by Javier Almansa Sobrino

Hi Sandrine, If my understanding is right, Code-Owner-Review is the equivalent to the old Code-Review+1 and therefore anyone can add a vote there, owner or not. If that is so, I think the current name might be misleading. Wouldn't it be better just "Code-Review", for instance? As an example, I am not code owner for Measure Boot, but sometimes I am requested to review the patches for it, so in that case it might lead to confusion if I give Code-Owner-Review score. What do you think? Best regards, Javier -----Original Message----- From: Sandrine Bailleux via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:Sandrine%20Bailleux%20via%20TF-A%20%3ctf-a@lists.trustedfirmware.org%3e>> Reply-To: Sandrine Bailleux <sandrine.bailleux(a)arm.com<mailto:Sandrine%20Bailleux%20%3csandrine.bailleux@arm.com%3e>> To: tf-a <tf-a(a)lists.trustedfirmware.org<mailto:tf-a%20%3ctf-a@lists.trustedfirmware.org%3e>> Subject: [TF-A] Announcing some changes around the code review label in Gerrit Date: Tue, 30 Jun 2020 13:29:00 +0000 Hello all, If you recall, the tf.org Project Maintenance Process [1] advocates a code review model where both code owners and maintainers need to review and approve a patch before it gets merged. Until now, the way we would record this in Gerrit was a bit cumbersome and ambiguous. * Code-Review+1 was for code owners to approve a patch. * Code-Review+2 was for maintainers to approve a patch. The submission rules in Gerrit were such that a patch needed a Code-Review+2 to be merged. This meant that if a maintainer was first to take a look at a patch and approved it (Code-Review+2), Gerrit would allow the patch to be merged without any code owners review. To align better with the Project Maintenance Process, I've done some changes in our Gerrit configuration. You will notice that the Code-Review label is gone and has been replaced by 2 new labels: * Code-Owner-Review * Maintainer-Review Stating the obvious but code owners are expected to vote on the Code-Owner-Review label and maintainers on the Maintainer-Review. Note that maintainers might also be code owners for some modules. If they are doing a "code owner" type of review on a patch, they would vote on the Code-Owner-Review label in this case. Any doubt, please ask. I hope I didn't break anything but if you notice any permissions problems (things you used to be able to do and cannot do anymore, or vice versa!) please let me know. One annoying consequence of this change is that if you've got some patches in review right now and got some votes on the former 'Code-Review' label, these have been partially lost. The history of review comments in Gerrit will still show that somebody had voted Code-Review -1/+1 on your patch but this will no longer appear in the labels summary frame and won't count towards the approvals required to get the patch merged. I could not think of a way to avoid this issue... This should only be temporary, while we transition all in-flight patches to the new code review model. Roughly: * Existing "Code-Review -1/+1" votes will have to be replayed as "Code-Owner-Review -1/+1". * Existing "Code-Review -2/+2" votes will have to be replayed as "Maintainer-Review -1/+1". Sorry for the inconvenience. I hope, once we've gone through the transition period, these changes will make the code review process clearer to everybody. I will update the TF-A documentation to explain all of this in the coming future. Best regards, Sandrine [1] https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…

5 years, 8 months

1
0
0 0

New TrustedFirmware.org security incident process is now live

by Dan Handley

Hi all The new TrustedFirmware.org security incident process is now live. This process is described here: https://developer.trustedfirmware.org/w/collaboration/security_center/repor… Initially the process will be used for the following projects: TF-A, TF-M, OP-TEE and Mbed TLS. The security documentation for each project will be updated soon to reflect this change. If you are part of an organization that believes it should receive security vulnerability information before it is made public then please ask your relevant colleagues to register as Trusted Stakeholders as described here: https://developer.trustedfirmware.org/w/collaboration/security_center/trust… Note we prefer individuals in each organization to coordinate their registration requests with each other and to provide us with an email alias managed by your organization instead of us managing a long list of individual addresses. Best regards Dan. (on behalf of the TrustedFirmware.org security team)

5 years, 8 months

1
0
0 0

Announcing some changes around the code review label in Gerrit

by Sandrine Bailleux

Hello all, If you recall, the tf.org Project Maintenance Process [1] advocates a code review model where both code owners and maintainers need to review and approve a patch before it gets merged. Until now, the way we would record this in Gerrit was a bit cumbersome and ambiguous. * Code-Review+1 was for code owners to approve a patch. * Code-Review+2 was for maintainers to approve a patch. The submission rules in Gerrit were such that a patch needed a Code-Review+2 to be merged. This meant that if a maintainer was first to take a look at a patch and approved it (Code-Review+2), Gerrit would allow the patch to be merged without any code owners review. To align better with the Project Maintenance Process, I've done some changes in our Gerrit configuration. You will notice that the Code-Review label is gone and has been replaced by 2 new labels: * Code-Owner-Review * Maintainer-Review Stating the obvious but code owners are expected to vote on the Code-Owner-Review label and maintainers on the Maintainer-Review. Note that maintainers might also be code owners for some modules. If they are doing a "code owner" type of review on a patch, they would vote on the Code-Owner-Review label in this case. Any doubt, please ask. I hope I didn't break anything but if you notice any permissions problems (things you used to be able to do and cannot do anymore, or vice versa!) please let me know. One annoying consequence of this change is that if you've got some patches in review right now and got some votes on the former 'Code-Review' label, these have been partially lost. The history of review comments in Gerrit will still show that somebody had voted Code-Review -1/+1 on your patch but this will no longer appear in the labels summary frame and won't count towards the approvals required to get the patch merged. I could not think of a way to avoid this issue... This should only be temporary, while we transition all in-flight patches to the new code review model. Roughly: * Existing "Code-Review -1/+1" votes will have to be replayed as "Code-Owner-Review -1/+1". * Existing "Code-Review -2/+2" votes will have to be replayed as "Maintainer-Review -1/+1". Sorry for the inconvenience. I hope, once we've gone through the transition period, these changes will make the code review process clearer to everybody. I will update the TF-A documentation to explain all of this in the coming future. Best regards, Sandrine [1] https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…

5 years, 8 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. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 360213: Null pointer dereferences (NULL_RETURNS) /plat/arm/common/arm_dyn_cfg.c: 96 in arm_bl1_set_mbedtls_heap() ________________________________________________________________________________________________________ *** CID 360213: Null pointer dereferences (NULL_RETURNS) /plat/arm/common/arm_dyn_cfg.c: 96 in arm_bl1_set_mbedtls_heap() 90 * In the latter case, if we still wanted to write in the DTB the heap 91 * information, we would need to call plat_get_mbedtls_heap to retrieve 92 * the default heap's address and size. 93 */ 94 95 tb_fw_config_info = FCONF_GET_PROPERTY(dyn_cfg, dtb, TB_FW_CONFIG_ID); >>> CID 360213: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "tb_fw_config_info", which is known to be "NULL". 96 tb_fw_cfg_dtb = tb_fw_config_info->config_addr; 97 98 if ((tb_fw_cfg_dtb != 0UL) && (mbedtls_heap_addr != NULL)) { 99 /* As libfdt use void *, we can't avoid this cast */ 100 void *dtb = (void *)tb_fw_cfg_dtb; 101 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 8 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 2nd July 2020 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 2nd 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: * PSA Fuzz Testing - Presented by Gary Morrison * Originally developed for TF-M PSA API’s this is a different approach to Fuzz testing to that was previously presented in the TF-A SMC Fuzz testing session a few weeks back and provides a testing approach for a the different level of PSA API testing coming to TF-A. * 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

5 years, 8 months

1
0
0 0

Re: [TF-A] How should we manage patches affecting multiple users?

by Joanna Farley

My take on this is perhaps not unexpectantly fairly aligned with Sandrine's. We as a project have over 30 platforms now up-streamed and the expectations is these are managed by the identified platform owners. We look to them to decide on which of any new capabilities offered are supported in their platforms. We have a strategy not to break up-streamed platforms except where we have clearly announced deprecation and this is all documented here https://trustedfirmware-a.readthedocs.io/en/latest/process/platform-compati… and where interfaces have changed and the work is trivial the submitter is expected to attempt to make a good effort to migrate platforms. To support this the current CI system hosted by Arm can only verify the builds of most platforms which is one of the gerrit approvals needed to merge a patch. Of course that does not mean the executables produced will necessarily run correctly which is where platform owners would need to assist with their own approvals and own testing if possible. With the Arm Juno platform and various Arm FVP models we do have the capability to test but that misses out all the other platforms up-streamed. With the OpenCI coming, which we owe a Tech-Forum session on BTW, the Juno and Arm FVP models will also be made available and if platform owners want they will be able to add their platforms to be tested if they want to invest the effort. Sadly migrating to the OpenCI will take time and will have to be delivered in phases but the hope is this will be useful to platform owners as well as for core changes with the visibility of the CI results. The various Arm platforms are generally owned and managed by different teams and go through the same processes as other non Arm platforms on getting patched up-streamed. So when new core features are added for new Arm hardware IP support or new software features that change behaviour as previously we still look to the platform owners to decide if they want support for these in their platforms. For some trivial changes that may be in the form of reviewing changes prepared but for others that may be deciding if they want to invest the effort to implement themselves. For core changes as well as making patches available via Gerrit for review we have been making more use of the TF-A mailing list to announce the patches are available. Indeed we are trying to make use of the mailing list while work is still in design to discuss openly decisions that need to be made which may or may not effect platforms. The Tech-Forum is also being used to present and discuss ideas and ongoing work. This is all being done to be more open about upcoming changes. We would welcome discussions on the mailing list and tech-forum sessions from platform owners about any subjects. This could be around coordinated support across platforms of new capabilities vs each platform following its own path. That of course holds challenges in coordination of effort and who's effort. Hopefully the direction of travel here for the project helps with some of the suggestions but happy to discuss more here on the mailing list of in a tech-forum meeting. Thanks Joanna On 25/06/2020, 03:16, "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, >> As you said, even a small change might break a platform and unfortunately we're not in a position to detect that with the CI yet. I agree that this is a limitation today. If you remember, I have been advocating for announcing on the email alias when in doubt. That way we minimize surprises for the platform owners. >> IMO we cannot reasonably announce all such changes and I would think that contributors are responsible for keeping an eye on patches and testing them if they think they might be affected. I understand. We should announce on the mailing list, when in doubt. I strongly disagree with the second part of the statement though. Asking platform owners to keep an eye on every change defeats the purpose of upstreaming. The burden must lie on the implementer of a change to try and upgrade consumers. >> But I think that the same change might be considered as an improvement by some, and a useless/undesirable change by others. Possible. And then we take call as a community. If it makes sense for some platforms to move ahead, then that should be OK too. >> We might be able to reduce the number of build options in some cases but there will always be a need to retain most of them IMO Thinking out loud - maybe moving to runtime checks makes sense in some cases instead of makefile variables e.g. CPU erratas. We should look at each case individually. I guess, the main problem seems to be low level of testing. So any implementer wont be confident making a change that affects other platforms. That's when sending an email to the community makes sense. We tackle the situation as a team, instead of one person doing all the work. -Varun -----Original Message----- From: Sandrine Bailleux <sandrine.bailleux(a)arm.com> Sent: Wednesday, June 24, 2020 4:54 AM To: Varun Wadekar <vwadekar(a)nvidia.com> Cc: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] How should we manage patches affecting multiple users? External email: Use caution opening links or attachments Hi Varun, Thanks for sharing your opinion. On 6/20/20 1:55 AM, Varun Wadekar wrote: > Hello @Sandrine Bailleux, > > Thanks for starting the email chain. My response to the issues you flagged in the email below. > > 1. This seems to be a bit tricky. As a consumer of an API, one would expect that it works as advertised. If the behavior changes, thus affecting the expectations or assumptions surrounding the API, then they should be announced. With so many platforms in the tree, we should always assume that even a small change will break a platform. I agree. Whenever there is clear intention to change the expectations or assumptions of an API, this should be announced and discussed. However, there are cases where we might want to rework the implementation of an API (to clean the code for example), make some improvements or extend its functionality. All of that might be done with no intent to step outside of the API original scope but still subtly break some code. As you said, even a small change might break a platform and unfortunately we're not in a position to detect that with the CI yet. IMO we cannot reasonably announce all such changes and I would think that contributors are responsible for keeping an eye on patches and testing them if they think they might be affected. > 2. For improvements, we should strive to upgrade all consumers of the API/makefile/features. This will ensure that all platforms remain current and we reduce maintenance cost in the long run. I assume, that such improvements will give birth to additional configs/makefile settings/platform variables etc. We would be signing up for a lot of maintenance by allowing some platforms to lag. > > For straight forward changes (e.g. the change under discussion) I assume that the platforms will respond and we would get the changes merged relatively fast. For controversial features, this will spark a healthy discussion in the community. I agree with you in principle. But I think that the same change might be considered as an improvement by some, and a useless/undesirable change by others. For example, the change under discussion is an improvement from our point of view. It will lower the maintenance cost, as any new file added in the GIC driver in the future will be automatically pulled in by platforms that use the newly introduced GIC makefile, without the need to update all platforms makefiles. But this might not be what everyone wants, some platform owners might prefer continue cherry-picking specific GIC source files to retain control over what they include in their firmware. In this case, is it the right thing to do to "upgrade" them? I think this is debatable. Maybe a better alternative is to simply make people aware of the change, provide a link to how the migration was done for Arm platforms in this case, so that they've got an example to guide them if they wish to embrace the change for their own platform ports. > 3. For a case where the change breaks platforms, it makes sense to just upgrade all of them. > >>> Now the question we were pondering in Gerrit is, where does the responsibility of migrating all platforms/users lie for all these types of changes? Is the patch author responsible to do all the work? > > [VW] IMO, the author of such a patch is the best person to upgrade all affected platforms/users. The main reason being that he/she is already an expert for the patch. Agree that the patch author is an expert for his own patch but that does not mean he's also an expert on how his patch should be applied for another platform port he's not familiar with. > But, this might not be true in some cases where the author will need help from the community. For such cases, we should ask for help on the mailing list. Yes, I think such cases require collaboration indeed. > I also want to highlight the dangers of introducing make variables as a solution. The current situation is already unmanageable with so many build variables and weak handlers. We should try and avoid adding more. Not sure how this ties with the original discussions but I agree with you, we've got far too many build options in this project. This makes testing a lot harder, as it means we have hundreds of valid combinations of build options to verify. It also makes the code harder to read and understand because it is sprinkled with #ifdefs. Hopefully, switching to a KConfig-like configuration system in the future will help alleviate this issue, as at least it will allow us to express the valid combinations of build options in a more robust manner (today the build system tries to forbid invalid combinations but I am sure it's far from exhaustive in these types of checks) and also visualize what's been enabled/disabled more easily for a specific build. Even though I acknowledge this problem, I am not sure we can completely solve it. Firmware is not general-purpose software and it requires a lot more control over the features you include or not because of stricter memory and CPU constraints. I think people need a way to turn on/off features at a fine granularity. We might be able to reduce the number of build options in some cases but there will always be a need to retain most of them IMO. > Finally, I agree that there's no silver bullet and we have to deal with each situation differently. Communication is key, as you rightly said. As long we involve the community, we should be OK. > > -Varun > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > Sandrine Bailleux via TF-A > Sent: Friday, June 19, 2020 2:57 AM > To: tf-a <tf-a(a)lists.trustedfirmware.org> > Subject: [TF-A] How should we manage patches affecting multiple users? > > External email: Use caution opening links or attachments > > > Hello everyone, > > I would like to start a discussion around the way we want to handle changes that affect all platforms/users. This subject came up in this code review [1]. > > I'll present my views on the subject and would like to know what others think. > > First of all, what do we mean by "changes that affect all platforms"? It would be any change that is not self-contained within a platform port. > IOW, a change in some file outside of the plat/ directory. It could be in a driver, in a library, in the build system, in the platform interfaces called by the generic code... the list goes on. > > 1. Some are just implementation changes, they leave the interfaces unchanged. These do not break other platforms builds since the call sites don't need to be updated. However, they potentially change the responsibilities of the interface, in which case this might introduce behavioral changes that all users of the interface need to be aware of and adapt their code to. > > 2. Some other changes might introduce optional improvements. They introduce a new way of doing things, perhaps a cleaner or more efficient one. Users can safely stay with the old way of doing things without fear of breakage but they would benefit from migrating. > > This is the case of Alexei's patch [1], which introduces an > intermediate > GICv2 makefile, that Arm platforms now include instead of pulling each individual file by themselves. At this point, it is just an improvement that introduces an indirection level in the build system. This is an improvement in terms of maintainability because if we add a new essential file to this driver in the future, we'll just need to add it in this new GICv2 makefile without having to update all platforms makefiles. However, platform makefiles can continue to pull in individual files if they wish to. > > 3. Some other changes might break backwards compatibility. This is something we should avoid as much as possible and we should always strive to provide a migration path. But there are cases where there might be no other way than to break things. In this case, all users have to be migrated. > > > Now the question we were pondering in Gerrit is, where does the responsibility of migrating all platforms/users lie for all these types of changes? Is the patch author responsible to do all the work? > > I think it's hard to come up with a one-size-fits-all answer. It really depends on the nature of changes, their consequences, the amount of work needed to do the migration, the ability for the patch author to test these changes, to name a few. > > I believe the patch author should migrate all users on a best-effort basis. If it's manageable then they should do the work and propose a patch to all affected users for them to review and test on their platforms. > > On the other hand, if it's too much work or impractical, then I think the best approach would be for the patch author to announce and discuss the changes on this mailing list. In some scenarios, the changes might be controversial and not all platform owners might agree that the patch brings enough benefit compared to the migration effort, in which case the changes might have to be withdrawn or re-thought. In any case, I believe communication is key here and no one should take any unilateral decision on their own if it affects other users. > > I realize this is a vast subject and that we probably won't come up with an answer/reach an agreement on all the aspects of the question. But I'd be interested in hearing other contributors' view and if they've got any experience managing these kinds of issues, perhaps in other open source project. > > Best regards, > Sandrine > > [1] > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4538 > -- > 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

5 years, 8 months

1
0
0 0

Re: [TF-A] Question on authenticating FIP images

by Sandrine Bailleux

Hi, On 6/25/20 3:24 AM, Raghu K via TF-A wrote: > One option you can look at is in bl1_fwu.c if you already haven't, in > bl1_fwu_image_auth() function, that uses the auth_mod_verify_img, which > is provided an image id, address and size. You can repeatedly call this > function on the different image ID's that you have in your FIP. You will > likely need to calculate the address to pass to this function based on > reading the FIP header(maybe you can use the IO framework for this by > opening different image ID's). > Don't think there is a straight forward way but what you are trying to > do should be achievable using existing code, rearranged to fit your needs. Yes, Raghu's approach sounds right to me. As he pointed out, this is not something that's supported out of the box because the firmware update feature is normally invoked through an SMC into BL1 as part of the firmware update flow early during the boot. Things are different in your case as you're looking to provide this feature much later as a runtime service so this will surely require some amount of tweaking but sounds feasible to me. Best regards, Sandrine > > Thanks > Raghu > > On 6/24/20 12:42 PM, arm in-cloud via TF-A wrote: >> Hi Sandrine, >> >> Waiting for your suggestions on this query. >> >> Thanks >> >> On Mon, Jun 22, 2020 at 3:40 PM arm in-cloud via TF-A >> <tf-a(a)lists.trustedfirmware.org >> <mailto:tf-a@lists.trustedfirmware.org>> wrote: >> >> <Posting the question to tf-a mailing list from Maniphest and >> copied all previous conversation> >> >> Hi, >> >> On our boards I have an external security chip which communicates >> with AP (application processor) over a encrypted communication >> channel. I have a communication driver/PTA running in a Secure >> Playload (OPTEE) running in S-EL1. My firmware update workflow >> (FIP.BIN) is as below. >> >> In our design, we have QSPI from where AP boots up (regular TF-A >> workflow) this QSPI is also accessible from external Security chip >> (which is responsible for AP/SOC's firmware update) >> On software side, I have a Non-Secure application which receives >> the prebuilt binary (FIP.BIN) it chopps the binary in fixed sized >> buffers and send to OPTEE-PTA which internally sends the binary to >> Security chip (which then validates and writes to QSPI). >> >> Now in this firmware update flow, I want to do following things. >> >> 1. I want to validate/authenticate the FIP image before sending >> to security chip. If it authentication is successful only then >> send the image to security chip. >> >> This is what I am planning:- >> >> 1. Receive the whole FIP.BIN from NS-APP and store it in RAM (in >> OPTEE's RAM) >> 2. I am planning to implement a SIP service in TF-A which will >> receive the address and size of FIP.BIN in RAM. >> 3. Calls in to auth_mod driver for authentication of the image. >> >> I don't want to update the images immediately I just needs to >> authenticate the images within FIP.BIN >> >> To design this feature, I started looking in to BL1 & BL2 code but >> not sure how much piece if code I can reuse or use. >> Also I looked in to fwu test apps if I can mimic something but >> looks the fwu implementation is absolutely different. >> >> My question is how do I just use the authentication functionality >> available in TF-A for my purpose. >> >> Appreciate your help! >> >> >> >> >> sandrine-bailleux-arm >> <https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/> added >> a subscriber: sandrine-bailleux-arm >> <https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/>.Tue, >> Jun 16, 6:50 AM <https://developer.trustedfirmware.org/T763#9015> >> >> <https://developer.trustedfirmware.org/T763#> >> >> Hi, >> >> Apologies for the delay, I had missed this ticket... Generally >> speaking, it's better to post questions on the TF-A mailing list >> [1], it's got far better visibility than Maniphest (which few >> people monitor I believe) and you are more likely to get a quick >> answer there. >> >> First of all, I've got a few questions that would help me >> understand your design. >> >> 1. You say that OPTEE-PTA would store the FIP image in its RAM. I >> am assuming this is secure RAM, that only secure software can >> access, right? If not, this would not seem very secure to me, >> as the normal world software could easily change the FIP image >> after it has been authenticated and replace it with some >> malicious firmware. >> >> 2. You'd like to implement a SiP service in TF-A to authenticate >> the FIP image, given its base address and size. Now I am >> guessing this would be an address in OPTEE's RAM, right? >> >> 3. What cryptographic key would sign the FIP image? Would TF-A >> have access to this key to authenticate it? >> >> 4. What would need authentication? The FIP image as a monolithic >> blob, or each individual image within this FIP? And in the >> latter case, would all images be authenticated using the same >> key or would different images be signed with different keys? >> >> Now, coming back to where to look into TF-A source code. You're >> looking in the right place, all Trusted Boot code is indeed built >> into BL1 and BL2 in TF-A. The following two documents detail how >> the authentication framework and firmware update flow work in TF-A >> and are worth reading if you haven't done so already: >> >> https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.ht… >> https://trustedfirmware-a.readthedocs.io/en/latest/components/firmware-upda… >> >> I reckon you'd want to reuse the cryptographic module in your >> case. It provides a callback to verify the signature of some >> payload, see [2] and include/drivers/auth/crypto_mod.h. However, I >> expect it won't be straight forward to reuse this code outside of >> its context, as it expects DER-encoded data structures following a >> specific ASN.1 format. Typically when used in the TF-A trusted >> boot flow, these are coming from X.509 certificates, which already >> provide the data structures in the right format. >> >> Best regards, >> Sandrine Bailleux >> >> [1] https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> [2] https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.ht… >> >> >> arm-in-cloud >> <https://developer.trustedfirmware.org/p/arm-in-cloud/> added a >> comment.Edited · Wed, Jun 17, 11:42 AM >> <https://developer.trustedfirmware.org/T763#9018> >> >> <https://developer.trustedfirmware.org/T763#> >> >> Thank you Sandrine for your feedback. >> >> Following are the answers to your questions: >> >> 1. Yes, the image will be stored in to OPTEEs secured memory. I >> am guessing TF-A gets access to this memory. >> 2. Yes, the OPTEE's secure memory address and Size will be passed >> to the SiP service running in TF-A. >> 3. These are RSA keys, in my case only TF-A has access to these >> keys. On a regular boot these are the same keys used to >> authenticate the images (BL31, BL32 & BL33) in the FIP stored >> in the QSPI. >> 4. Yes all images will be authenticated using same key. >> >> Thanks for the documentation links, from the firmware-update doc. >> I am mainly trying to use IMAGE_AUTH part. In my case COPY is >> already done just needs AUTH part and once AUTH is successful, >> optee will pass that payload the security chip for update. And >> after rebooting my device will boot with new firmware. (In my case >> we always reboot after firmware updates). >> >> Do you want me to post this query again on the TF-A mailing list? >> >> Thank you! >> >> >> >> sandrine-bailleux-arm >> <https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/> added >> a comment.Fri, Jun 19, 3:09 AM >> <https://developer.trustedfirmware.org/T763#9032> >> >> <https://developer.trustedfirmware.org/T763#> >> >> Hi, >> >> OK I understand a bit better, thanks for the details. >> >> Do you want me to post this query again on the TF-A mailing list? >> >> If it's not too much hassle for you then yes, I think it'd be >> preferable to continue the discussion on the TF-A mailing list. I >> will withhold my comments until then. >> >> >> >> -- >> TF-A mailing list >> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> >> > >

5 years, 8 months

2
1
0 0

Re: [TF-A] Unit Test tech forum follow-up

by Varun Wadekar

Hello Lauren, Thanks for answering the open items from the tech forum. Just curious, do you know if CppUTest can also consider a set of C files as a unit instead of a single function? This is the policy we have adopted internally, but with an automated tool to generate the unit tests. Cheers, Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Lauren Wehrmeister via TF-A Sent: Thursday, June 25, 2020 10:52 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Unit Test tech forum follow-up External email: Use caution opening links or attachments Following up about some questions from my presentation at the tech forum on the TF-A unit testing framework. In regards to the other tool that was investigated alongside CppUTest, it was Google Test<https://github.com/google/googletest>. The main reason for choosing CppUTest was that it is easily portable to new platforms and has a small footprint despite its feature set. This could be very useful if we want to use it on hardware (not on the host machine) in the future, even if it only has a small amount of memory. Google test is very good for testing user space applications, but most of its features require pthread, file system, and other services of the operating system which we usually don't have in an embedded environment. So we chose CppUTest because it fits for both host and target based testing so we won't end up using different frameworks in the same project. Something to note is that CppUTest has an option<https://cpputest.github.io/manual.html#gtest> for running Google Test based test cases too, but the intention is to keep the framework clean by using only CppUTest. Also c-picker can support parsing large data structures since the tool uses PyYAML for parsing the config files and clang for processing the source files. Thanks, Lauren

5 years, 8 months

2
1
0 0

Unit Test tech forum follow-up

by Lauren Wehrmeister

Following up about some questions from my presentation at the tech forum on the TF-A unit testing framework. In regards to the other tool that was investigated alongside CppUTest, it was Google Test<https://github.com/google/googletest>. The main reason for choosing CppUTest was that it is easily portable to new platforms and has a small footprint despite its feature set. This could be very useful if we want to use it on hardware (not on the host machine) in the future, even if it only has a small amount of memory. Google test is very good for testing user space applications, but most of its features require pthread, file system, and other services of the operating system which we usually don't have in an embedded environment. So we chose CppUTest because it fits for both host and target based testing so we won't end up using different frameworks in the same project. Something to note is that CppUTest has an option<https://cpputest.github.io/manual.html#gtest> for running Google Test based test cases too, but the intention is to keep the framework clean by using only CppUTest. Also c-picker can support parsing large data structures since the tool uses PyYAML for parsing the config files and clang for processing the source files. Thanks, Lauren

5 years, 8 months

1
0
0 0

Re: [TF-A] How should we manage patches affecting multiple users?

by Varun Wadekar

Hello @Sandrine Bailleux, Thanks for starting the email chain. My response to the issues you flagged in the email below. 1. This seems to be a bit tricky. As a consumer of an API, one would expect that it works as advertised. If the behavior changes, thus affecting the expectations or assumptions surrounding the API, then they should be announced. With so many platforms in the tree, we should always assume that even a small change will break a platform. 2. For improvements, we should strive to upgrade all consumers of the API/makefile/features. This will ensure that all platforms remain current and we reduce maintenance cost in the long run. I assume, that such improvements will give birth to additional configs/makefile settings/platform variables etc. We would be signing up for a lot of maintenance by allowing some platforms to lag. For straight forward changes (e.g. the change under discussion) I assume that the platforms will respond and we would get the changes merged relatively fast. For controversial features, this will spark a healthy discussion in the community. 3. For a case where the change breaks platforms, it makes sense to just upgrade all of them. >> Now the question we were pondering in Gerrit is, where does the responsibility of migrating all platforms/users lie for all these types of changes? Is the patch author responsible to do all the work? [VW] IMO, the author of such a patch is the best person to upgrade all affected platforms/users. The main reason being that he/she is already an expert for the patch. But, this might not be true in some cases where the author will need help from the community. For such cases, we should ask for help on the mailing list. I also want to highlight the dangers of introducing make variables as a solution. The current situation is already unmanageable with so many build variables and weak handlers. We should try and avoid adding more. Finally, I agree that there's no silver bullet and we have to deal with each situation differently. Communication is key, as you rightly said. As long we involve the community, we should be OK. -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandrine Bailleux via TF-A Sent: Friday, June 19, 2020 2:57 AM To: tf-a <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] How should we manage patches affecting multiple users? External email: Use caution opening links or attachments Hello everyone, I would like to start a discussion around the way we want to handle changes that affect all platforms/users. This subject came up in this code review [1]. I'll present my views on the subject and would like to know what others think. First of all, what do we mean by "changes that affect all platforms"? It would be any change that is not self-contained within a platform port. IOW, a change in some file outside of the plat/ directory. It could be in a driver, in a library, in the build system, in the platform interfaces called by the generic code... the list goes on. 1. Some are just implementation changes, they leave the interfaces unchanged. These do not break other platforms builds since the call sites don't need to be updated. However, they potentially change the responsibilities of the interface, in which case this might introduce behavioral changes that all users of the interface need to be aware of and adapt their code to. 2. Some other changes might introduce optional improvements. They introduce a new way of doing things, perhaps a cleaner or more efficient one. Users can safely stay with the old way of doing things without fear of breakage but they would benefit from migrating. This is the case of Alexei's patch [1], which introduces an intermediate GICv2 makefile, that Arm platforms now include instead of pulling each individual file by themselves. At this point, it is just an improvement that introduces an indirection level in the build system. This is an improvement in terms of maintainability because if we add a new essential file to this driver in the future, we'll just need to add it in this new GICv2 makefile without having to update all platforms makefiles. However, platform makefiles can continue to pull in individual files if they wish to. 3. Some other changes might break backwards compatibility. This is something we should avoid as much as possible and we should always strive to provide a migration path. But there are cases where there might be no other way than to break things. In this case, all users have to be migrated. Now the question we were pondering in Gerrit is, where does the responsibility of migrating all platforms/users lie for all these types of changes? Is the patch author responsible to do all the work? I think it's hard to come up with a one-size-fits-all answer. It really depends on the nature of changes, their consequences, the amount of work needed to do the migration, the ability for the patch author to test these changes, to name a few. I believe the patch author should migrate all users on a best-effort basis. If it's manageable then they should do the work and propose a patch to all affected users for them to review and test on their platforms. On the other hand, if it's too much work or impractical, then I think the best approach would be for the patch author to announce and discuss the changes on this mailing list. In some scenarios, the changes might be controversial and not all platform owners might agree that the patch brings enough benefit compared to the migration effort, in which case the changes might have to be withdrawn or re-thought. In any case, I believe communication is key here and no one should take any unilateral decision on their own if it affects other users. I realize this is a vast subject and that we probably won't come up with an answer/reach an agreement on all the aspects of the question. But I'd be interested in hearing other contributors' view and if they've got any experience managing these kinds of issues, perhaps in other open source project. Best regards, Sandrine [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4538 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 8 months

2
2
0 0

Re: [TF-A] Question on authenticating FIP images

by Raghu K

5 years, 8 months

1
0
0 0

Re: [TF-A] Question on authenticating FIP images

by arm in-cloud

Hi Sandrine, Waiting for your suggestions on this query. Thanks On Mon, Jun 22, 2020 at 3:40 PM arm in-cloud via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > <Posting the question to tf-a mailing list from Maniphest and copied all > previous conversation> > > Hi, > > On our boards I have an external security chip which communicates with AP > (application processor) over a encrypted communication channel. I have a > communication driver/PTA running in a Secure Playload (OPTEE) running in > S-EL1. My firmware update workflow (FIP.BIN) is as below. > > In our design, we have QSPI from where AP boots up (regular TF-A workflow) > this QSPI is also accessible from external Security chip (which is > responsible for AP/SOC's firmware update) > On software side, I have a Non-Secure application which receives the > prebuilt binary (FIP.BIN) it chopps the binary in fixed sized buffers and > send to OPTEE-PTA which internally sends the binary to Security chip (which > then validates and writes to QSPI). > > Now in this firmware update flow, I want to do following things. > > 1. I want to validate/authenticate the FIP image before sending to > security chip. If it authentication is successful only then send the image > to security chip. > > This is what I am planning:- > > 1. Receive the whole FIP.BIN from NS-APP and store it in RAM (in > OPTEE's RAM) > 2. I am planning to implement a SIP service in TF-A which will receive > the address and size of FIP.BIN in RAM. > 3. Calls in to auth_mod driver for authentication of the image. > > I don't want to update the images immediately I just needs to authenticate > the images within FIP.BIN > > To design this feature, I started looking in to BL1 & BL2 code but not > sure how much piece if code I can reuse or use. > Also I looked in to fwu test apps if I can mimic something but looks the > fwu implementation is absolutely different. > > My question is how do I just use the authentication functionality > available in TF-A for my purpose. > > Appreciate your help! > > > > > sandrine-bailleux-arm > <https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/> added a > subscriber: sandrine-bailleux-arm > <https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/>.Tue, Jun > 16, 6:50 AM <https://developer.trustedfirmware.org/T763#9015> > > <https://developer.trustedfirmware.org/T763#> > > Hi, > > Apologies for the delay, I had missed this ticket... Generally speaking, > it's better to post questions on the TF-A mailing list [1], it's got far > better visibility than Maniphest (which few people monitor I believe) and > you are more likely to get a quick answer there. > > First of all, I've got a few questions that would help me understand your > design. > > 1. You say that OPTEE-PTA would store the FIP image in its RAM. I am > assuming this is secure RAM, that only secure software can access, right? > If not, this would not seem very secure to me, as the normal world software > could easily change the FIP image after it has been authenticated and > replace it with some malicious firmware. > > > 1. You'd like to implement a SiP service in TF-A to authenticate the > FIP image, given its base address and size. Now I am guessing this would be > an address in OPTEE's RAM, right? > > > 1. What cryptographic key would sign the FIP image? Would TF-A have > access to this key to authenticate it? > > > 1. What would need authentication? The FIP image as a monolithic blob, > or each individual image within this FIP? And in the latter case, would all > images be authenticated using the same key or would different images be > signed with different keys? > > Now, coming back to where to look into TF-A source code. You're looking in > the right place, all Trusted Boot code is indeed built into BL1 and BL2 in > TF-A. The following two documents detail how the authentication framework > and firmware update flow work in TF-A and are worth reading if you haven't > done so already: > > > https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.ht… > > https://trustedfirmware-a.readthedocs.io/en/latest/components/firmware-upda… > > I reckon you'd want to reuse the cryptographic module in your case. It > provides a callback to verify the signature of some payload, see [2] and > include/drivers/auth/crypto_mod.h. However, I expect it won't be straight > forward to reuse this code outside of its context, as it expects > DER-encoded data structures following a specific ASN.1 format. Typically > when used in the TF-A trusted boot flow, these are coming from X.509 > certificates, which already provide the data structures in the right format. > > Best regards, > Sandrine Bailleux > > [1] https://lists.trustedfirmware.org/mailman/listinfo/tf-a > [2] > https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.ht… > > > arm-in-cloud <https://developer.trustedfirmware.org/p/arm-in-cloud/> added > a comment.Edited · Wed, Jun 17, 11:42 AM > <https://developer.trustedfirmware.org/T763#9018> > > <https://developer.trustedfirmware.org/T763#> > > Thank you Sandrine for your feedback. > > Following are the answers to your questions: > > 1. Yes, the image will be stored in to OPTEEs secured memory. I am > guessing TF-A gets access to this memory. > 2. Yes, the OPTEE's secure memory address and Size will be passed to > the SiP service running in TF-A. > 3. These are RSA keys, in my case only TF-A has access to these keys. > On a regular boot these are the same keys used to authenticate the images > (BL31, BL32 & BL33) in the FIP stored in the QSPI. > 4. Yes all images will be authenticated using same key. > > Thanks for the documentation links, from the firmware-update doc. I am > mainly trying to use IMAGE_AUTH part. In my case COPY is already done just > needs AUTH part and once AUTH is successful, optee will pass that payload > the security chip for update. And after rebooting my device will boot with > new firmware. (In my case we always reboot after firmware updates). > > Do you want me to post this query again on the TF-A mailing list? > > Thank you! > > > > sandrine-bailleux-arm > <https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/> added a > comment.Fri, Jun 19, 3:09 AM > <https://developer.trustedfirmware.org/T763#9032> > > <https://developer.trustedfirmware.org/T763#> > > Hi, > > OK I understand a bit better, thanks for the details. > > Do you want me to post this query again on the TF-A mailing list? > > If it's not too much hassle for you then yes, I think it'd be preferable > to continue the discussion on the TF-A mailing list. I will withhold my > comments until then. > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

5 years, 8 months

1
0
0 0

Re: [TF-A] Unhandled Exception at EL3 in BL31 for Neoverse N1 with direct connect of DSU

by Witkowski, Andrzej

Sorry for a delay. I didn't have a bandwidth for doing it. I asked my teammate Marcin Salnik for testing the fix https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3493 on our Veloce emulator. Now, I can confirm that this fix works. ACC BL31 booted. From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: Monday, June 01, 2020 8:57 PM To: Witkowski, Andrzej <andrzej.witkowski(a)intel.com> Cc: Lessnau, Adam <adam.lessnau(a)intel.com>; tf-a(a)lists.trustedfirmware.org Subject: RE: Unhandled Exception at EL3 in BL31 for Neoverse N1 with direct connect of DSU Hi, I believe the fix for this issue is part of https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3493. Can you please try that change? -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Witkowski, Andrzej via TF-A Sent: Monday, June 1, 2020 7:08 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Cc: Witkowski, Andrzej <andrzej.witkowski(a)intel.com<mailto:andrzej.witkowski@intel.com>>; Lessnau, Adam <adam.lessnau(a)intel.com<mailto:adam.lessnau@intel.com>> Subject: [TF-A] Unhandled Exception at EL3 in BL31 for Neoverse N1 with direct connect of DSU External email: Use caution opening links or attachments Hi, I work on project which uses ARM CPU Neoverse N1 with direct connect of DSU. I noticed the following error "Unhandled Exception at EL3" in BL31 bootloader after switching from ATF 2.1 to 2.2. The root cause is that after invoking neoverse_n1_errata-report function in lib/cpus/aarch64/neoverse_n1.S file and reaching the line 525, the function check_errata_dsu_934 in lib/cpus/aarch64/dsu_helpers.S file is always invoked regardless of whether ERRATA_DSU_936184 is set to 0 or to 1. In our case, ERRATA_DSU_936184 := 0. [cid:image001.png@01D64A40.BBEF1AA0] [cid:image002.png@01D64A40.BBEF1AA0] Neoverse N1 with direct connect version of DSU doesn't contain SCU/L3 cache and CLUSTERCFR_EL1 register. The error "Unhandled Exception at EL3" appears in BL31 bootloader during attempt to read the CLUSTERCFR_EL1 register which doesn't exist in our RTL HW. Andrzej Witkowskie Intel Technology Poland --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN. Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited. --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Sowackiego 173 | 80-298 Gdask | Sd Rejonowy Gdask Pnoc | VII Wydzia Gospodarczy Krajowego Rejestru Sdowego - KRS 101882 | NIP 957-07-52-316 | Kapita zakadowy 200.000 PLN. Ta wiadomo wraz z zacznikami jest przeznaczona dla okrelonego adresata i moe zawiera informacje poufne. W razie przypadkowego otrzymania tej wiadomoci, prosimy o powiadomienie nadawcy oraz trwae jej usunicie; jakiekolwiek przegldanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.

5 years, 8 months

1
0
0 0

Question on authenticating FIP images

by arm in-cloud

<Posting the question to tf-a mailing list from Maniphest and copied all previous conversation> Hi, On our boards I have an external security chip which communicates with AP (application processor) over a encrypted communication channel. I have a communication driver/PTA running in a Secure Playload (OPTEE) running in S-EL1. My firmware update workflow (FIP.BIN) is as below. In our design, we have QSPI from where AP boots up (regular TF-A workflow) this QSPI is also accessible from external Security chip (which is responsible for AP/SOC's firmware update) On software side, I have a Non-Secure application which receives the prebuilt binary (FIP.BIN) it chopps the binary in fixed sized buffers and send to OPTEE-PTA which internally sends the binary to Security chip (which then validates and writes to QSPI). Now in this firmware update flow, I want to do following things. 1. I want to validate/authenticate the FIP image before sending to security chip. If it authentication is successful only then send the image to security chip. This is what I am planning:- 1. Receive the whole FIP.BIN from NS-APP and store it in RAM (in OPTEE's RAM) 2. I am planning to implement a SIP service in TF-A which will receive the address and size of FIP.BIN in RAM. 3. Calls in to auth_mod driver for authentication of the image. I don't want to update the images immediately I just needs to authenticate the images within FIP.BIN To design this feature, I started looking in to BL1 & BL2 code but not sure how much piece if code I can reuse or use. Also I looked in to fwu test apps if I can mimic something but looks the fwu implementation is absolutely different. My question is how do I just use the authentication functionality available in TF-A for my purpose. Appreciate your help! sandrine-bailleux-arm <https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/> added a subscriber: sandrine-bailleux-arm <https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/>.Tue, Jun 16, 6:50 AM <https://developer.trustedfirmware.org/T763#9015> <https://developer.trustedfirmware.org/T763#> Hi, Apologies for the delay, I had missed this ticket... Generally speaking, it's better to post questions on the TF-A mailing list [1], it's got far better visibility than Maniphest (which few people monitor I believe) and you are more likely to get a quick answer there. First of all, I've got a few questions that would help me understand your design. 1. You say that OPTEE-PTA would store the FIP image in its RAM. I am assuming this is secure RAM, that only secure software can access, right? If not, this would not seem very secure to me, as the normal world software could easily change the FIP image after it has been authenticated and replace it with some malicious firmware. 1. You'd like to implement a SiP service in TF-A to authenticate the FIP image, given its base address and size. Now I am guessing this would be an address in OPTEE's RAM, right? 1. What cryptographic key would sign the FIP image? Would TF-A have access to this key to authenticate it? 1. What would need authentication? The FIP image as a monolithic blob, or each individual image within this FIP? And in the latter case, would all images be authenticated using the same key or would different images be signed with different keys? Now, coming back to where to look into TF-A source code. You're looking in the right place, all Trusted Boot code is indeed built into BL1 and BL2 in TF-A. The following two documents detail how the authentication framework and firmware update flow work in TF-A and are worth reading if you haven't done so already: https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.ht… https://trustedfirmware-a.readthedocs.io/en/latest/components/firmware-upda… I reckon you'd want to reuse the cryptographic module in your case. It provides a callback to verify the signature of some payload, see [2] and include/drivers/auth/crypto_mod.h. However, I expect it won't be straight forward to reuse this code outside of its context, as it expects DER-encoded data structures following a specific ASN.1 format. Typically when used in the TF-A trusted boot flow, these are coming from X.509 certificates, which already provide the data structures in the right format. Best regards, Sandrine Bailleux [1] https://lists.trustedfirmware.org/mailman/listinfo/tf-a [2] https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.ht… arm-in-cloud <https://developer.trustedfirmware.org/p/arm-in-cloud/> added a comment.Edited · Wed, Jun 17, 11:42 AM <https://developer.trustedfirmware.org/T763#9018> <https://developer.trustedfirmware.org/T763#> Thank you Sandrine for your feedback. Following are the answers to your questions: 1. Yes, the image will be stored in to OPTEEs secured memory. I am guessing TF-A gets access to this memory. 2. Yes, the OPTEE's secure memory address and Size will be passed to the SiP service running in TF-A. 3. These are RSA keys, in my case only TF-A has access to these keys. On a regular boot these are the same keys used to authenticate the images (BL31, BL32 & BL33) in the FIP stored in the QSPI. 4. Yes all images will be authenticated using same key. Thanks for the documentation links, from the firmware-update doc. I am mainly trying to use IMAGE_AUTH part. In my case COPY is already done just needs AUTH part and once AUTH is successful, optee will pass that payload the security chip for update. And after rebooting my device will boot with new firmware. (In my case we always reboot after firmware updates). Do you want me to post this query again on the TF-A mailing list? Thank you! sandrine-bailleux-arm <https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/> added a comment.Fri, Jun 19, 3:09 AM <https://developer.trustedfirmware.org/T763#9032> <https://developer.trustedfirmware.org/T763#> Hi, OK I understand a bit better, thanks for the details. Do you want me to post this query again on the TF-A mailing list? If it's not too much hassle for you then yes, I think it'd be preferable to continue the discussion on the TF-A mailing list. I will withhold my comments until then.

5 years, 8 months

1
0
0 0

Re: [TF-A] GICV3: system interface EOI ordering RFC

by Sandeep Tripathy

Hi Raghu, > -----Original Message----- > From: TF-A [mailto:tf-a-bounces@lists.trustedfirmware.org] On Behalf Of > Raghu Krishnamurthy via TF-A > Sent: Monday, June 08, 2020 7:09 PM > To: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC > > Hello, > > Sorry for chiming in late. Are we sure that the msr/mrs to the GICv3 EOI > register is not a context synchronizing event or ensures ordering itself > ? Also did the addition of DSB() fix the issue ? If yes, can you try > adding a delay or a few NOP's/dummy instructions or an ISB to see if the > issue goes away? Yes these experiments were done to observe the behavior which led to this change. A definitive confirmation of how core treats these accesses can be only be from arm core team or by actually probing the transfers. I had a response from arm support on the very same question which reads as follows: "In theory, the memory barrier should be placed between the clearing of the peripheral and the access to the EOI register". In a slightly unrelated case I had observed this with NVIC on axi probe and there is no feasibility to repeat this with GICv3 at the moment. > > We need to know the right thing to do architecturally and confirm that > the issue is really due to reordering at the core before adding the DSB. > Adding a DSB might be masking a timing issue. Is the above response and what Soby had confirmed sufficient ? or could someone from arm get this reconfirmed from core design unless it is obvious to them ? And this is equally applicable to linux as well. > > -Raghu > Thanks Sandeep > > > On 6/8/20 4:47 AM, Sandeep Tripathy via TF-A wrote: > >> -----Original Message----- > >> From: Soby Mathew [mailto:Soby.Mathew@arm.com] > >> Sent: Monday, June 08, 2020 3:36 PM > >> To: Sandeep Tripathy; Olivier Deprez; tf-a(a)lists.trustedfirmware.org > >> Cc: nd > >> Subject: RE: [TF-A] GICV3: system interface EOI ordering RFC > >> > >> Just some inputs from my side: > >> I agree we need at least a dsb() after the write to MMIO region to > >> silence > >> the > >> peripheral and before the EOI at GIC sysreg interface. Adding it to the > >> GIC EOI > > > > Thanks for the confirmation. Now it’s about choosing the right place. > > > >> API seems the logical thing to do but as Olivier mentions, there are > >> interrupt > >> handler which do not deal with MMIO (eg: the Systimer interrupt) so > >> adding > >> it > >> to GICv3 API might be arduous for such handlers. > >> > >> So there is a choice here to let the interrupt handlers to deal with > >> ensuring > >> completeness before EOI at sysreg interface or adding it to GICv3 EOI > >> API > >> and > >> take the overhead for interrupt handlers which do not have to deal with > >> MMIO. > >> > > > > Yes I feel either of these is a must to guarantee functionality > > architecturally though > > both approach end up with some unnecessary overhead. > > > > If GICv3 api takes care then it is an overhead for some ISRs dealing > > with > > non-MMIO. > > At present I do not see an active use case in reference implementation > > where > > sys timer > > ISR is in a performance intensive path where one additional DSB will be > > perceivable. > > But there may be some I could be totally wrong in this assumption > (pmu/debug > > or.. not sure). > > Whereas I can certainly imagine some MMIO ISRs in performance critical > > path > > where unnecessary > > DSB is not acceptable at all. > > > > If the interrupt handler needs to ensure then it will generically add > > 'DSB' > > as I think > > the driver cannot and should not make assumptions about how EOI is done > > afterwards. > > That will be overhead for the ISRs dealing with MMIO peripherals and non > > GIC-v3. > > If we consider only GICv3+ then good. Otherwise I would prefer the > > 'plat_ic_end_of_interrupt' > > like Olivier mentioned with a #if GICv3 instead of each ISRs dealing > > with > > it. > > > >> The GICv3 legacy MMIO CPU interface is deprecated for TF-A and the sys > >> interface is the only one GICv3 driver in TF-A supports. > > > > Right we can ignore the GICv3 legacy mode but GICv2 will still remain ? > > > >> > >> Best Regards > >> Soby Mathew > >> > > > > Thanks > > Sandeep > > > >>> -----Original Message----- > >>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > Sandeep > >>> Tripathy via TF-A > >>> Sent: 08 June 2020 10:34 > >>> To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf- > >> a(a)lists.trustedfirmware.org > >>> Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC > >>> > >>> Hi Olivier, > >>>> -----Original Message----- > >>>> From: Olivier Deprez [mailto:Olivier.Deprez@arm.com] > >>>> Sent: Monday, June 08, 2020 1:14 PM > >>>> To: tf-a(a)lists.trustedfirmware.org; Sandeep Tripathy > >>>> Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC > >>>> > >>>> Hi Sandeep, > >>>> > >>>> gicv3_end_of_interrupt_sel1 is a static access helper macro. Its > >>>> naming precisely tells what it does at gicv3 module level. It is > >>>> called from > >>> the weak > >>>> plat_ic_end_of_interrupt function for BL32 image. > >>>> > >>>> I tend to think it is the driver responsibility to ensure the module > >>> interrupt > >>>> acknowledge register write is reaching HW in order (or "be visible to > >>> all > >>>> observers"). > >>> > >>> The driver should be agnostic of what interrupt controller is used and > >>> its > >>> behavior. > >>> And since 'all' writes were to mmio ranges mapped Device(nGnRE) > >>> /strongly-ordered(nGnRnE) > >>> there was no such need. This is a special case for GICv3 system > >>> interface only. > >>> Adding at driver level a DSB is unnecessary for other interrupt > >>> controllers. > >>> > >>>> Also I suspect adding a dsb might not be required generically for all > >>> kind of IP. > >>> > >>> Here are you referring to the peripheral IP or interrupt controller IP > >>> ? > >>> The issue is reordering at arm core itself (STR to device address Vs > >>> msr(sysreg > >>> write)). > >>> So I think Its applicable for all IP. > >>> > >>>> Adding a barrier in generic code might incur an unnecessary > >>>> bottleneck. > >>> > >>> But if there is a need to *ensure* presence of at least one DSB > >>> between > >>> the > >>> write transfer from core to device clear and gicv3 eoi icc register > >>> write in a > >>> generic way then what other option we have. > >>>> > >>>> Thus wouldn't it be better to add the barrier to the overridden > >>>> platform function rather than in generic gicv3 code? > >>> > >>> That can be done but I feel this is more to do with gicv3 system > >>> interface only. > >>> Inside plat_xxx one has to check #if GICV3 ...and system interface. > >>>> > >>>> I have a put a comment in the review, we can continue the discussion > >>> there. > >>>> > >>>> Regards, > >>>> Olivier. > >>>> > >>> Thanks > >>> Sandeep > >>>> ________________________________________ > >>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of > >>>> Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> > >>>> Sent: 05 June 2020 19:43 > >>>> To: tf-a(a)lists.trustedfirmware.org > >>>> Subject: [TF-A] GICV3: system interface EOI ordering RFC > >>>> > >>>> Hi, > >>>> In a typical interrupt handling sequence we do 1-Read IAR > >>>> 2-Do interrupt handling > >>>> 3-Clear the interrupt at source , so that the device de-asserts > >>>> IRQ > >>> request to > >>>> GIC > >>>> >> I am suggesting a need of DSB here in case of GICv3 +. > >>>> 4-Write to GIC cpu interface to do EOI. > >>>> > >>>> Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write > >>>> over > >>> AMBA > >>>> interface. The > >>>> Addresses are mapped with (nR) attribute. Hence the write transfers > >>> from the > >>>> core will be > >>>> generated at step 3 and 4 in order. Please ignore the additional > >>> buffers/bridges > >>>> in path from > >>>> core till peripheral which has to be dealt separately as per SOC. > >>>> > >>>> Query: I understand GICv3 system interface accesses are not over > >>>> this > >>> protocol > >>>> and core will not > >>>> follow the ordering rule ? > >>>> > >>>> I have observed spurious interrupt issue/manifestation ( I don't have > >>> the > >>>> transfers probed) in > >>>> RTOS environment where I have a primitive GICv3 driver but I wonder > >>>> why things does not fail in Linux or tf-a. If it is working because > >>>> from step(3) to > >>> step(4) we have > >>>> barriers by chace > >>>> due to other device register writes then I would suggest to have one > >>>> in > >>> the EOI > >>>> clearing API itself. > >>>> > >>>> RFC: > >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454 > >>>> > >>>> Thanks > >>>> Sandeep > >>> -- > >>> 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

5 years, 8 months

3
9
0 0

Re: [TF-A] Upgrading libfdt library

by Joanna Farley

I think it is clear Madhu has been applying due diligence here both in his own testing and notification to the project through the ML so that consumers can respond and also perform any testing they feel is necessary. In think its appropriate for us to pause while we wait for such feedback but it would be good to have some indication on who feels there might be an issue here and wants to provide feedback. I appreciate you are Varun and we need to analyse the risks and what mitigations need to be in place. As you may have picked up on from the various tech forums we take testing seriously and are looking to augment with different test strategies and tools however these will take time to deploy and spread their coverage through the project codebase. Until then we will have to analyse the level of risk and apply the appropriate level of mitigations which I think Madhu has but lets see if we have some specific issues needing further mitigations to give more confidence. Thanks Joanna On 19/06/2020, 23:35, "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, Thanks for the information. Adding libfdt to the unit testing framework is a good idea. The verification should give us more confidence on the stability side. Let’s see if platform owners would like to include more tests. -Varun -----Original Message----- From: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> Sent: Friday, June 19, 2020 1:01 PM To: Varun Wadekar <vwadekar(a)nvidia.com> Cc: tf-a(a)lists.trustedfirmware.org Subject: RE: [TF-A] Upgrading libfdt library External email: Use caution opening links or attachments Hi Varun I tested the patch by running all applicable tf-a-tests suites [1] and Linux boot tests on FVP and Juno platforms. Since libfdt is platform agnostic, we are planning on adding it to the unit test framework as well(which was described in yesterday's tech forum). I need to admit that I am (over!) confident about libfdt since it is also used in U-boot and Linux projects. It seems the release tags don’t have much significance in the dtc project. Hence, I picked the latest commit at the time. In our internal CI, we also run Coverity MISRA and other static checks to find issues in TF-A and fix them as needed. However, we don’t fix issues reported in 3rd party libraries such as libfdt. I am waiting to hear feedback from various platform owners if they have any issues with this upgrade. [1] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests Thanks, Madhukar -----Original Message----- From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: Thursday, June 18, 2020 1:30 PM To: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org Subject: RE: [TF-A] Upgrading libfdt library Hi, I think there are some valid concerns raised in the thread. Since this is an external project I felt we needed to set a criteria for the upgrade. One day, when we start using the unit testing framework and have 100% coverage numbers and solid positive/negative testing, we would be more confident. Until then we just have to live with what have. @Madhukar is there any we can find out all the tests, static analysis checks, security checks that was run on the upgrade? Just trying to understand how confident we are that this does not introduce any regressions? -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghu K via TF-A Sent: Thursday, June 18, 2020 9:07 AM To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Upgrading libfdt library External email: Use caution opening links or attachments One thing that might be worth considering is versioning the library like xlat_tables and xlat_tables_v2 for a few releases and deprecate the old one if/when there is broad agreement from platforms to move to the new one. Platforms can perform their independent testing like STM and can report back over time. Obviously, for those few releases if there are API changes in libfdt there will have to be support for both new and old api's which will cause temporary ugliness but this might ease concerns about testing, stability etc. -Raghu On 6/18/20 4:12 AM, Soby Mathew via TF-A wrote: >> -----Original Message----- >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of >> Sandrine Bailleux via TF-A >> Sent: 16 June 2020 13:09 >> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Madhukar Pappireddy >> <Madhukar.Pappireddy(a)arm.com>; Varun Wadekar <vwadekar(a)nvidia.com> >> Cc: tf-a(a)lists.trustedfirmware.org >> Subject: Re: [TF-A] Upgrading libfdt library >> >> Hi Alexei, >> >> On 6/16/20 1:51 PM, Alexei Fedorov wrote: >>> Thanks for your very detailed explanation of the reason behind this >>> solution. >>> This brings the question on how do we monitor libfdt bug fixes, code >>> cleanup, etc. (which Madhukar pointed out) and integrate these >>> changes in TF-A source tree. >> Right now, it is a manual process and not only for libfdt but for all >> projects TF-A depends on. We keep an eye on them and aim at updating >> them when necessary. Unfortunately, like any manual process, it is >> error-prone and things might slip through the cracks. The TF-A >> release tick is usually a good reminder to update all dependencies >> but unfortunately libfdt has been left behind for some time (about 2 years)... > As I recall, when we tried to update libfdt last time, there was significant code bloat in generated binary (feature creep?) and we abandoned the update. The policy was to stick to a stable version and only update if there are any bugfixes or new feature we would want to make use of. > > Generally speaking, we might have done several fixes in the imported 3rd party library by running static checks like for MISRA compliance etc and this has to be repeated when the library is updated. Also, for security audits, it is important to be sure of the "security status" of the imported library and hence we tended to not update for every release. > > But I agree that we do have to be on top of bug fixes and hence we need to update but not sure how we can balance this with concerns above. > > Regarding MbedTLS, being a security critical project, we would like to encourage platform integrators to take ownership of staying upto date rather than relying on update from TF-A repo. Hence the motivation to keep it separate. > > Best Regards > Soby Mathew > > > > >> Regards, >> Sandrine >> -- >> 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 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 9 months

1
0
0 0

Re: [TF-A] Upgrading libfdt library

by Varun Wadekar

Hi, I think there are some valid concerns raised in the thread. Since this is an external project I felt we needed to set a criteria for the upgrade. One day, when we start using the unit testing framework and have 100% coverage numbers and solid positive/negative testing, we would be more confident. Until then we just have to live with what have. @Madhukar is there any we can find out all the tests, static analysis checks, security checks that was run on the upgrade? Just trying to understand how confident we are that this does not introduce any regressions? -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghu K via TF-A Sent: Thursday, June 18, 2020 9:07 AM To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Upgrading libfdt library External email: Use caution opening links or attachments One thing that might be worth considering is versioning the library like xlat_tables and xlat_tables_v2 for a few releases and deprecate the old one if/when there is broad agreement from platforms to move to the new one. Platforms can perform their independent testing like STM and can report back over time. Obviously, for those few releases if there are API changes in libfdt there will have to be support for both new and old api's which will cause temporary ugliness but this might ease concerns about testing, stability etc. -Raghu On 6/18/20 4:12 AM, Soby Mathew via TF-A wrote: >> -----Original Message----- >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of >> Sandrine Bailleux via TF-A >> Sent: 16 June 2020 13:09 >> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Madhukar Pappireddy >> <Madhukar.Pappireddy(a)arm.com>; Varun Wadekar <vwadekar(a)nvidia.com> >> Cc: tf-a(a)lists.trustedfirmware.org >> Subject: Re: [TF-A] Upgrading libfdt library >> >> Hi Alexei, >> >> On 6/16/20 1:51 PM, Alexei Fedorov wrote: >>> Thanks for your very detailed explanation of the reason behind this >>> solution. >>> This brings the question on how do we monitor libfdt bug fixes, code >>> cleanup, etc. (which Madhukar pointed out) and integrate these >>> changes in TF-A source tree. >> Right now, it is a manual process and not only for libfdt but for all >> projects TF-A depends on. We keep an eye on them and aim at updating >> them when necessary. Unfortunately, like any manual process, it is >> error-prone and things might slip through the cracks. The TF-A >> release tick is usually a good reminder to update all dependencies >> but unfortunately libfdt has been left behind for some time (about 2 years)... > As I recall, when we tried to update libfdt last time, there was significant code bloat in generated binary (feature creep?) and we abandoned the update. The policy was to stick to a stable version and only update if there are any bugfixes or new feature we would want to make use of. > > Generally speaking, we might have done several fixes in the imported 3rd party library by running static checks like for MISRA compliance etc and this has to be repeated when the library is updated. Also, for security audits, it is important to be sure of the "security status" of the imported library and hence we tended to not update for every release. > > But I agree that we do have to be on top of bug fixes and hence we need to update but not sure how we can balance this with concerns above. > > Regarding MbedTLS, being a security critical project, we would like to encourage platform integrators to take ownership of staying upto date rather than relying on update from TF-A repo. Hence the motivation to keep it separate. > > Best Regards > Soby Mathew > > > > >> Regards, >> Sandrine >> -- >> 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

5 years, 9 months

2
2
0 0

How should we manage patches affecting multiple users?

by Sandrine Bailleux

Hello everyone, I would like to start a discussion around the way we want to handle changes that affect all platforms/users. This subject came up in this code review [1]. I'll present my views on the subject and would like to know what others think. First of all, what do we mean by "changes that affect all platforms"? It would be any change that is not self-contained within a platform port. IOW, a change in some file outside of the plat/ directory. It could be in a driver, in a library, in the build system, in the platform interfaces called by the generic code... the list goes on. 1. Some are just implementation changes, they leave the interfaces unchanged. These do not break other platforms builds since the call sites don't need to be updated. However, they potentially change the responsibilities of the interface, in which case this might introduce behavioral changes that all users of the interface need to be aware of and adapt their code to. 2. Some other changes might introduce optional improvements. They introduce a new way of doing things, perhaps a cleaner or more efficient one. Users can safely stay with the old way of doing things without fear of breakage but they would benefit from migrating. This is the case of Alexei's patch [1], which introduces an intermediate GICv2 makefile, that Arm platforms now include instead of pulling each individual file by themselves. At this point, it is just an improvement that introduces an indirection level in the build system. This is an improvement in terms of maintainability because if we add a new essential file to this driver in the future, we'll just need to add it in this new GICv2 makefile without having to update all platforms makefiles. However, platform makefiles can continue to pull in individual files if they wish to. 3. Some other changes might break backwards compatibility. This is something we should avoid as much as possible and we should always strive to provide a migration path. But there are cases where there might be no other way than to break things. In this case, all users have to be migrated. Now the question we were pondering in Gerrit is, where does the responsibility of migrating all platforms/users lie for all these types of changes? Is the patch author responsible to do all the work? I think it's hard to come up with a one-size-fits-all answer. It really depends on the nature of changes, their consequences, the amount of work needed to do the migration, the ability for the patch author to test these changes, to name a few. I believe the patch author should migrate all users on a best-effort basis. If it's manageable then they should do the work and propose a patch to all affected users for them to review and test on their platforms. On the other hand, if it's too much work or impractical, then I think the best approach would be for the patch author to announce and discuss the changes on this mailing list. In some scenarios, the changes might be controversial and not all platform owners might agree that the patch brings enough benefit compared to the migration effort, in which case the changes might have to be withdrawn or re-thought. In any case, I believe communication is key here and no one should take any unilateral decision on their own if it affects other users. I realize this is a vast subject and that we probably won't come up with an answer/reach an agreement on all the aspects of the question. But I'd be interested in hearing other contributors' view and if they've got any experience managing these kinds of issues, perhaps in other open source project. Best regards, Sandrine [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4538

5 years, 9 months

1
0
0 0

Re: [TF-A] ATF LTS version

by Varun Wadekar

Hello Joanna, I had discussed the idea with Matteo in the past, but the discussion in the last tech forum prompted the email. >> I appreciate this CI is currently a little opaque to many contributors as this is still in the process of being transitioned to the OpenCI hosted by Trustedfirmware.org servers which will be visible to all I agree, it is hard to test all the use cases. The opaque nature of the CI is a bit annoying, but not a big issue. >> the additional testing done for a 6 monthly tagged release is quite minimal and the larger work is ensuring all documentation is up to date. Additionally all new features are generally behind their own build flags but I appreciate it is some work for a tagged release to be absorbed into product offerings. Interesting In one of our internal discussions we were exploring the possibility of using doxygen style comments and creating an API reference for a release without a lot of effort. We should try to explore this idea in the community. >> One thing that had been considered briefly was the production of a security bug only branch That is a good idea and can act as the base for the LTS version. But we should consider increasing the scope and include bug fixes, stability issues, performance issues, etc. I believe when the community widely adopts TFTF and starts upstreaming the test cases, we can expect more interest around a LTS release. For platform owners (e.g. NVIDIA) it makes sense to plan our release strategy around LTS versions. Right now, our releases lack direction as we don’t know which version to use. And then there is additional pain of rebasing recent fixes/improvements on older releases. -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joanna Farley via TF-A Sent: Thursday, June 11, 2020 6:47 AM To: Matteo Carlini <Matteo.Carlini(a)arm.com>; tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] ATF LTS version External email: Use caution opening links or attachments Hi Varun, I guess this suggestion came in response to last weeks Tech Forum discussion from a question about experiences people had from migrating to different TF-A tagged releases. In general we try and keep the tip of Master at tagged release quality through an extensive CI system ran on each patch. I appreciate this CI is currently a little opaque to many contributors as this is still in the process of being transitioned to the OpenCI hosted by Trustedfirmware.org servers which will be visible to all. As mentioned in the recent "Overview of the TF-A v2.3 Release" presentation on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ the additional testing done for a 6 monthly tagged release is quite minimal and the larger work is ensuring all documentation is up to date. Additionally all new features are generally behind their own build flags but I appreciate it is some work for a tagged release to be absorbed into product offerings. I asked at the tech forum last week what more we could do to allow releases to be integrated more easily. On the call it was requested if we could disable weak bindings to symbols so it could be more easily seen where platform decisions may need to be made and we will look into this. If there are any more adjustments to the way tagged releases are produced please let us know. One thing that had been considered briefly was the production of a security bug only branch that was maintained only between 6 month tagged releases before being replaced by the next security bug only branch based on the next 6 month release but that has not progressed very far as a proposal as until your email here it was perceived to not be in demand. A LTS branch is a larger endeavour as it sounds like something that includes more than security fixes and I look forward to you elaborating more as Matteo requests. Thanks Joanna On 11/06/2020, 12:19, "Matteo Carlini via TF-A" <tf-a(a)lists.trustedfirmware.org> wrote: Hi Varun, Thanks for raising this topic (but please do embrace the official terminology “TF-A”…we never really promoted ATF and it's also absolutely outdated now 😉 ). Arm has received different queries over time on supporting Trusted Firmware LTS releases, but the effort to sustain them is something that the Arm engineering team alone cannot really afford and commit to (either in the TF-A or TF-M space). The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers, so to evaluate the possibility of a more concrete proposal to be carried on within the community Project. I guess it will also be good to start by elaborating more concretely on the requirements that you would like to see in an hypothetical LTS versioning scheme. Thanks Matteo > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A > Sent: 10 June 2020 22:47 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] ATF LTS version > > Hello team, > > To extend the discussion around version upgrades from our last call, I would like to understand if there is enough interest around generating a LTS version of the TF-A to alleviate the pain. > > For NVIDIA, this would be helpful as it streamlines the upgrade path for our devices in the field. The LTS version will guarantee security fixes, bug fixes, stability fixes for the longer term and we won’t have to upgrade the entire firmware to get these goodies. > > It would be interesting to see what OEMs and maintainers think about this? Has this been discussed at tf.org or Arm internally? > > -Varun -- 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

5 years, 9 months

2
3
0 0

Re: [TF-A] Upgrading libfdt library

by Raghu K

One thing that might be worth considering is versioning the library like xlat_tables and xlat_tables_v2 for a few releases and deprecate the old one if/when there is broad agreement from platforms to move to the new one. Platforms can perform their independent testing like STM and can report back over time. Obviously, for those few releases if there are API changes in libfdt there will have to be support for both new and old api's which will cause temporary ugliness but this might ease concerns about testing, stability etc. -Raghu On 6/18/20 4:12 AM, Soby Mathew via TF-A wrote: >> -----Original Message----- >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandrine >> Bailleux via TF-A >> Sent: 16 June 2020 13:09 >> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Madhukar Pappireddy >> <Madhukar.Pappireddy(a)arm.com>; Varun Wadekar <vwadekar(a)nvidia.com> >> Cc: tf-a(a)lists.trustedfirmware.org >> Subject: Re: [TF-A] Upgrading libfdt library >> >> Hi Alexei, >> >> On 6/16/20 1:51 PM, Alexei Fedorov wrote: >>> Thanks for your very detailed explanation of the reason behind this >>> solution. >>> This brings the question on how do we monitor libfdt bug fixes, code >>> cleanup, etc. (which Madhukar pointed out) and integrate these changes >>> in TF-A source tree. >> Right now, it is a manual process and not only for libfdt but for all projects TF-A >> depends on. We keep an eye on them and aim at updating them when >> necessary. Unfortunately, like any manual process, it is error-prone and things >> might slip through the cracks. The TF-A release tick is usually a good reminder >> to update all dependencies but unfortunately libfdt has been left behind for >> some time (about 2 years)... > As I recall, when we tried to update libfdt last time, there was significant code bloat in generated binary (feature creep?) and we abandoned the update. The policy was to stick to a stable version and only update if there are any bugfixes or new feature we would want to make use of. > > Generally speaking, we might have done several fixes in the imported 3rd party library by running static checks like for MISRA compliance etc and this has to be repeated when the library is updated. Also, for security audits, it is important to be sure of the "security status" of the imported library and hence we tended to not update for every release. > > But I agree that we do have to be on top of bug fixes and hence we need to update but not sure how we can balance this with concerns above. > > Regarding MbedTLS, being a security critical project, we would like to encourage platform integrators to take ownership of staying upto date rather than relying on update from TF-A repo. Hence the motivation to keep it separate. > > Best Regards > Soby Mathew > > > > >> Regards, >> Sandrine >> -- >> TF-A mailing list >> TF-A(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 9 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A