- TF-A - lists.trustedfirmware.org

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 12 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 12 of 12 defect(s) ** CID 369886: Uninitialized variables (UNINIT) /drivers/nxp/flexspi/nor/fspi.c: 130 in fspi_op_setup() ________________________________________________________________________________________________________ *** CID 369886: Uninitialized variables (UNINIT) /drivers/nxp/flexspi/nor/fspi.c: 130 in fspi_op_setup() 124 cmd_id2 = FSPI_NOR_CMD_RDSR; 125 break; 126 } 127 128 x_addr = FSPI_LUTREG_OFFSET + (uint32_t)(0x10 * fspi_op_seq_id); 129 if ((F_FLASH_SIZE_BYTES <= SZ_16M_BYTES) || (ignore_flash_sz)) { >>> CID 369886: Uninitialized variables (UNINIT) >>> Using uninitialized value "cmd_id1". 130 x_instr0 = FSPI_INSTR_OPRND0(cmd_id1); 131 x_instr1 = FSPI_INSTR_OPRND1(FSPI_LUT_ADDR24BIT); 132 VERBOSE("CMD_ID = %x offset = 0x%x\n", cmd_id1, x_addr); 133 } else { 134 x_instr0 = FSPI_INSTR_OPRND0(cmd_id2); 135 x_instr1 = FSPI_INSTR_OPRND1(FSPI_LUT_ADDR32BIT); ** CID 369885: Memory - corruptions (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 369885: Memory - corruptions (ARRAY_VS_SINGLETON) /plat/nxp/common/nv_storage/plat_nv_storage.c: 64 in read_nv_app_data() 58 if (ret != XSPI_SUCCESS) { 59 ERROR("Failed to initialized driver flexspi-nor.\n"); 60 ERROR("exiting warm-reset request.\n"); 61 return -ENODEV; 62 } 63 >>> CID 369885: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Passing "(uint32_t *)&nv_app_data" to function "xspi_read" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 64 xspi_read(nv_base_addr, 65 (uint32_t *)&nv_app_data, sizeof(nv_app_data_t)); 66 xspi_sector_erase((uint32_t) nv_base_addr, 67 F_SECTOR_ERASE_SZ); 68 #endif 69 return ret; ** CID 369884: Memory - corruptions (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 369884: Memory - corruptions (ARRAY_VS_SINGLETON) /drivers/brcm/i2c/i2c.c: 669 in i2c_send_byte() 663 struct iproc_xact_info info; 664 665 iproc_i2c_fill_info(&info, bus_id, devaddr, 0U, &value, 666 SMBUS_PROT_SEND_BYTE, 0U); 667 668 /* Refer to i2c_smbus_write_byte params passed. */ >>> CID 369884: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Passing "info.data" via argument "&info" to function "iproc_i2c_data_send" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 669 rc = iproc_i2c_data_send(&info); 670 671 if (rc < 0) { 672 ERROR("%s: %s error accessing device 0x%x\n", 673 __func__, "Write", devaddr); 674 } ** CID 369883: Memory - illegal accesses (UNINIT) ________________________________________________________________________________________________________ *** CID 369883: Memory - illegal accesses (UNINIT) /drivers/nxp/crypto/caam/src/caam.c: 142 in configure_jr() 136 return -1; 137 } 138 139 start_jr(num); 140 141 /* Do HW configuration of the JR */ >>> CID 369883: Memory - illegal accesses (UNINIT) >>> Using uninitialized value "reg_base_addr" when calling "init_job_ring". 142 job_ring = init_job_ring(SEC_NOTIFICATION_TYPE_POLL, 0, 0, 143 reg_base_addr, 0); 144 145 if (job_ring == NULL) { 146 ERROR("Error in init_job_ring"); 147 return -1; ** CID 369882: (BAD_SHIFT) /drivers/nxp/ddr/phy-gen2/phy.c: 2320 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2338 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2308 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2347 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2334 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2329 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2312 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2351 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2298 in parse_odt() /drivers/nxp/ddr/phy-gen2/phy.c: 2316 in parse_odt() ________________________________________________________________________________________________________ *** CID 369882: (BAD_SHIFT) /drivers/nxp/ddr/phy-gen2/phy.c: 2320 in parse_odt() 2314 case DDR_ODT_OTHER_DIMM: 2315 for (j = 0; j < DDRC_NUM_CS; j++) { 2316 if ((((cs_d0 & (1 << i)) != 0) && 2317 ((cs_d1 & (1 << j)) != 0)) || 2318 (((cs_d1 & (1 << i)) != 0) && 2319 ((cs_d0 & (1 << j)) != 0))) { >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2320 odt[j] |= (1 << i) << shift; 2321 } 2322 } 2323 break; 2324 case DDR_ODT_ALL: 2325 for (j = 0; j < DDRC_NUM_CS; j++) { /drivers/nxp/ddr/phy-gen2/phy.c: 2338 in parse_odt() 2332 case DDR_ODT_SAME_DIMM: 2333 for (j = 0; j < DDRC_NUM_CS; j++) { 2334 if ((((cs_d0 & (1 << i)) != 0) && 2335 ((cs_d0 & (1 << j)) != 0)) || 2336 (((cs_d1 & (1 << i)) != 0) && 2337 ((cs_d1 & (1 << j)) != 0))) { >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2338 odt[j] |= (1 << i) << shift; 2339 } 2340 } 2341 break; 2342 case DDR_ODT_OTHER_CS_ONSAMEDIMM: 2343 for (j = 0; j < DDRC_NUM_CS; j++) { /drivers/nxp/ddr/phy-gen2/phy.c: 2308 in parse_odt() 2302 if (i == j) { 2303 continue; 2304 } 2305 if (((cs_d0 | cs_d1) & (1 << j)) == 0) { 2306 continue; 2307 } >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2308 odt[j] |= (1 << i) << shift; 2309 } 2310 break; 2311 case DDR_ODT_CS_AND_OTHER_DIMM: 2312 odt[i] |= (1 << i) << 4; 2313 /* fallthrough */ /drivers/nxp/ddr/phy-gen2/phy.c: 2347 in parse_odt() 2341 break; 2342 case DDR_ODT_OTHER_CS_ONSAMEDIMM: 2343 for (j = 0; j < DDRC_NUM_CS; j++) { 2344 if (i == j) { 2345 continue; 2346 } >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2347 if ((((cs_d0 & (1 << i)) != 0) && 2348 ((cs_d0 & (1 << j)) != 0)) || 2349 (((cs_d1 & (1 << i)) != 0) && 2350 ((cs_d1 & (1 << j)) != 0))) { 2351 odt[j] |= (1 << i) << shift; 2352 } /drivers/nxp/ddr/phy-gen2/phy.c: 2334 in parse_odt() 2328 } 2329 odt[j] |= (1 << i) << shift; 2330 } 2331 break; 2332 case DDR_ODT_SAME_DIMM: 2333 for (j = 0; j < DDRC_NUM_CS; j++) { >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2334 if ((((cs_d0 & (1 << i)) != 0) && 2335 ((cs_d0 & (1 << j)) != 0)) || 2336 (((cs_d1 & (1 << i)) != 0) && 2337 ((cs_d1 & (1 << j)) != 0))) { 2338 odt[j] |= (1 << i) << shift; 2339 } /drivers/nxp/ddr/phy-gen2/phy.c: 2329 in parse_odt() 2323 break; 2324 case DDR_ODT_ALL: 2325 for (j = 0; j < DDRC_NUM_CS; j++) { 2326 if (((cs_d0 | cs_d1) & (1 << j)) == 0) { 2327 continue; 2328 } >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2329 odt[j] |= (1 << i) << shift; 2330 } 2331 break; 2332 case DDR_ODT_SAME_DIMM: 2333 for (j = 0; j < DDRC_NUM_CS; j++) { 2334 if ((((cs_d0 & (1 << i)) != 0) && /drivers/nxp/ddr/phy-gen2/phy.c: 2312 in parse_odt() 2306 continue; 2307 } 2308 odt[j] |= (1 << i) << shift; 2309 } 2310 break; 2311 case DDR_ODT_CS_AND_OTHER_DIMM: >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2312 odt[i] |= (1 << i) << 4; 2313 /* fallthrough */ 2314 case DDR_ODT_OTHER_DIMM: 2315 for (j = 0; j < DDRC_NUM_CS; j++) { 2316 if ((((cs_d0 & (1 << i)) != 0) && 2317 ((cs_d1 & (1 << j)) != 0)) || /drivers/nxp/ddr/phy-gen2/phy.c: 2351 in parse_odt() 2345 continue; 2346 } 2347 if ((((cs_d0 & (1 << i)) != 0) && 2348 ((cs_d0 & (1 << j)) != 0)) || 2349 (((cs_d1 & (1 << i)) != 0) && 2350 ((cs_d1 & (1 << j)) != 0))) { >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2351 odt[j] |= (1 << i) << shift; 2352 } 2353 } 2354 break; 2355 case DDR_ODT_NEVER: 2356 break; /drivers/nxp/ddr/phy-gen2/phy.c: 2298 in parse_odt() 2292 2293 if (i < 0 || i > 3) { 2294 printf("Error: invalid chip-select value\n"); 2295 } 2296 switch (val) { 2297 case DDR_ODT_CS: >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2298 odt[i] |= (1 << i) << shift; 2299 break; 2300 case DDR_ODT_ALL_OTHER_CS: 2301 for (j = 0; j < DDRC_NUM_CS; j++) { 2302 if (i == j) { 2303 continue; /drivers/nxp/ddr/phy-gen2/phy.c: 2316 in parse_odt() 2310 break; 2311 case DDR_ODT_CS_AND_OTHER_DIMM: 2312 odt[i] |= (1 << i) << 4; 2313 /* fallthrough */ 2314 case DDR_ODT_OTHER_DIMM: 2315 for (j = 0; j < DDRC_NUM_CS; j++) { >>> CID 369882: (BAD_SHIFT) >>> In expression "1 << i", shifting by a negative amount has undefined behavior. The shift amount, "i", is no more than -1. 2316 if ((((cs_d0 & (1 << i)) != 0) && 2317 ((cs_d1 & (1 << j)) != 0)) || 2318 (((cs_d1 & (1 << i)) != 0) && 2319 ((cs_d0 & (1 << j)) != 0))) { 2320 odt[j] |= (1 << i) << shift; 2321 } ** CID 369881: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 369881: Memory - corruptions (OVERRUN) /drivers/brcm/i2c/i2c.c: 556 in i2c_init() 550 { 551 if (bus_id > MAX_I2C) { 552 WARN("%s: Invalid Bus %u\n", __func__, bus_id); 553 return -1; 554 } 555 >>> CID 369881: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 2 by passing argument "bus_id" (which evaluates to 2) in call to "iproc_i2c_init". 556 iproc_i2c_init(bus_id, speed); 557 return 0U; 558 } 559 560 /* 561 * Function Name: i2c_probe ** CID 369880: Error handling issues (CHECKED_RETURN) /drivers/nxp/ddr/nxp-ddr/utility.c: 43 in get_ddr_freq() ________________________________________________________________________________________________________ *** CID 369880: Error handling issues (CHECKED_RETURN) /drivers/nxp/ddr/nxp-ddr/utility.c: 43 in get_ddr_freq() 37 #define CCN_HN_F_SAM_NODEID_DDR1 0x18 38 #endif 39 40 unsigned long get_ddr_freq(struct sysinfo *sys, int ctrl_num) 41 { 42 if (sys->freq_ddr_pll0 == 0) { >>> CID 369880: Error handling issues (CHECKED_RETURN) >>> Calling "get_clocks" without checking return value (as is done elsewhere 4 out of 5 times). 43 get_clocks(sys); 44 } 45 46 switch (ctrl_num) { 47 case 0: 48 return sys->freq_ddr_pll0; ** CID 369879: Memory - corruptions (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 369879: Memory - corruptions (ARRAY_VS_SINGLETON) /drivers/brcm/i2c/i2c.c: 763 in i2c_write_byte() 757 struct iproc_xact_info info; 758 759 iproc_i2c_fill_info(&info, bus_id, devaddr, regoffset, &value, 760 SMBUS_PROT_WR_BYTE, 1U); 761 762 /* Refer to i2c_smbus_write_byte params passed. */ >>> CID 369879: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Passing "info.data" via argument "&info" to function "iproc_i2c_data_send" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 763 rc = iproc_i2c_data_send(&info); 764 765 if (rc < 0) { 766 ERROR("%s: %s error accessing device 0x%x\n", 767 __func__, "Write", devaddr); 768 return -1; ** CID 369878: Control flow issues (DEADCODE) /drivers/nxp/ddr/nxp-ddr/utility.c: 169 in disable_unused_ddrc() ________________________________________________________________________________________________________ *** CID 369878: Control flow issues (DEADCODE) /drivers/nxp/ddr/nxp-ddr/utility.c: 169 in disable_unused_ddrc() 163 debug("Both controllers in use.\n"); 164 return 0; 165 } 166 167 for (i = 0; i < num_hnf_nodes; i++) { 168 val = mmio_read_64((uintptr_t)hnf_sam_ctrl); >>> CID 369878: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "i < 4" inside this statement: "nodeid = ((disable_ddrc == ...". 169 nodeid = disable_ddrc == 1 ? CCN_HN_F_SAM_NODEID_DDR1 : 170 (disable_ddrc == 2 ? CCN_HN_F_SAM_NODEID_DDR0 : 171 (i < 4 ? CCN_HN_F_SAM_NODEID_DDR0 172 : CCN_HN_F_SAM_NODEID_DDR1)); 173 if (nodeid != (val & CCN_HN_F_SAM_NODEID_MASK)) { 174 debug("Setting HN-F node %d\n", i); ** CID 369877: Incorrect expression (NO_EFFECT) /drivers/nxp/ddr/nxp-ddr/utility.c: 145 in disable_unused_ddrc() ________________________________________________________________________________________________________ *** CID 369877: Incorrect expression (NO_EFFECT) /drivers/nxp/ddr/nxp-ddr/utility.c: 145 in disable_unused_ddrc() 139 switch (disable_ddrc) { 140 case 1: 141 priv->num_ctlrs = 1; 142 priv->spd_addr = &priv->spd_addr[priv->dimm_on_ctlr]; 143 priv->ddr[0] = priv->ddr[1]; 144 priv->ddr[1] = NULL; >>> CID 369877: Incorrect expression (NO_EFFECT) >>> Assigning "priv->phy[0]" to itself has no effect. 145 priv->phy[0] = priv->phy[0]; 146 priv->phy[1] = NULL; 147 debug("Disable first DDR controller\n"); 148 break; 149 case 2: 150 priv->num_ctlrs = 1; ** CID 369876: Incorrect expression (UNUSED_VALUE) /plat/nxp/soc-lx2160a/lx2160aqds/ddr_init.c: 333 in init_ddr() ________________________________________________________________________________________________________ *** CID 369876: Incorrect expression (UNUSED_VALUE) /plat/nxp/soc-lx2160a/lx2160aqds/ddr_init.c: 333 in init_ddr() 327 info.phy_gen2_fw_img_buf = PHY_GEN2_FW_IMAGE_BUFFER; 328 if (info.clk == 0) { 329 info.clk = get_ddr_freq(&sys, 1); 330 } 331 info.dimm_on_ctlr = DDRC_NUM_DIMM; 332 >>> CID 369876: Incorrect expression (UNUSED_VALUE) >>> Assigning value "DDR_WRM_BOOT_NT_SUPPORTED" to "info.warm_boot_flag" here, but that stored value is overwritten before it can be used. 333 info.warm_boot_flag = DDR_WRM_BOOT_NT_SUPPORTED; 334 #ifdef NXP_WARM_BOOT 335 info.warm_boot_flag = DDR_COLD_BOOT; 336 if (wrm_bt_flg != 0U) { 337 info.warm_boot_flag = DDR_WARM_BOOT; 338 } else { ** CID 369875: Uninitialized variables (UNINIT) /drivers/nxp/flexspi/nor/fspi.c: 134 in fspi_op_setup() ________________________________________________________________________________________________________ *** CID 369875: Uninitialized variables (UNINIT) /drivers/nxp/flexspi/nor/fspi.c: 134 in fspi_op_setup() 128 x_addr = FSPI_LUTREG_OFFSET + (uint32_t)(0x10 * fspi_op_seq_id); 129 if ((F_FLASH_SIZE_BYTES <= SZ_16M_BYTES) || (ignore_flash_sz)) { 130 x_instr0 = FSPI_INSTR_OPRND0(cmd_id1); 131 x_instr1 = FSPI_INSTR_OPRND1(FSPI_LUT_ADDR24BIT); 132 VERBOSE("CMD_ID = %x offset = 0x%x\n", cmd_id1, x_addr); 133 } else { >>> CID 369875: Uninitialized variables (UNINIT) >>> Using uninitialized value "cmd_id2". 134 x_instr0 = FSPI_INSTR_OPRND0(cmd_id2); 135 x_instr1 = FSPI_INSTR_OPRND1(FSPI_LUT_ADDR32BIT); 136 VERBOSE("CMD_ID = %x offset = 0x%x\n", cmd_id2, x_addr); 137 } 138 x_instr0 |= FSPI_INSTR_PAD0(FSPI_LUT_PAD1) 139 | FSPI_INSTR_OPCODE0(FSPI_LUT_CMD); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 7 months

1
0
0 0

Re: [TF-A] please fix incomplete distclean Makefile target

by Nicolas Boulenguez

raghu.ncstate(a)icloud.com: > Are you pushing ssh://<username>@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a HEAD:refs/for/integration? > Note that 29418 port. That tripped me up initially. It is not clear from your earlier emails where you cloned from(review.trustedfirmware.org or git.trustedfirmware.org). [α] links to [β] which recommends # git clone "https://review.trustedfirmware.org/TF-A/trusted-firmware-a" I had an existing repository (most contributors probably do) and used 'git add remote' and 'git fetch' instead. [α] recommends # git push <remote-name> HEAD:refs/for/integration%<topic-branch> As expected, the host requires a password. # git push ssh://<user>@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a HEAD:refs/for/integration? -> fatal: invalid refspec 'HEAD:refs/for/integration?' Anyhow, the host would require an SSH key. [α] https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/ [β] https://review.trustedfirmware.org/admin/repos/TF-A%2Ftrusted-firmware-a

4 years, 7 months

1
0
0 0

Re: [TF-A] please fix incomplete distclean Makefile target

by Sandrine Bailleux

Hi Nicolas, On 3/29/21 12:40 AM, Nicolas Boulenguez via TF-A wrote: > Currently, tools/cert_create/cert_create is not removed. > The attached one-line patch fixes this. Thank you for your patch! The TF-A project uses the Gerrit review system for patch reviews, would you mind resending your patch on review.trustedfirmware.org please? If you need help with that, there's a "getting started" guide there (it is a bit outdated but hopefully still helpful): https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/ And our project specific contribution guidelines are there: https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.html Regards, Sandrine

4 years, 7 months

2
6
0 0

Glitching protection

by François Ozog

Hi Trusted Firmware M recently introduced protection against glitching at key decision points: https://github.com/mcu-tools/mcuboot/pull/776 To me this is a key mitigation element for companies that target PSA level 3 compliance which means hardware attacks resilience. I believe similar techniques need to be used in different projects involved in Linux secure booting (TF-A, OP-TEE, U-Boot, Linux kernel). Are there any efforts planned around this ? Is it feasible to have a "library" that could be integrated in different projects? Cheers FF

4 years, 7 months

4
8
0 0

Re: [TF-A] Firmware FuSa workshop

by Miklos Balint

To += op-tee(a)lists.trustedfirmware.org<mailto:op-tee@lists.trustedfirmware.org> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of François Ozog via TF-A Sent: 26 March 2021 19:08 To: Heinrich Schuchardt <xypron.glpk(a)gmx.de> Cc: tf-a(a)lists.trustedfirmware.org; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org> Subject: Re: [TF-A] Firmware FuSa workshop Le ven. 26 mars 2021 à 18:42, Heinrich Schuchardt <xypron.glpk(a)gmx.de<mailto:xypron.glpk@gmx.de>> a écrit : On 26.03.21 16:05, François Ozog wrote: > Hi, > > > Linaro is conducting an opportunity assessment to make OP-TEE ready for > functional safety sensitive environments. The goal is to present a plan to > Linaro members by the end of July 2021. > > The scope of the research is somewhat bigger because we can’t think of > OP-TEE without thinking of Trusted Firmware and Hafnium. The plan will > though not address those (unless we recognize we have to). We don’t think > U-Boot shall be part of the picture but we are welcoming contradictory > points of views. Hello François, Some boards boot via SPL->TF-A->U-Boot. Here U-Boot's SPL is relevant for OP-TEE's security. U-Boot can save variables via OP-TEE (implemented by Ilias). In this case OP-TEE has an implication on secure boot. I fully understand that these scenarios are not in the focus of the workshop. it may if companies have this particular flow in mind for safety certification. Our goal is not to make all boot flows safety ready but to identify which ones we need to consider. And the workshop may help in this identification. Best regards Heinrich > > We are organizing a 2 hours workshop on April 15th 9am CET to mostly hear > about use cases and ideas about Long Term Support requirements . We will > present the state of the research. > > The first use case is booting a safety certified type-1 hypervisor (open > source or commercial is irrelevant). > > But we know there are many more: please be ready to contribute. > > We think of more radical use cases: a safety payload is actually loaded as > a Secure Partition on top of Hafnium with OP-TEE or Zephyr used as a device > backends. In other words, Trust Zone hosts both safety and security worlds > , EL3 being the « software root of trust » pivot world. In those cases, > some cores never go out of secure state… > > > Agenda (to be refined) > > - > > Vision > - > > State of the research > <https://docs.google.com/presentation/u/0/d/1jWqu39gCF-5XzbFkodXsiVNJJLUN88B…> > - > > Use cases discussion > - > > What is the right scope? > - > > “Who do what” discussion (LTS, archiving...) > - > > Safety personnel (Linaro and contractors) discussion > - > > Other considerations from participants? > - > > Community organizations and funding? > - > > Closing and next steps > > > Should you want to participate and have not yet received an invite, please > contact me directly. > > Cordially, > > François-Frédéric > > PS: Please reach out should you want another date with a time compatible > with more time zones. This alternate date is not guaranteed though. > > -- [https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&ex…] François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog

4 years, 7 months

1
0
0 0

please fix incomplete distclean Makefile target

by Nicolas Boulenguez

Hello. Currently, tools/cert_create/cert_create is not removed. The attached one-line patch fixes this.

4 years, 7 months

1
0
0 0

TF-A OpenCI Update

by Joanna Farley

Hi Everyone, I wanted to give an update on the availability of the TF-A OpenCI. Recognised projects contributors can now invoke the OpenCI on patches they submit or patches they review through Gerrit and so view results and fix any issues identified without an Arm reviewer having to intercede and start the Open CI for them. This is achieved in Gerrit patches (https://review.trustedfirmware.org/p/TF-A/trusted-firmware-a/+/dashboard/si…) by setting the Allow-CI label with +1 or +2 where +1 is a light level of testing and +2 includes additional tests on top of the +1 tests. Results are linked to in the Gerrit patch comments. Recognised projects contributors is currently seeded as everybody listed in https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about… including all maintainers and code-owners. The intent going forward is to include others when vouched for by other recognised projects contributors. In this way we hope to be open to all project contributors to have access to the OpenCI while providing some protection to the OpenCI back end resources. The plan is to have another TF-A Tech-Forum session on the OpenCI on 8th April 2021 where more of the details of the OpenCI can be shared, discussed and questions can be taken. For now please experiment with the OpenCI through your patch submissions or reviews. Please be aware this is a shared resource and use when appropriate during the patch review and be tolerant if its not quite perfect yet. Please rest assured the existing Legacy CI is still available during this transition to the OpenCI where needed to help ensure patches are adequately tested to maintain repository quality levels. I’ll like to say a big thanks to the Linaro team working in the background to provide the OpenCI service to the TF-A project. Cheers Joanna

4 years, 7 months

1
0
0 0

Firmware FuSa workshop

by François Ozog

Hi, Linaro is conducting an opportunity assessment to make OP-TEE ready for functional safety sensitive environments. The goal is to present a plan to Linaro members by the end of July 2021. The scope of the research is somewhat bigger because we can’t think of OP-TEE without thinking of Trusted Firmware and Hafnium. The plan will though not address those (unless we recognize we have to). We don’t think U-Boot shall be part of the picture but we are welcoming contradictory points of views. We are organizing a 2 hours workshop on April 15th 9am CET to mostly hear about use cases and ideas about Long Term Support requirements . We will present the state of the research. The first use case is booting a safety certified type-1 hypervisor (open source or commercial is irrelevant). But we know there are many more: please be ready to contribute. We think of more radical use cases: a safety payload is actually loaded as a Secure Partition on top of Hafnium with OP-TEE or Zephyr used as a device backends. In other words, Trust Zone hosts both safety and security worlds , EL3 being the « software root of trust » pivot world. In those cases, some cores never go out of secure state… Agenda (to be refined) - Vision - State of the research <https://docs.google.com/presentation/u/0/d/1jWqu39gCF-5XzbFkodXsiVNJJLUN88B…> - Use cases discussion - What is the right scope? - “Who do what” discussion (LTS, archiving...) - Safety personnel (Linaro and contractors) discussion - Other considerations from participants? - Community organizations and funding? - Closing and next steps Should you want to participate and have not yet received an invite, please contact me directly. Cordially, François-Frédéric PS: Please reach out should you want another date with a time compatible with more time zones. This alternate date is not guaranteed though. -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

4 years, 7 months

2
2
0 0

Glitching protection

by Tamas Ban

Hi, Recently the same fault injection protection code what is used in MCUboot was added to TF-M project. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7468 It is a library which can be reused in any project to harden the critical call path and condition checks, which are crucial from device security point of view. BR, Tamas Ban

4 years, 7 months

1
1
0 0

Re: [TF-A] Glitching protection

by Joanna Farley

Hi François, The TF-A team members have thought about trying to explore the use of more mitigations for Side Channel attacks along the lines of "Canary In the Coalmine" type techniques to as you say build additional resilience and as you can expect the techniques used by our peer TF-M project are one we would like to explore. I would not say this is a plan as such but definitely something already listed on our backlog. As to if the TF-M code can be reused that would need to be explored more. Cheers Joanna On 26/03/2021, 14:12, "TF-A on behalf of François Ozog via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Trusted Firmware M recently introduced protection against glitching at key decision points: https://github.com/mcu-tools/mcuboot/pull/776 To me this is a key mitigation element for companies that target PSA level 3 compliance which means hardware attacks resilience. I believe similar techniques need to be used in different projects involved in Linux secure booting (TF-A, OP-TEE, U-Boot, Linux kernel). Are there any efforts planned around this ? Is it feasible to have a "library" that could be integrated in different projects? Cheers FF -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A