- TF-A - lists.trustedfirmware.org

Does ARMv8 TrustZone provide a secure ROM?

by Iñigo Vicente Waliño

Hi, Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used as a trusted root or is it useless? If the TPM is changed to another, is the boot performed? Thanks, Inigo.

5 years, 4 months

1
0
0 0

(no subject)

by Iñigo Vicente Waliño

Hi, Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used as a trusted root or is it useless? If the TPM is changed to another, is the boot performed? Thanks, Inigo.

5 years, 4 months

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Sandrine Bailleux

Hi Sumit, On 1/8/20 7:09 AM, Sumit Garg via TF-A wrote: > Hi Sandrine, > > On Fri, 20 Dec 2019 at 12:29, Sumit Garg <sumit.garg(a)linaro.org> wrote: >> >> Hi Sandrine, >> >> On Wed, 18 Dec 2019 at 21:07, Sandrine Bailleux >> <Sandrine.Bailleux(a)arm.com> wrote: >>> >>> Hi Sumit, >>> >>> I've started providing some early review comments on your patches in >>> Gerrit but these are mainly about implementation details. I would like >>> to continue the higher-level design discussions here in parallel on the >>> mailing list, if that's fine with you. >>> >> >> Yes that's perfectly fine with me. >> > > Do you have any further comments? As I have already incorporated most > of the your comments related to design and implementation details in > latest v4 patch-set [1]. > > [1] https://review.trustedfirmware.org/q/topic:%22tbbr%252Ffw_enc%22+(status:op… Apologies, with the Christmas break, I haven't had a chance to look at your patches again. I will allocate some time for it this week and get back to you. Regards, Sandrine

5 years, 4 months

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Sandrine Bailleux

Hi Sumit, I've started providing some early review comments on your patches in Gerrit but these are mainly about implementation details. I would like to continue the higher-level design discussions here in parallel on the mailing list, if that's fine with you. On 12/6/19 1:29 PM, Sumit Garg via TF-A wrote: > Hi Sandrine, > > On Thu, 5 Dec 2019 at 20:31, Sandrine Bailleux > <Sandrine.Bailleux(a)arm.com> wrote: >>>> Also, I am still trying to get my head around how this would integrate >>>> with a cryptographic engine where the key does not leave the chip. I can >>>> imagine that we could get the address of the encrypted firmware image >>>> from the FIP, pass that to a cryptographic engine, request it to decrypt >>>> it and store the result somewhere in Trusted RAM. In this case, we >>>> wouldn't call plat_get_fip_encryption_key(). Do you have any idea how we >>>> would pull this off? Like how the different modules (IO layer, crypto >>>> module, image parser module, ...) would integrate together? >>> >>> In this case, I would expect platform to provide key identifier rather >>> than actual key as part of plat_get_fip_encryption_key() which is then >>> passed onto auth_decrypt() that is implementation specific to >>> cryptographic engine in similar terms as currently done for mbedTLS >>> backend. >> >> Ah I see, so plat_get_fip_encryption_key() could return either the key >> itself or a key identifier. Just like plat_get_rotpk_info() can return >> either the key or a hash of it today. However, in the case of >> plat_get_rotpk_info(), it also returns some flags indicating which one >> it is. Don't we need something similar for >> plat_get_fip_encryption_key()? How will the crypto module be able to >> tell the difference between a key and a key ID otherwise? Or would you >> expect a given crypto module backend to always use either keys or key >> IDs, but not both? >> > > It perfectly makes sense for crypto module backend to support both key > ID and actual key. But I was thinking from use-case perspective that > why would one like to expose key to the firmware if the crypto module > could better protect it. And I could come up with one use-case where > the SSK (burnt in SoC fuses) is provided as an actual key and BSSK > (accessible only to crypto module) is provided via a key ID. Yes, that makes sense to me. > So yes I agree with you to provide additional flags field along with > key buffer. Also, I think it makes sense to rename > "plat_get_fip_encryption_key()" to "plat_get_fip_enc_key_info()". Agree. >>>> I have some concerns around the generation of the initialization vectors >>>> in the encrypt_fw tool. Right now, IVs are simply a random sequence of >>>> bytes (obtained through a call to OpenSSL's RAND_bytes() API). Now, I >>>> would imagine that RAND_bytes() is typically based on a good random >>>> number generator and thus will generate different sequences every time >>>> it is called. At least, as long as it is called from the same machine >>>> every time. But what if we encrypt a new FIP bundle from a different >>>> machine, say in the context of a firmware update? Is it not possible >>>> that it might choose the same IV out of bad luck? >>>> >>>> Perhaps that's an issue left to provisioning/manufacturing time and is >>>> out of the scope here. But it worries me because AFAIU, the security of >>>> AES-GCM is critically undermined if the same nonce is used multiple >>>> times with the same key (see section 5.1.1. "Nonce reuse" in RFC 5116). >>>> If the encryption key is the SSK (rather than the BSSK) then I guess the >>>> probability is even higher, as it is shared amongst a class of devices. >>>> >>> >>> Agree that "nonce" should be unique and using a random number >>> generator available on build machine was an effort towards that. But >>> thinking about the case that you have mentioned, I think we could have >>> an optional user provided "nonce" as an input to "encrypt_fw" tool, so >>> that the user is aware to randomly generate and provide a unique >>> nonce. >> >> Yes, I like your suggestion of specifying the nonce to the tool. But I >> think it should be the default behaviour then. You mention an *optional* >> user-provided nonce, I would like to suggest we make this mandatory >> instead. We could provide an option to request the tool to generate the >> nonce, intended for development purposes. >> > > Making nonce as default and mandatory command line option seems to be > overkill for a user. It may also lead to unsafe practices of > hardcoding a nonce in Makefile, shell scripts etc. So I think we > should keep this as optional only for a narrow use-case where people > might not trust uniqueness property of RNG from multiple build > machines. I don't know... Hard-coding a nonce in the makefile is unsafe for sure but I would think that a nonce generated by the tool is also unsafe without proper management of these nonces across keys and devices, but in a much more subtle manner. I still think the nonce generation would be better left outside of the scope of this tool. > BTW, I have already added nonce command line option as part of v3 > patch-set [1]. Please have a look. > > [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2496/2..3 > >>>> Impact on memory footprint and performance >>>> ------------------------------------------ >>>> >>>> Do you know what the performance impact is when this feature is enabled >>>> in TF-A, to decrypt images at boot time? Obviously it depends on the >>>> platform and whether there is a dedicated cryptographic engine, and I >>>> suppose you cannot really get any relevant measurements out of QEMU but >>>> I would be interested if you've got any rough numbers. >>> >>> Following are measurements based on qemu for mbedTLS software library >>> based authenticated decryption: >>> >>> BL31 plain: >>> NOTICE: Load image time: 137us, size: 28KB >>> BL31 encrypted: >>> NOTICE: Load image time: 3979us, size: 28KB >>> >>> BL32 plain: >>> NOTICE: Load image time: 1791us, size: 360KB >>> BL32 encrypted: >>> NOTICE: Load image time: 36339us, size: 360KB >> >> Thanks. So it's a 29% increase for BL31 and 20% for BL32. I would have >> naively expected similar percentages, any idea why we get such a >> difference between BL31 and BL32? I am just curious. Maybe it's down to >> how the crypto algorithm/mode of operation works under the hood? > > Yes this additional increase for BL31 seems to be due to one time > initialization operations carried on first invocation of mbedTLS gcm > APIs, especially time taken to generate AES tables (see call to > aes_gen_tables() in mbedtls/library/aes.c +576). Ah I see, thanks for the explanation. Regarding the memory impact, given that it's adding quite a bit of code and data (around 9KB for BL1 and 12KB for BL2 from what you were saying in a previous email), I think we need to make this feature optional and wrap it under a build flag. Not everyone will need to encrypt firmware images, having only authentication is a valid use case as well. If I am not mistaken, your patches right now unconditionally pull the mbedTLS primitives into BL1 and BL2 (as long as TBBR is enabled of course). As a matter of fact, I am not able to build BL1 on FVP platform with your patches, presumably due to the unconditional size increase. The following build command: > make TRUSTED_BOARD_BOOT=1 ARM_ROTPK_LOCATION=devel_rsa MBEDTLS_DIR=mbedtls bl1 ... fails at link time: aarch64-linux-gnu-ld.bfd: build/fvp/release/bl1/bl1.elf section `xlat_table' will not fit in region `RAM' aarch64-linux-gnu-ld.bfd: BL1's RW section has exceeded its limit. aarch64-linux-gnu-ld.bfd: region `RAM' overflowed by 4096 bytes Makefile:889: recipe for target 'build/fvp/release/bl1/bl1.elf' failed Regards, Sandrine

5 years, 4 months

2
2
0 0

Re: [TF-A] [Question] Why are the log related macros defined in multiple of 10's

by Dan Handley

Hi > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew > via TF-A > Sent: 06 January 2020 12:34 > To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a(a)lists.trustedfirmware.org; > Sheetal Tigadoli <sheetal.tigadoli(a)broadcom.com> > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-A] [Question] Why are the log related macros defined in > multiple of 10's > > > Hi All, > > > > I wanted to understand the reason behind defining LOG_LEVEL_* macros > > as multiple of 10's, also same goes with LOG_MARKER_* macros. > > If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and > > division operation when printing the msgs to console. > > > > Please let me your thoughts on this. > > > > Link to this question on Phabricator - > > https://developer.trustedfirmware.org/T624 > > > > Thanks > > Sheetal > As Sandrine said in Phabricator, the reason was simply to leave space between the levels to allow adding intermediate levels without breaking compatibility. Compatibility was a possible concern if external tools used the log level and you only rebuilt some of the TF-A components (components could end up using different values). However, I suspect the actual level value is never emitted in practice (just the text prefix) so this may not be a real concern. > Hi Sheetal > I didn't quite get reason for the optimization from multiples of 10 to > consecutive numbers. The mod operation you refer to are assertions which will > be compiled out when DEBUG=0 or when ENABLE_ASSSERTIONS=0. Other than that > there is a single divide by 10 operation within the default implementation of > plat_log_get_prefix(). > > > If the logging utility is considered performance critical, removing the > single divide by 10 will not result in any gain. Usually the bottleneck for > logs are UART baudrates and the CPU spends most of time spinning in a wait > loop for UART to be free. Hence I don't see any need for change for log > levels macro if the intent is performance optimization. > +1. Unless there's an actual performance gain, this sounds like an unnecessary change. Dan. 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, 4 months

1
0
0 0

Re: [TF-A] [Question] Why are the log related macros defined in multiple of 10's

by Soby Mathew

On 06/01/2020 12:34, Soby Mathew via TF-A wrote: >> Hi All, >> >> I wanted to understand the reason behind defining LOG_LEVEL_* macros as >> multiple of 10's, also same goes with LOG_MARKER_* macros. >> If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and >> division operation when printing the msgs to console. >> >> Please let me your thoughts on this. >> >> Link to this question on Phabricator - >> https://developer.trustedfirmware.org/T624 >> >> Thanks >> Sheetal > > Hi Sheetal > I didn't quite get reason for the optimization from multiples of 10 to > consecutive numbers. The mod operation you refer to are assertions which > will be compiled out when DEBUG=0 or when ENABLE_ASSSERTIONS=0. Other > than that there is a single divide by 10 operation within the default > implementation of plat_log_get_prefix(). > > > If the logging utility is considered performance critical, removing the > single divide by 10 will not result in any gain. Usually the bottleneck > for logs are UART baudrates and the CPU spends most of time spinning in > a wait loop for UART to be free. Hence I don't see any need for change > for log levels macro if the intent is performance optimization. > > Best Regards > Soby Mathew > Hi Sheetal There is some discussion related to this here : https://github.com/ARM-software/tf-issues/issues/462 and see associated issues and PRs for more details. Best Regards Soby Mathew >> -- >> 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] [Question] Why are the log related macros defined in multiple of 10's

by Soby Mathew

> Hi All, > > I wanted to understand the reason behind defining LOG_LEVEL_* macros as > multiple of 10's, also same goes with LOG_MARKER_* macros. > If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and > division operation when printing the msgs to console. > > Please let me your thoughts on this. > > Link to this question on Phabricator - > https://developer.trustedfirmware.org/T624 > > Thanks > Sheetal Hi Sheetal I didn't quite get reason for the optimization from multiples of 10 to consecutive numbers. The mod operation you refer to are assertions which will be compiled out when DEBUG=0 or when ENABLE_ASSSERTIONS=0. Other than that there is a single divide by 10 operation within the default implementation of plat_log_get_prefix(). If the logging utility is considered performance critical, removing the single divide by 10 will not result in any gain. Usually the bottleneck for logs are UART baudrates and the CPU spends most of time spinning in a wait loop for UART to be free. Hence I don't see any need for change for log levels macro if the intent is performance optimization. Best Regards Soby Mathew > -- > 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

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. 9 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 13 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 9 of 9 defect(s) ** CID 353233: Control flow issues (NO_EFFECT) /plat/intel/soc/common/socfpga_sip_svc.c: 235 in is_address_in_ddr_range() ________________________________________________________________________________________________________ *** CID 353233: Control flow issues (NO_EFFECT) /plat/intel/soc/common/socfpga_sip_svc.c: 235 in is_address_in_ddr_range() 229 return false; 230 return true; 231 } 232 233 static bool is_address_in_ddr_range(uint64_t addr) 234 { >>> CID 353233: Control flow issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "addr >= 0ULL". 235 if (addr >= DRAM_BASE && addr <= DRAM_BASE + DRAM_SIZE) 236 return true; 237 238 return false; 239 } 240 ** CID 353232: Memory - corruptions (OVERRUN) /plat/rockchip/common/drivers/parameter/ddr_parameter.c: 124 in ddr_region_usage_parse() ________________________________________________________________________________________________________ *** CID 353232: Memory - corruptions (OVERRUN) /plat/rockchip/common/drivers/parameter/ddr_parameter.c: 124 in ddr_region_usage_parse() 118 * that means s-regions are all parsed yet, so finsh. 119 */ 120 if (p.ns_top[i] == p.boundary) 121 goto out; 122 123 /* s-region's base starts from previous ns-region's top */ >>> CID 353232: Memory - corruptions (OVERRUN) >>> Overrunning array "p.s_base" of 10 8-byte elements at element index 10 (byte offset 87) using index "p.s_nr" (which evaluates to 10). 124 p.s_base[p.s_nr] = p.ns_top[i]; 125 126 /* s-region's top ends with next ns-region's base */ 127 if (i + 1 < p.ns_nr) 128 p.s_top[p.s_nr] = p.ns_base[i + 1]; 129 else ** CID 353231: (DIVIDE_BY_ZERO) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 374 in mv_ddr4_dq_vref_calibration() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 380 in mv_ddr4_dq_vref_calibration() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 378 in mv_ddr4_dq_vref_calibration() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 376 in mv_ddr4_dq_vref_calibration() ________________________________________________________________________________________________________ *** CID 353231: (DIVIDE_BY_ZERO) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 374 in mv_ddr4_dq_vref_calibration() 368 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy_num); 369 vref_avg += center_vref[if_id][subphy_num]; 370 dq_vref_vec[subphy_num] = center_vref[if_id][subphy_num]; 371 vref_subphy_num++; 372 } 373 >>> CID 353231: (DIVIDE_BY_ZERO) >>> In expression "vref_avg / vref_subphy_num", division by expression "vref_subphy_num" which may be zero has undefined behavior. 374 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 375 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_START); 376 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 377 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_END); 378 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, ("final vref average %d\n", vref_avg / vref_subphy_num)); 379 /* run centralization again with optimal vref to update global structures */ /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 380 in mv_ddr4_dq_vref_calibration() 374 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 375 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_START); 376 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 377 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_END); 378 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, ("final vref average %d\n", vref_avg / vref_subphy_num)); 379 /* run centralization again with optimal vref to update global structures */ >>> CID 353231: (DIVIDE_BY_ZERO) >>> In expression "vref_avg / vref_subphy_num", division by expression "vref_subphy_num" which may be zero has undefined behavior. 380 mv_ddr4_centralization(dev_num, pbs_tap_factor, c_opt_per_bus, pbs_res_per_bus, valid_win_size, 381 TX_DIR, vref_avg / vref_subphy_num, duty_cycle); 382 } 383 384 /* return dram from vref DRAM from vref training mode */ 385 mv_ddr4_vref_training_mode_ctrl(dev_num, 0, ACCESS_TYPE_MULTICAST, 0); /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 378 in mv_ddr4_dq_vref_calibration() 372 } 373 374 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 375 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_START); 376 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 377 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_END); >>> CID 353231: (DIVIDE_BY_ZERO) >>> In expression "vref_avg / vref_subphy_num", division by expression "vref_subphy_num" which may be zero has undefined behavior. 378 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, ("final vref average %d\n", vref_avg / vref_subphy_num)); 379 /* run centralization again with optimal vref to update global structures */ 380 mv_ddr4_centralization(dev_num, pbs_tap_factor, c_opt_per_bus, pbs_res_per_bus, valid_win_size, 381 TX_DIR, vref_avg / vref_subphy_num, duty_cycle); 382 } 383 /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 376 in mv_ddr4_dq_vref_calibration() 370 dq_vref_vec[subphy_num] = center_vref[if_id][subphy_num]; 371 vref_subphy_num++; 372 } 373 374 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 375 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_START); >>> CID 353231: (DIVIDE_BY_ZERO) >>> In expression "vref_avg / vref_subphy_num", division by expression "vref_subphy_num" which may be zero has undefined behavior. 376 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 377 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_END); 378 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, ("final vref average %d\n", vref_avg / vref_subphy_num)); 379 /* run centralization again with optimal vref to update global structures */ 380 mv_ddr4_centralization(dev_num, pbs_tap_factor, c_opt_per_bus, pbs_res_per_bus, valid_win_size, 381 TX_DIR, vref_avg / vref_subphy_num, duty_cycle); ** CID 353230: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 353230: Memory - corruptions (OVERRUN) /drivers/marvell/mv_ddr/ddr3_debug.c: 1570 in run_xsb_test() 1564 if (write_type != 0) { 1565 CHECK_STATUS(ddr3_tip_ext_write 1566 (dev_num, if_id, addr, 1, 1567 xsb_test_table[seq])); 1568 } 1569 if (read_type != 0) { >>> CID 353230: Memory - corruptions (OVERRUN) >>> Overrunning array "data_read" of 1 4-byte elements by passing it to a function which accesses it at element index 7 (byte offset 31) using argument "1U". 1570 CHECK_STATUS(ddr3_tip_ext_read 1571 (dev_num, if_id, addr, 1, 1572 data_read)); 1573 } 1574 if ((read_type != 0) && (write_type != 0)) { 1575 ret_tmp = ** CID 353229: Memory - corruptions (OVERRUN) /plat/rockchip/common/drivers/parameter/ddr_parameter.c: 130 in ddr_region_usage_parse() ________________________________________________________________________________________________________ *** CID 353229: Memory - corruptions (OVERRUN) /plat/rockchip/common/drivers/parameter/ddr_parameter.c: 130 in ddr_region_usage_parse() 124 p.s_base[p.s_nr] = p.ns_top[i]; 125 126 /* s-region's top ends with next ns-region's base */ 127 if (i + 1 < p.ns_nr) 128 p.s_top[p.s_nr] = p.ns_base[i + 1]; 129 else >>> CID 353229: Memory - corruptions (OVERRUN) >>> Overrunning array "p.s_top" of 10 8-byte elements at element index 10 (byte offset 87) using index "p.s_nr" (which evaluates to 10). 130 p.s_top[p.s_nr] = p.boundary; 131 p.s_nr++; 132 } 133 out: 134 return p; ** CID 353228: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /lib/debugfs/devfip.c: 106 in get_entry() ________________________________________________________________________________________________________ *** CID 353228: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /lib/debugfs/devfip.c: 106 in get_entry() 100 } 101 102 if (n != sizeof(struct fip_entry)) { 103 return -1; 104 } 105 >>> CID 353228: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "entry->size > 9223372036854775807L" is always false regardless of the values of its operands. This occurs as the logical first operand of "||". 106 if ((entry->size > LONG_MAX) || (entry->offset_address > LONG_MAX)) { 107 return -1; 108 } 109 110 if (entry->size == 0) { 111 return 0; ** CID 353227: Parse warnings (PARSE_ERROR) /services/std_svc/spm_mm/spm_mm_xlat.c: 26 in () ________________________________________________________________________________________________________ *** CID 353227: Parse warnings (PARSE_ERROR) /services/std_svc/spm_mm/spm_mm_xlat.c: 26 in () 20 /* Place translation tables by default along with the ones used by BL31. */ 21 #ifndef PLAT_SP_IMAGE_XLAT_SECTION_NAME 22 #define PLAT_SP_IMAGE_XLAT_SECTION_NAME "xlat_table" 23 #endif 24 25 /* Allocate and initialise the translation context for the secure partitions. */ >>> CID 353227: Parse warnings (PARSE_ERROR) >>> expected a string literal 26 REGISTER_XLAT_CONTEXT2(sp, 27 PLAT_SP_IMAGE_MMAP_REGIONS, 28 PLAT_SP_IMAGE_MAX_XLAT_TABLES, 29 PLAT_VIRT_ADDR_SPACE_SIZE, PLAT_PHY_ADDR_SPACE_SIZE, 30 EL1_EL0_REGIME, PLAT_SP_IMAGE_XLAT_SECTION_NAME); 31 ** CID 353226: (VARARGS) /lib/libc/snprintf.c: 110 in snprintf() /lib/libc/snprintf.c: 93 in snprintf() /lib/libc/snprintf.c: 114 in snprintf() ________________________________________________________________________________________________________ *** CID 353226: (VARARGS) /lib/libc/snprintf.c: 110 in snprintf() 104 unum = (unsigned int)num; 105 } 106 107 unsigned_dec_print(&s, n, &chars_printed, unum); 108 break; 109 case 's': >>> CID 353226: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 110 str = va_arg(args, char *); 111 string_print(&s, n, &chars_printed, str); 112 break; 113 case 'u': 114 unum = va_arg(args, unsigned int); 115 unsigned_dec_print(&s, n, &chars_printed, unum); /lib/libc/snprintf.c: 93 in snprintf() 87 if (*fmt == '%') { 88 fmt++; 89 /* Check the format specifier. */ 90 switch (*fmt) { 91 case 'i': 92 case 'd': >>> CID 353226: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 93 num = va_arg(args, int); 94 95 if (num < 0) { 96 if (chars_printed < n) { 97 *s = '-'; 98 s++; /lib/libc/snprintf.c: 114 in snprintf() 108 break; 109 case 's': 110 str = va_arg(args, char *); 111 string_print(&s, n, &chars_printed, str); 112 break; 113 case 'u': >>> CID 353226: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 114 unum = va_arg(args, unsigned int); 115 unsigned_dec_print(&s, n, &chars_printed, unum); 116 break; 117 default: 118 /* Panic on any other format specifier. */ 119 ERROR("snprintf: specifier with ASCII code '%d' not supported.", ** CID 353225: Control flow issues (NO_EFFECT) /plat/intel/soc/common/soc/socfpga_mailbox.c: 298 in intel_mailbox_get_config_status() ________________________________________________________________________________________________________ *** CID 353225: Control flow issues (NO_EFFECT) /plat/intel/soc/common/soc/socfpga_mailbox.c: 298 in intel_mailbox_get_config_status() 292 uint32_t status, res; 293 uint32_t response[6]; 294 295 status = mailbox_send_cmd(1, cmd, NULL, 0, 0, response, 296 sizeof(response) / sizeof(response[0])); 297 >>> CID 353225: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "status < 0U". 298 if (status < 0) 299 return status; 300 301 res = response[RECONFIG_STATUS_STATE]; 302 if (res && res != MBOX_CFGSTAT_STATE_CONFIG) 303 return res; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

5 years, 4 months

1
0
0 0

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

by Alexei Fedorov

Hi Varun Could you take a look at the Nvidia driver defect reported by the Coverity scan? Regards. Alexei. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of scan-admin--- via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 03 January 2020 08:19 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware 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 352832: Uninitialized variables (UNINIT) /plat/nvidia/tegra/soc/t194/drivers/mce/nvg.c: 197 in nvg_update_ccplex_gsc() ________________________________________________________________________________________________________ *** CID 352832: Uninitialized variables (UNINIT) /plat/nvidia/tegra/soc/t194/drivers/mce/nvg.c: 197 in nvg_update_ccplex_gsc() 191 ret = EINVAL; 192 } else { 193 nvg_set_request_data((uint64_t)TEGRA_NVG_CHANNEL_UPDATE_CCPLEX_GSC, 194 (uint64_t)gsc_idx); 195 } 196 >>> CID 352832: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret". 197 return ret; 198 } 199 200 /* 201 * Cache clean operation for all CCPLEX caches. 202 */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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, 4 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 352832: Uninitialized variables (UNINIT) /plat/nvidia/tegra/soc/t194/drivers/mce/nvg.c: 197 in nvg_update_ccplex_gsc() ________________________________________________________________________________________________________ *** CID 352832: Uninitialized variables (UNINIT) /plat/nvidia/tegra/soc/t194/drivers/mce/nvg.c: 197 in nvg_update_ccplex_gsc() 191 ret = EINVAL; 192 } else { 193 nvg_set_request_data((uint64_t)TEGRA_NVG_CHANNEL_UPDATE_CCPLEX_GSC, 194 (uint64_t)gsc_idx); 195 } 196 >>> CID 352832: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret". 197 return ret; 198 } 199 200 /* 201 * Cache clean operation for all CCPLEX caches. 202 */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

5 years, 4 months

1
0
0 0

Re: [TF-A] [Question] Why are the log related macros defined in multiple of 10's

by Olivier Deprez

Hi Sheetal, Your remark/question makes sense. The original requirement is described here: https://github.com/ARM-software/tf-issues/issues/232 We may get further update from Dan, but I sense this was to provision for intermediate log levels (as stated by Sandrine on phabricator). Will you be able to submit a patch for this? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Sheetal Tigadoli via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 20 December 2019 15:48 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] [Question] Why are the log related macros defined in multiple of 10's Hi All, I wanted to understand the reason behind defining LOG_LEVEL_* macros as multiple of 10's, also same goes with LOG_MARKER_* macros. If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and division operation when printing the msgs to console. Please let me your thoughts on this. Link to this question on Phabricator - https://developer.trustedfirmware.org/T624 Thanks Sheetal -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 4 months

2
1
0 0

[Question] Why are the log related macros defined in multiple of 10's

by Sheetal Tigadoli

Hi All, I wanted to understand the reason behind defining LOG_LEVEL_* macros as multiple of 10's, also same goes with LOG_MARKER_* macros. If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and division operation when printing the msgs to console. Please let me your thoughts on this. Link to this question on Phabricator - https://developer.trustedfirmware.org/T624 Thanks Sheetal

5 years, 4 months

1
0
0 0

[Question] Why are the log related macros defined in multiple of 10's

by Sheetal Tigadoli

Hi All, I wanted to understand the reason behind defining LOG_LEVEL_* macros as multiple of 10's, also same goes with LOG_MARKER_* macros. If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and division operation when printing the msgs to console. Please let me your thoughts on this. Link to this question on Phabricator - https://developer.trustedfirmware.org/T624 Thanks Sheetal

5 years, 4 months

1
0
0 0

Re: [TF-A] RPi4 and CPU hotplugging

by Soby Mathew

> > Subject: [PATCH] rpi3/4: Add support for offlining CPUs > From: Jan Kiszka <jan.kiszka(a)siemens.com> > > The hooks were populated but the power down left the CPU in limbo-land. > What we need to do - until there is a way to actually power off - is to > turn off the MMU and enter the spinning loop as if we were cold-booted. > This allows the on-call to pick up the CPU again. > > Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com> > --- > plat/rpi/common/rpi3_pm.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/plat/rpi/common/rpi3_pm.c b/plat/rpi/common/rpi3_pm.c > index 8c2d070c4..2a6bf076b 100644 > --- a/plat/rpi/common/rpi3_pm.c > +++ b/plat/rpi/common/rpi3_pm.c > @@ -123,6 +123,15 @@ static void rpi3_pwr_domain_off(const psci_power_state_t *target_state) > #endif > } > > +void __dead2 plat_secondary_cold_boot_setup(void); > + > +static void __dead2 > +rpi3_pwr_domain_pwr_down_wfi(const psci_power_state_t *target_state) > +{ > + disable_mmu_el3(); > + plat_secondary_cold_boot_setup(); > +} > + > /******************************************************************************* > * Platform handler called when a power domain is about to be turned on. The > * mpidr determines the CPU to be turned on. > @@ -224,6 +233,7 @@ static void __dead2 rpi3_system_off(void) > static const plat_psci_ops_t plat_rpi3_psci_pm_ops = { > .cpu_standby = rpi3_cpu_standby, > .pwr_domain_off = rpi3_pwr_domain_off, > + .pwr_domain_pwr_down_wfi = rpi3_pwr_domain_pwr_down_wfi, > .pwr_domain_on = rpi3_pwr_domain_on, > .pwr_domain_on_finish = rpi3_pwr_domain_on_finish, > .system_off = rpi3_system_off, > -- > 2.16.4 > Hi Jan, I have put in a suggestion for the change. Basically, if you are able to do a `reset` before spinning in `plat_secondary_cold_boot_setup()`, that would be ideal. Also, if `plat_secondary_cold_boot_setup()` can trap the primary CPU as well if it were to be offlined, then I think your changes should be good. Best Regards Soby Mathew

5 years, 5 months

2
2
0 0

Re: [TF-A] About disable gic cpuif in psci suspend or off

by Soby Mathew

Hi Jisheng, This is due to the power management requirement of GICv3. In section 7.1 of GICv3 specification : https://static.docs.arm.com/ihi0069/c/IHI0069C_gic_architecture_specificati… It says the that " Before powering down the CPU interface and the PE when the Redistributor is powered up, software must put the interface between the CPU interface and the Redistributor into the quiescent state or the system will become UNPREDICTABLE". In order to put the Redistributor in a quiescent state, all the group enables in CPU interface must be disabled , otherwise "setting GICR_WAKER.ProcessorSleep to 1 when the physical group enables in the CPU interface are set to 1 results in UNPREDICTABLE behavior." Hope that clarifies. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Jisheng > Zhang via TF-A > Sent: 05 December 2019 10:31 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] About disable gic cpuif in psci suspend or off > > Hi, > > In ATF-A, I usually see below code in psci suspend or off code path: > > /* Prevent interrupts from spuriously waking up this cpu */ > plat_arm_gic_cpuif_disable(); > > But per my understanding, before calling psci_suspend(), the NW, e.g linux > kernel has disabled all interrupts from cpu level, so here preventing interrupt is > to prevent the interrupts from secure world? > > Another question is: for Cortex A55, this is not necessary. Because > CA55 TRM says when the core_pwrdn_en bit is set, executing WFI > automatically masks all interrupts and wake-up events in the core. Am I right? > > Thanks in advance > -- > 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] SMC to intentionally trigger a panic in TF-A

by Joanna Farley

Julius, On the subject of DebugFS's purpose it was envisages and is today as Sandrine describes as a debug build only capability. Saying that though there has been some early thoughts that it could evolve into a Secure Debug feature where this type of capability or something like it is always on requiring debug certificates for authenticated access. This is something very much for a possible future evolution and is not in the patches available today. We would welcome any thoughts on such an evolution in this space. Joanna On 13/12/2019, 13:01, "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, OK, in that case I can see that a solution based on TF-A's DebugFS interface might not be desirable. Indeed, our original intention was to make the whole DebugFS system a debug-only feature (hence its name!). As such, I agree that it is likely not to get the same level of scrutiny and testing as other features intended for production systems. One of the main use cases we have in mind for DebugFS is, being able to peek and poke into the firmware for testing purposes. Today, when doing functional testing from the normal world (for example, using TF-A Tests), we are limited to what's exposed through the SMC interface. And even then, we have limited visibility on what really happened in the firmware, as we can only deduce so much from the SMC return value(s). DebugFS could be used to bridge this gap, by providing a side channel for getting internal firmware state information. Going back to the SMC-based solution then, I am not quite convinced SYSTEM_RESET2 is the right interface for intentionally triggering a panic in TF-A. I think the semantics do not quite match. If anything, a firmware crash seems more like a shutdown operation to me rather than a reset (we don't recover from a firmware crash). I am not even sure we should look into the PSCI SMC range, as it's not a power-management operation. Julius, you wrote: > It's the same problem that the SMC/PSCI spec and the TF repository layout is only designed to deal with generic vs. SoC-vendor-specific differentiation. If the normal world OS needs a feature, we can only make it generic or duplicate it across all vendors running that OS. So it sounds like it's not the first time that you hit this issue, is it? Do you have any other example of Normal World OS feature you would have liked to expose through a generic SMC interface? I am wondering whether this could help choosing the right SMC range, if we can identify some common criteria among a set of such features. Regards, Sandrine -- 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] Design proposal: Property Access Layer

by Abhishek Pandit

Hi Louis, The term PAL is also used for platform abstraction layer so it "could" be confusing to have this being used for something different. Not necessarily suggesting to change anything but it might be worth considering this aspect. Thanks, Abhishek -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Louis Mayencourt via TF-A Sent: 19 November 2019 13:40 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Design proposal: Property Access Layer Hi everyone, Please let me introduce the `Property Access Layer` prototype: The Property Access Layer (PAL) is an abstraction layer for platform specific data, allowing a "property" to be queried and a value retrieved without the requesting entity knowing what backing store is being used to hold the data. It is used to bridge new and old ways of providing platform-specific data: Today, information like the Chain of Trust is held within several, nested platform-defined tables. In the future, it may be provided as part of a device tree blob, along with the information about images to load. Introducing this abstraction layer will make migration easier and will preserve functionality for platforms that cannot / don't want to use device tree. Please have a look at the patches: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2559/1 Regards, Louis 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. -- 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

Re: [TF-A] SMC to intentionally trigger a panic in TF-A

by Sandrine Bailleux

Hi Julius, OK, in that case I can see that a solution based on TF-A's DebugFS interface might not be desirable. Indeed, our original intention was to make the whole DebugFS system a debug-only feature (hence its name!). As such, I agree that it is likely not to get the same level of scrutiny and testing as other features intended for production systems. One of the main use cases we have in mind for DebugFS is, being able to peek and poke into the firmware for testing purposes. Today, when doing functional testing from the normal world (for example, using TF-A Tests), we are limited to what's exposed through the SMC interface. And even then, we have limited visibility on what really happened in the firmware, as we can only deduce so much from the SMC return value(s). DebugFS could be used to bridge this gap, by providing a side channel for getting internal firmware state information. Going back to the SMC-based solution then, I am not quite convinced SYSTEM_RESET2 is the right interface for intentionally triggering a panic in TF-A. I think the semantics do not quite match. If anything, a firmware crash seems more like a shutdown operation to me rather than a reset (we don't recover from a firmware crash). I am not even sure we should look into the PSCI SMC range, as it's not a power-management operation. Julius, you wrote: > It's the same problem that the SMC/PSCI spec and the TF repository layout is only designed to deal with generic vs. SoC-vendor-specific differentiation. If the normal world OS needs a feature, we can only make it generic or duplicate it across all vendors running that OS. So it sounds like it's not the first time that you hit this issue, is it? Do you have any other example of Normal World OS feature you would have liked to expose through a generic SMC interface? I am wondering whether this could help choosing the right SMC range, if we can identify some common criteria among a set of such features. Regards, Sandrine

5 years, 5 months

1
0
0 0

Re: [TF-A] [RFC] BL2 MTD frameworks

by Olivier Deprez

Hi, Thanks George and Lionel for your answers. Following up and closing on this, the approach used in mentioned patch (https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283) looks ok provided it should now build on all platforms. The original concern was about api breakage in the generic code, and that there might exist inconsistencies among platforms (ones depending on a 32b offset, others on 64 bits). Changing the generic seek api offset parameter from ssize_t to signed long long everywhere as a default makes it better compliant to using larger density storage chips in the long term. This is fine as long as it also still support older lower density chips. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 08 November 2019 18:34 To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] [RFC] BL2 MTD frameworks Hi, Just to clarify a little bit more. There is no link here about a 32/64 bit architecture. The content of this change is to take care about new memory introduce (mtd devices) that are not based on size * LBA (where LBA=512) but size * LBA where (LBA=1) and in such case, the size could exceed the 4GB. It is not platform dependent and not architecture dependent, it's link to the connected MTD device only. I'm not sure that a new type is useful except if you want a type is modified regarding a platform flag such as USE_LARGE_MTD_DEVICE. Hope it's more clear. BR, Lionel On 11/5/19 3:20 PM, Gyorgy Szing via TF-A wrote: > Hi, > > I did not investigated all the details so what stays below may contain mistakes, but still I would like to add some comments. > > "using a type for the offset" > The type we use for this purpose seems to be a configuration parameter for the IO layer as it depends on the upper layer being used with the IO library. For example libc uses "long int" to specify the file offset (fseek, ftell), using a different type while running below libc does not seem to be a good idea. > The best option seems to be to define a type like (as Olivier mentioned) lib/zlib does. How we set this configuration parameter during the build is a question. The offset type could be dictated by the platform, the architecture (aarch32 or aarch64) or by the user. Which one is worth to implement needs investigation. > > If it is a good idea to use the same name "off_t" as zlib uses (or even the same type) is be questionable. It may give us more flexibility if we use a dedicated name, and the configuration maps the IO type to the one used by the upper layer. > > "32 bit backward compatibility" > Another angle worth to consider is the 32/64 bit compatibility. I.e.: newlib can use 64 bit offsets even on 32 bit architectures, and they use some wrappers to maintain binary compatibility with old builds. When built in a compatible manner, functions using the standardized names use 32 bit wide offsets and call the real 64 bit implementation as a wrapper. > To solve compatibility issues we could use a similar pattern. Instead of changing the existing function, we could add a new one (i.e. seek64). Then new 64 bit aware code could use the new function if available, and legacy code could call the old one. Longer term it is an option to deprecate the 32 bit version. > > "use stdint.h types" > And a finally: when selecting the type used for off_t (or whatever we are going to call it) please consider using stdint.h types (i.e. int_fast64_t). > > /George > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Olivier Deprez via TF-A > Sent: 25 October 2019 14:42 > To: tf-a(a)lists.trustedfirmware.org; Lionel DEBIEVE <lionel.debieve(a)st.com> > Subject: Re: [TF-A] [RFC] BL2 MTD frameworks > > Hi Lionel, > > On https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283 > I'm extending the discussion to the TF-A ML, to get people's opinion. > > The idea is to extend the io_seek offset parameter from ssize_t to unsigned long long. > There are indeed good reasons for that as flash storage density grows over the years. > > Now on the change, the struct io_dev_funcs seek function pointer is generic for the whole codebase / drivers. > So currently the change breaks the builds for at least rcar, stratix10 (did not check others from that point). > > An alternative is defining offset as an off_t type which is ssize_t by default, and only unsigned long long based on the platform (using _FILE_OFFSET_BITS=64). This pattern actually already exists in lib/zlib > > Other option is to change the generic prototype for all platform drivers (then we ensure all platforms build and supply platform patches). > > What do ML people think? > > Regards, > Olivier. > > > > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 18 October 2019 17:26 > To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > Subject: [TF-A] [RFC] BL2 MTD frameworks > > Hello Maintainers, > > I've sent a patch series around MTD framework management into BL2 stage (cf https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283). > > This patch series will add following frameworks: > > - a raw NAND framework implementation to support SLC NAND devices. Current implementation is limited to read operations without ECC corrections. Overrides are available to use hardware ECC from controller or low-level drivers. It also supports ONFI detection management but this can also be disabled or overridden by platform specific data. > - a SPI-MEM framework (inspired from kernel/u-boot implementation) that encapsulates all SPI operations to SPI low level drivers. > - a SPI-NAND framework based on SPI-MEM to support SPI NAND devices. This framework is also limited to the read operation. It uses single command, address and data bus width as legacy but can be overridden by platform. > - a SPI-NOR framework based on SPI-MEM to manage SPI NOR devices. It is also limited to read operations using single command, address and data bus width as legacy (override still possible by platform). The framework embeds some specific implementations for manufacturers specific behavior in case of quad mode configuration activation. > > This patch series also includes: > > - a new io_mtd interface to manage a generic access to all these frameworks. > - a NAND core driver that accesses independently to raw NAND or SPI-NAND framework. This core driver requires a scratch buffer defined by platform to manage unaligned pages (could be defined to 0 in case of aligned page) and limits access to a single NAND instance management. > - a complete integration is available based on STM32MP1 platform. > > Tests have been performed with the following devices: > > SLC NAND: > - Micron MT29F8G08ABACAH4 (ONFI) > - Micron MT29F8G16ABACAH4 (ONFI) > - Toshiba TH58NVG3S0HTAI0 (Non ONFI) > - Toshiba TC58BVG1S3HTAI0 (On die ECC) > > SPI NOR: > - Macronix MX25L51245G > - Cypress/Spansion S25FL512 > - Micron n25q512ax3 > > SPI-NAND: > - Micron MT29F2G01ABAGD > > Waiting for your comments. > > Best regards, Lionel > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > 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. -- 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] psci shutdown do not follow graceful power off sequence

by Andreas Färber

Hi S*deeps, Am 10.12.19 um 16:08 schrieb Sudeep Holla via TF-A: > The more we discuss, I think we will get to know all sorts of CENH(as you put) > are done all over the place and expecting system is work just fine even > when lots of interface/contracts are broken is just .....(fill your own word :)) > > I promise not to discuss these CENH any further after this email :) > > On Tue, Dec 10, 2019 at 03:59:01PM +0530, Sandeep Tripathy wrote: >> Hi Sudeep, >> >> On Mon, Dec 9, 2019 at 10:40 PM Sudeep Holla <sudeep.holla(a)arm.com> wrote: >>> >>> The application has to terminate cleanly when SIGTERM is sent(may be using >>> appropriate handler. And can intimate the same to the consumers so that they >>> can consume the data before it's lost. >> The DDR is not powered off ever in this scenario. So when to/how to consume >> the log is up to the (consumer) application design. > > CENH#1 > >> Assume its an incrementing log ie. after reboot this (producer) master again >> will continue to dump more records on to it. > > CENH#2 > > (I see the roles being exchanged, OS was slave + producer and not sure > what you are referring has master above. Anyways use KDUMP and features > like that if you need RAM dump for portions of memory given to the kernel. Sorry to barge in, but it sounds like you're not quite understanding each other in this ever-growing thread: Sandeep said his use case was a SmartNIC, so I assume the logging direction is from SoC on the SmartNIC to host SoC via PCIe? Think dmesg-like logs, from one host for another - I fail to see how Sudeep's kdump suggestion could help here. But maybe I'm not understanding properly, in which case I'll just blame your abstract master/slave discussions. :) To me and my ignorance however it sounds like this use case has nothing really to do with shutdown? If the log producer does not flush their logs after say each line ending, then also without shutdown you have no guarantee of the logs reaching the consumer in a timely manner through all the producer's caches, no? Think of watchdogs, power loss or other irregular resets that PSCI can do nothing about. Especially for logs, those error conditions would be the most important to receive data of. Cheers, Andreas >> How would you suggest to handle this. In this case both producer and >> consumer deliberately asked for coherent memory so why it should also >> consider a possible data loss due to platforms not giving the coherency >> because it will add some time to flush the core caches. > > CENH#3, not sure if such flexibility should be given to applications. > >> If they get non-cached(coherent) memory range they don't have to do anything >> isn't it ? > > Applications must not try that, kernel mostly provides cached memory from > it's memory allocator. I get a sense that this is some magic pre-allocated > memory that is either reserved or taken out of kernel memory, but the > application (along with its driver) maps it coherent in some magic way. > > -- > Regards, > Sudeep > -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

5 years, 5 months

3
2
0 0

Re: [TF-A] RPi4 and CPU hotplugging

by Andreas Färber

Hi Andre, Am 09.12.19 um 11:08 schrieb Andre Przywara via TF-A: > On Mon, 9 Dec 2019 08:41:47 +0100 > Jan Kiszka <jan.kiszka(a)web.de> wrote: >> How should we continue with the patch below? > > If you want to go into the lion's den that is gerrit, please feel free to submit this. Shouldn't be too hard for a single patch. Otherwise I need to look into some RPi4 TF-A stuff this week anyway, so could pick up your patch as well. [...] >> Subject: [PATCH] rpi3/4: Add support for offlining CPUs Seeing the "rpi3/4" here again: It's been some time since I pitched TF-A to the Foundation for RPi4 in vein, and my 2.1 based RPi3 test setup broke with some firmware update. Not seeing any message from Matthias here yet, are you aware that U-Boot has combined rpi3 and rpi4 targets into one? Are you looking into combining the PLAT=rpi{3,4} TF-A targets, too? We're targeting to use a single Linux image for both, so needing two different TF-A binaries would make TF-A adoption more difficult for us. Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

5 years, 5 months

2
2
0 0

Re: [TF-A] psci shutdown do not follow graceful power off sequence

by Dan Handley

Hi Sandeep (I accidentally dropped the TF-A list in my last reply - now re-adding). > -----Original Message----- > From: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com> > Sent: 05 December 2019 17:17 > > On Thu, Dec 5, 2019 at 9:54 PM Dan Handley <Dan.Handley(a)arm.com> wrote: > > > > Hi Sandeep > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > > > Sandeep Tripathy via TF-A > > > Sent: 05 December 2019 12:00 > > > > > > My query is more on the spec. > > > The OS (eg: linux) and atf and psci spec seem to have assumed that > > > it is managing an independent system or managing 'all' the masters > > > in a coherent domain. > > > What other > > > reason could possibly encourage to not to follow a shutdown sequence. > > > > > Do you mean "to not follow a *graceful* shutdown sequence"? > Yes, exactly. Thanks! > > If so I can think of 3 reasons: > > 1. It's much slower than a non-graceful shutdown. > But this is certainly not a concern for smaller embedded systems. True, but TF-A tries to be a reference for all systems. > > 2. There is no observable difference between a graceful and non-graceful > > shutdown from the calling OS's point of view. The OS presumably has no > > knowledge of other masters it does not manage. > > Can CCN state machine go bad because one participating entity just goes off > without marking its exit ? > Please note I have not seen the issue and it is my assumption. > It depends on the interconnect. Arm interconnects designed for pre-v8.2 systems required explicit programming to take the master our of the coherency domain. Arm interconnects for v8.2+ systems do this automatically via hardware system coherency signals. The TF-A off/reset platform interfaces have provision to do this programming if necessary, but only for the running cluster, which is another reason not to use these PSCI functions in this scenario. > > 3. It's hard for firmware to implement in the multicore situation. > Agree. It is complex to initiate and ensure 'other cores' power down in > firmware. > > > > I haven't yet seen a reason why SYSTEM_SUSPEND won't work instead. > > > I think you are suggesting to use psci system suspend hook in reboot /power > off path Or use system suspend from the OS itself ? Should work. > I'm suggesting to just do a normal SYSTEM_SUSPEND (suspend to RAM) from the OS. > @Sudeep, I agree alternate approaches to solve data loss problem works and > may be those are the best suited. > The past thread[1] is somewhat related but diverged in multiple directions. > I wanted to know and focus the above 3 points especially point 2. Regards Dan. 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, 5 months

3
14
0 0

RPi4 and CPU hotplugging

by Jan Kiszka

Hi Andre, I'm trying to get CPU offlining work for Linux on the RPi4. In fact, this is working already with current ATF master and the Raspberry kernel 4.19.85. Not it would be "nice" if onlining worked as well: [ 94.959294] CPU1: shutdown [ 94.959311] psci: CPU1 killed. [ 106.750960] CPU1: failed to come online [ 106.755425] CPU1: failed in unknown state : 0x0 Is this a known limitation? Or am I using the wrong kernel (obviously, it's a downstream one ;) )? Thanks, Jan PS: Current RPi firmware requires an explicit "armstub=armstub8.bin" in config.txt, no automatic pickup.

5 years, 5 months

3
6
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Sandrine Bailleux

Hi Sumit, Thanks for your answer. On 12/2/19 2:22 PM, Sumit Garg via TF-A wrote: > First of all, the authenticated encryption framework for FIP payloads > allows for algorithm parameter to be passed in the header (see struct > fip_toc_dec_data here [1]). So it should be easy to add support for > CCM algorithm too. > > Now coming on to additional reason to choose AES-GCM only (apart from > reasons that you have already mentioned) being: > - Currently mbedTLS only exposes partial decryption APIs for GCM > (mbedtls_gcm_starts(), mbedtls_gcm_update() and mbedtls_gcm_finish()) > but not CCM. And we need to rely on stack based partial decryption > approach (see gcm_decrypt() here [2]) as I think we can't afford large > buffers for both encrypted and plain firmware image. > > [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/2/inclu… > [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2494/2/drive… I see, that makes sense to me. >> Also, I am still trying to get my head around how this would integrate >> with a cryptographic engine where the key does not leave the chip. I can >> imagine that we could get the address of the encrypted firmware image >> from the FIP, pass that to a cryptographic engine, request it to decrypt >> it and store the result somewhere in Trusted RAM. In this case, we >> wouldn't call plat_get_fip_encryption_key(). Do you have any idea how we >> would pull this off? Like how the different modules (IO layer, crypto >> module, image parser module, ...) would integrate together? > > In this case, I would expect platform to provide key identifier rather > than actual key as part of plat_get_fip_encryption_key() which is then > passed onto auth_decrypt() that is implementation specific to > cryptographic engine in similar terms as currently done for mbedTLS > backend. Ah I see, so plat_get_fip_encryption_key() could return either the key itself or a key identifier. Just like plat_get_rotpk_info() can return either the key or a hash of it today. However, in the case of plat_get_rotpk_info(), it also returns some flags indicating which one it is. Don't we need something similar for plat_get_fip_encryption_key()? How will the crypto module be able to tell the difference between a key and a key ID otherwise? Or would you expect a given crypto module backend to always use either keys or key IDs, but not both? >> I have some concerns around the generation of the initialization vectors >> in the encrypt_fw tool. Right now, IVs are simply a random sequence of >> bytes (obtained through a call to OpenSSL's RAND_bytes() API). Now, I >> would imagine that RAND_bytes() is typically based on a good random >> number generator and thus will generate different sequences every time >> it is called. At least, as long as it is called from the same machine >> every time. But what if we encrypt a new FIP bundle from a different >> machine, say in the context of a firmware update? Is it not possible >> that it might choose the same IV out of bad luck? >> >> Perhaps that's an issue left to provisioning/manufacturing time and is >> out of the scope here. But it worries me because AFAIU, the security of >> AES-GCM is critically undermined if the same nonce is used multiple >> times with the same key (see section 5.1.1. "Nonce reuse" in RFC 5116). >> If the encryption key is the SSK (rather than the BSSK) then I guess the >> probability is even higher, as it is shared amongst a class of devices. >> > > Agree that "nonce" should be unique and using a random number > generator available on build machine was an effort towards that. But > thinking about the case that you have mentioned, I think we could have > an optional user provided "nonce" as an input to "encrypt_fw" tool, so > that the user is aware to randomly generate and provide a unique > nonce. Yes, I like your suggestion of specifying the nonce to the tool. But I think it should be the default behaviour then. You mention an *optional* user-provided nonce, I would like to suggest we make this mandatory instead. We could provide an option to request the tool to generate the nonce, intended for development purposes. >> Impact on memory footprint and performance >> ------------------------------------------ >> >> Do you know what the performance impact is when this feature is enabled >> in TF-A, to decrypt images at boot time? Obviously it depends on the >> platform and whether there is a dedicated cryptographic engine, and I >> suppose you cannot really get any relevant measurements out of QEMU but >> I would be interested if you've got any rough numbers. > > Following are measurements based on qemu for mbedTLS software library > based authenticated decryption: > > BL31 plain: > NOTICE: Load image time: 137us, size: 28KB > BL31 encrypted: > NOTICE: Load image time: 3979us, size: 28KB > > BL32 plain: > NOTICE: Load image time: 1791us, size: 360KB > BL32 encrypted: > NOTICE: Load image time: 36339us, size: 360KB Thanks. So it's a 29% increase for BL31 and 20% for BL32. I would have naively expected similar percentages, any idea why we get such a difference between BL31 and BL32? I am just curious. Maybe it's down to how the crypto algorithm/mode of operation works under the hood? > Following is the patch I used to take measurements in case someone is > interested to try it out on actual platform: > > diff --git a/common/bl_common.c b/common/bl_common.c > index e6f9802..d7303d2 100644 > --- a/common/bl_common.c > +++ b/common/bl_common.c > @@ -148,6 +148,7 @@ static int load_auth_image_internal(unsigned int image_id, > int is_parent_image) > { > int rc; > + unsigned long int ticks; > > #if TRUSTED_BOARD_BOOT > if (dyn_is_auth_disabled() == 0) { > @@ -164,11 +165,16 @@ static int load_auth_image_internal(unsigned int image_id, > } > #endif /* TRUSTED_BOARD_BOOT */ > > + ticks = read_cntpct_el0(); > /* Load the image */ > rc = load_image(image_id, image_data); > if (rc != 0) { > return rc; > } > +#define SYS_COUNTER_FREQ_IN_TICKS ((1000 * 1000 * 1000) / 16) > + NOTICE("Load image time: %ldus, size: %dKB\n", > + (read_cntpct_el0() - ticks) * 1000000 / > SYS_COUNTER_FREQ_IN_TICKS, > + image_data->image_size / 1024); > > #if TRUSTED_BOARD_BOOT > if (dyn_is_auth_disabled() == 0) { > >> >> And what's the memory footprint impact? IIUC, AES-GCM almost does not >> inflate the size of the data it encrypts. The size of the ciphertext >> seems to be the same as the plaintext + the size of the authentication >> tag. So I guess there's no real impact on flash storage and Trusted RAM >> usage to hold decrypted firmware. But what about the mbedTLS primitives >> to decrypt the images? How much code and data does this add? > > Following is my analysis on code and data increase due to mbedTLS primitives: > > Binary size: > ========= > > $ ls -lh build/qemu/release/*.bin > -rwxrwxr-x 1 sumit sumit 58K Dec 2 12:53 build/qemu/release/bl1.bin > -rwxrwxr-x 1 sumit sumit 66K Dec 2 12:53 build/qemu/release/bl2.bin > -rwxrwxr-x 1 sumit sumit 29K Dec 2 12:53 build/qemu/release/bl31.bin > -rw-rw-r-- 1 sumit sumit 2.5M Dec 2 12:53 build/qemu/release/fip.bin > -rw-rw-r-- 1 sumit sumit 32 Dec 2 12:53 build/qemu/release/rotpk_sha256.bin > > After importing mbedTLS primitives to support AES-GCM algo: > > $ ls -lh build/qemu/release/*.bin > -rwxrwxr-x 1 sumit sumit 67K Dec 2 12:56 build/qemu/release/bl1.bin > -rwxrwxr-x 1 sumit sumit 78K Dec 2 12:56 build/qemu/release/bl2.bin > -rwxrwxr-x 1 sumit sumit 29K Dec 2 12:56 build/qemu/release/bl31.bin > -rw-rw-r-- 1 sumit sumit 2.5M Dec 2 12:56 build/qemu/release/fip.bin > -rw-rw-r-- 1 sumit sumit 32 Dec 2 12:53 build/qemu/release/rotpk_sha256.bin > > Stack and heap: Works fine with default allocations on qemu. > ============ OK thanks. >> encrypt_fw tool >> --------------- >> >> We have some floating ideas around re-implementing the tools (fiptool, >> certtool) in a scripting language (possibly python) in the future and >> also doing a better job at sharing a common description of the list of >> images to boot/authenticate between the firmware and the host tools. But >> we're not there yet, so I agree that implementing this new tool in C >> from the same "mold" as fiptool and certtool is what makes the most >> sense today. It's just another tool we will have to rework if and when >> we get there. > > Sounds like a good idea to have these tools being python based. BTW, we noticed some copyright headers attributed to both Arm and Linaro and pre-dating year 2019, e.g. in https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2496/3/tools… : * Copyright (c) 2015, ARM Limited and Contributors. All rights reserved. * Copyright (c) 2019, Linaro Limited I am guessing this is because this tool was derived from the existing cert_create tool code, is that right? >> I did not understand why this new tool needs to know what image it is >> encrypting. For example, one possible invocation could be: >> >> tools/encrypt_fw/encrypt_fw \ >> -k 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef \ >> --soc-fw bl31.bin \ >> --soc-fw-enc bl31_enc.bin \ >> --tos-fw bl32.bin \ >> --tos-fw-enc bl32_enc.bin >> >> Why not invoking the tool once per image instead? As in: >> >> encrypt_fw -k key -in ifile -out ofile >> >> for BL31, then for BL32? Does the tool do anything different based on >> the type of image it receives? > > "encrypt_fw" tool doesn't infer anything based on image type but image > types were added for more user visibility and ease of use as follows: > - Provides the capability to encrypt multiple firmwares on single invocation. I am not really convinced that this is a useful feature. I would rather have an external script (or the build system) invoking the tool multiple times, once per firmware image. Putting that complexity in the tool itself seems unnecessary to me. Also, it makes the tool TBBR specific, as it has to know the list of images it's allowed to encrypt. Unfortunately, we already have this TBBR knowledge embedded into the fiptool/cert_create tool today but we would like to change that in the future. It does not scale well with new images or alternative chains of trust. > - Restricts usage of tool for FIP payloads only. Why would we want that? > - Better align with Makefile framework to build command line args > while building different images and finally invoke tool at once before > creating FIP payload. Could we not invoke the tool for each image as we go along? As in, we build BL31 and just after we generate the encrypted version of it. Then we build BL32 and its encrypted version. And so on. While we do that, we build the fiptool command line that will indeed put all the encrypted images in the final FIP image. How does that sound? Regards, Sandrine

5 years, 5 months

2
1
0 0

Re: [TF-A] psci shutdown do not follow graceful power off sequence

by Sudeep Holla

On Thu, Dec 05, 2019 at 10:47:14PM +0530, Sandeep Tripathy wrote: > On Thu, Dec 5, 2019 at 9:54 PM Dan Handley <Dan.Handley(a)arm.com> wrote: > > > > Hi Sandeep > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > > > Tripathy via TF-A > > > Sent: 05 December 2019 12:00 > > > > > > My query is more on the spec. > > > The OS (eg: linux) and atf and psci spec seem to have assumed that it is > > > managing an independent system or managing 'all' the masters in a coherent > > > domain. > > > What other > > > reason could possibly encourage to not to follow a shutdown sequence. > > > > > Do you mean "to not follow a *graceful* shutdown sequence"? > Yes, exactly. Thanks! > If so I can think of 3 reasons: > > 1. It's much slower than a non-graceful shutdown. > But this is certainly not a concern for smaller embedded systems. But we are talking about generic solution here, aren't we ? If so, it remains concern. [..] > I think you are suggesting to use psci system suspend hook in reboot > /power off path Or use system suspend from the OS itself ? Should work. > Just suspend, don't try to use PSCI SYSTEM_SUSPEND in reboot/poweroff path, not at-least in the generic code. If you think it works fine to address your issue, you can use it in your custom solution :) > @Sudeep, I agree alternate approaches to solve data loss problem works > and may be those are the best suited. No, the data loss issue had more open questions and I haven't understood the solution you have there. > The past thread[1] is somewhat related but diverged in multiple directions. OK, details again ? -- Regards, Sudeep

5 years, 5 months

1
0
0 0

Re: [TF-A] SMC to intentionally trigger a panic in TF-A

by Sandrine Bailleux

Hi Julius, As you were mentioning that the Linux kernel uses /proc/sysrq-trigger for a similar purpose, I was wondering whether you'd be open to a solution based on a "DebugFS" entry. As you may have seen on the mailing list, Olivier posted a proposal for introducing a firmware debug interface, which has many similarities to how /proc or /sys works in the kernel world: https://lists.trustedfirmware.org/pipermail/tf-a/2019-October/000120.html TF-A patches for this feature are up for review right now and Olivier has also posted some TF-A Tests patches that demonstrate how this can be used from normal world. In addition, we are also working on a Linux driver for this. As you can imagine, DebugFS uses an SMC interface under the hood (currently allocated in the SiP range). But being an abstraction over the SMC layer, which specific SMC function ID is used does not matter so much and it does not need to be standardized by any Arm specification. You'd need to mandate all Chrome OS devices to have this DebugFS entry in the firmware but the backend could vary from platform to platform. Would that suit your use case? Regards, Sandrine 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, 5 months

2
1
0 0

Build config tool

by Balint Dobszay

Hi All, In TF-A we have a large set of build options (over 90). Dependency and incompatibility checks for these are currently done in the Makefile system. This can be hard to follow and difficult to maintain. We are investigating if there is a better way to describe the build options in a structured way, handle the dependencies/relations between them, and provide a more user-friendly configuration interface. A possible good solution for this is Kconfig, more specifically a Python implementation called Kconfiglib [1]. We plan to do more prototyping work in this area. Any feedback or comments on this topic are welcome. Regards, Balint [1] https://github.com/ulfalizer/Kconfiglib

5 years, 5 months

1
0
0 0

Re: [TF-A] psci shutdown do not follow graceful power off sequence

by Sudeep Holla

On Tue, Dec 3, 2019 at 4:58 PM Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi, > system shutdown or system reset PSCI calls are invoked by the last > core in the system. PSCI lib does not do cache flush for the last core > /cluster and does not follow the core / cluster power down sequence. > This may cause issue in a system if the system is not standalone one > ie if the system is a slave or node in a bigger system with other > coherent masters/PEs. > I am not sure if system off/reset is the right API to call in such a setup. > Please suggest if the PSCI spec expected 'shutdown/reset/reset2' to > deliberately skip the core/cluster shutdown sequence. > Yes and IIRC this has been discussed in the past[1]. I expect to get some closure on open question on that thread. Quite a few questions were raised by few people and I am not sure if all were answered. I need to dig but but AFAIK it wasn't all answered. -- Regards, Sudeep [1] https://lkml.org/lkml/2019/1/18/16

5 years, 5 months

2
2
0 0

About disable gic cpuif in psci suspend or off

by Jisheng Zhang

Hi, In ATF-A, I usually see below code in psci suspend or off code path: /* Prevent interrupts from spuriously waking up this cpu */ plat_arm_gic_cpuif_disable(); But per my understanding, before calling psci_suspend(), the NW, e.g linux kernel has disabled all interrupts from cpu level, so here preventing interrupt is to prevent the interrupts from secure world? Another question is: for Cortex A55, this is not necessary. Because CA55 TRM says when the core_pwrdn_en bit is set, executing WFI automatically masks all interrupts and wake-up events in the core. Am I right? Thanks in advance

5 years, 5 months

1
0
0 0

Re: [TF-A] Insufficient ordering guarantees in bakery_lock_get() and bakery_lock_release() in bakery_lock_coherent.c

by Raghupathy Krishnamurthy

Hi Soby, Thanks for your response. >>it is needed to ensure the ordering of the succeeding sev(). Agree. Thanks for the clarification. >>Was this an issue that actually manifested on a hardware or is this something that you caught while reviewing the code? Noticed it while reviewing code and I have not observed it on hardware. Thanks -Raghu On November 26, 2019 at 8:55 AM, Soby Mathew <Soby.Mathew(a)arm.com> wrote: On 26/11/2019 16:30, Raghupathy Krishnamurthy via TF-A wrote: Hello! Reposting this from (https://developer.trustedfirmware.org/T589). bakery_lock_get() uses a dmbld() after lock acquisition which is insufficient in a lock acquire situation. With just dmbld(), stores in a critical section can be reordered before the dmbld() and indeed before the lock acquisition has taken place. similarly, bakery_lock_release() only uses dmbst(). A load in the critical section could be reordered after the dmbst() and write to the lock data structure releasing the lock. This is likely less of a problem but lock release needs to provide release semantics, and dmbst() is insufficient. For ex: A load in the critical section of CPU1 can be reordered after the store for the lock release, and it could read from a store that is executed on CPU2 in the same critical section, since CPU2 saw the store for the lock release first, and raced into the critical section. Hi Raghu, You are right on this. The dmbld() and dmbst() does not provide sufficient guarantees in the cases you mention. Was this an issue that actually manifested on a hardware or is this something that you caught while reviewing the code ? Also the dsb() after the write to the lock seems unnecessary. Am I missing something here ? It looks like the same issue is present even in bakery_lock_normal. If you are referring to the dsb() at this line : https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/locks/… it is needed to ensure the ordering of the succeeding sev(). Best Regards Soby Mathew Thanks Raghu

5 years, 5 months

2
2
0 0

Re: [TF-A] psci shutdown do not follow graceful power off sequence

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 > Sent: 03 December 2019 16:59 > > Hi, > system shutdown or system reset PSCI calls are invoked by the last core in > the system. That may be the case in practice but these functions can be called by any core in the system at any time, not just the last core. > PSCI lib does not do cache flush for the last core /cluster and > does not follow the core / cluster power down sequence. Correct. Not only that, it doesn't do anything with the other cores in the system that may be running at that time. > This may cause issue in a system if the system is not standalone one ie if > the system is a slave or node in a bigger system with other coherent > masters/PEs. > What issue specifically? Are the other coherent masters expecting to have the same view of the node's memory that the node had prior to calling system off/suspend? If so, then the node is not really independent to the wider system and system off/reset are probably not the right calls to use. Perhaps SYSTEM_SUSPEND is what you're looking for? That function requires all other cores to be off before the call and will perform cache maintenance on the last core. > Please suggest if the PSCI spec expected 'shutdown/reset/reset2' to > deliberately skip the core/cluster shutdown sequence. > Yes, the spec was deliberately relaxed between version 0.2 and 1.0 to allow implementations to just "pull the plug" since there would be no observable difference to the normal world caller between this behaviour and attempting to shutdown cleanly, which would be difficult and inherently racy anyway. > Otherwise in case it makes sense following is a patch to take care of this. > https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2364/ > issue: https://developer.trustedfirmware.org/T566 Thanks but I don't think we want this. Regards Dan. 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, 5 months

1
0
0 0

psci shutdown do not follow graceful power off sequence

by Sandeep Tripathy

Hi, system shutdown or system reset PSCI calls are invoked by the last core in the system. PSCI lib does not do cache flush for the last core /cluster and does not follow the core / cluster power down sequence. This may cause issue in a system if the system is not standalone one ie if the system is a slave or node in a bigger system with other coherent masters/PEs. Please suggest if the PSCI spec expected 'shutdown/reset/reset2' to deliberately skip the core/cluster shutdown sequence. Otherwise in case it makes sense following is a patch to take care of this. https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2364/ issue: https://developer.trustedfirmware.org/T566 Thanks Sandeep

5 years, 5 months

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Sandrine Bailleux

Hello Sumit, Sorry for not getting back to you earlier on this. I started looking at your patches and although I've not completely got my head around them yet, I've got some early comments and questions. I've tried to classify them by themes below. First of all, let me say that I'm no security expert and I did not know about the concept of authenticated encryption/decryption before looking at your patches. I spent a couple of hours reading about such algorithms in general and AES-GCM in particular. Most of what I've learned so far is based on my understanding of RFC 5116 [1]. What's the motivation for choosing GCM to start with? I've seen that it is free of patent [2], which I am guessing was a strong argument for it. I've also read that it is supposed to be quite lightweight and can take full advantage of parallel processing, although I've not looked into the details. Were these the reasons? Any other reasons? Key management -------------- fip_file_read() retrieves the key from the platform and stores it in a buffer on the stack. I don't see any code wiping it out of memory once we're done with it. Did I miss it? Unlike the root of trust public key, this is a (symmetric) secret key so it is sensitive data that we must not leave for grabs, even if the stack is in Trusted RAM and that it's likely to be overwritten by subsequent stack usage. Also, I am still trying to get my head around how this would integrate with a cryptographic engine where the key does not leave the chip. I can imagine that we could get the address of the encrypted firmware image from the FIP, pass that to a cryptographic engine, request it to decrypt it and store the result somewhere in Trusted RAM. In this case, we wouldn't call plat_get_fip_encryption_key(). Do you have any idea how we would pull this off? Like how the different modules (IO layer, crypto module, image parser module, ...) would integrate together? I have some concerns around the generation of the initialization vectors in the encrypt_fw tool. Right now, IVs are simply a random sequence of bytes (obtained through a call to OpenSSL's RAND_bytes() API). Now, I would imagine that RAND_bytes() is typically based on a good random number generator and thus will generate different sequences every time it is called. At least, as long as it is called from the same machine every time. But what if we encrypt a new FIP bundle from a different machine, say in the context of a firmware update? Is it not possible that it might choose the same IV out of bad luck? Perhaps that's an issue left to provisioning/manufacturing time and is out of the scope here. But it worries me because AFAIU, the security of AES-GCM is critically undermined if the same nonce is used multiple times with the same key (see section 5.1.1. "Nonce reuse" in RFC 5116). If the encryption key is the SSK (rather than the BSSK) then I guess the probability is even higher, as it is shared amongst a class of devices. Impact on memory footprint and performance ------------------------------------------ Do you know what the performance impact is when this feature is enabled in TF-A, to decrypt images at boot time? Obviously it depends on the platform and whether there is a dedicated cryptographic engine, and I suppose you cannot really get any relevant measurements out of QEMU but I would be interested if you've got any rough numbers. And what's the memory footprint impact? IIUC, AES-GCM almost does not inflate the size of the data it encrypts. The size of the ciphertext seems to be the same as the plaintext + the size of the authentication tag. So I guess there's no real impact on flash storage and Trusted RAM usage to hold decrypted firmware. But what about the mbedTLS primitives to decrypt the images? How much code and data does this add? encrypt_fw tool --------------- We have some floating ideas around re-implementing the tools (fiptool, certtool) in a scripting language (possibly python) in the future and also doing a better job at sharing a common description of the list of images to boot/authenticate between the firmware and the host tools. But we're not there yet, so I agree that implementing this new tool in C from the same "mold" as fiptool and certtool is what makes the most sense today. It's just another tool we will have to rework if and when we get there. I did not understand why this new tool needs to know what image it is encrypting. For example, one possible invocation could be: tools/encrypt_fw/encrypt_fw \ -k 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef \ --soc-fw bl31.bin \ --soc-fw-enc bl31_enc.bin \ --tos-fw bl32.bin \ --tos-fw-enc bl32_enc.bin Why not invoking the tool once per image instead? As in: encrypt_fw -k key -in ifile -out ofile for BL31, then for BL32? Does the tool do anything different based on the type of image it receives? Regards, Sandrine [1] https://tools.ietf.org/html/rfc5116 [2] https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents…

5 years, 5 months

2
1
0 0

Design proposal: new buildsystem

by Balint Dobszay

Hi All, The buildsystem of TF-A became complex and loaded with technical debt during the years, and it's time to do something about this. We made some plans and prototyping work to move to a CMake based solution and we would like to get feedback on the idea. Why CMake? In summary CMake is a mature tool having a wide acceptance in C and C++ projects. Also it has benefits of decreasing fragmentation in the developer community if we sync up with TF-M. How will it happen? This will be a slow process where the old build system will co-exist for a period with the new one. How long that period will be is an open question. For a more detailed summary please see https://developer.trustedfirmware.org/w/tf_a/cmake-buildsystem-proposal/ The design discussion will follow the design review proposal process of TF.org, as described on this page: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… You can find the patch for capturing the design decisions and discussion here: https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2662/ If you would like to contribute or have an opinion or any ideas please reply to this email or add a comment on Gerrit (link above). Regards, Balint 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, 5 months

1
0
0 0

Re: [TF-A] Insufficient ordering guarantees in bakery_lock_get() and bakery_lock_release() in bakery_lock_coherent.c

by Soby Mathew

On 26/11/2019 16:30, Raghupathy Krishnamurthy via TF-A wrote: > Hello! > > Reposting this from (https://developer.trustedfirmware.org/T589). > > bakery_lock_get() uses a dmbld() after lock acquisition which is insufficient in a lock acquire situation. With just dmbld(), stores in a critical section can be reordered before the dmbld() and indeed before the lock acquisition has taken place. similarly, bakery_lock_release() only uses dmbst(). A load in the critical section could be reordered after the dmbst() and write to the lock data structure releasing the lock. This is likely less of a problem but lock release needs to provide release semantics, and dmbst() is insufficient. For ex: A load in the critical section of CPU1 can be reordered after the store for the lock release, and it could read from a store that is executed on CPU2 in the same critical section, since CPU2 saw the store for the lock release first, and raced into the critical section. Hi Raghu, You are right on this. The dmbld() and dmbst() does not provide sufficient guarantees in the cases you mention. Was this an issue that actually manifested on a hardware or is this something that you caught while reviewing the code ? > Also the dsb() after the write to the lock seems unnecessary. Am I missing something here ? It looks like the same issue is present even in bakery_lock_normal. > If you are referring to the dsb() at this line : https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/locks/… it is needed to ensure the ordering of the succeeding sev(). Best Regards Soby Mathew > Thanks > Raghu >

5 years, 5 months

1
0
0 0

Insufficient ordering guarantees in bakery_lock_get() and bakery_lock_release() in bakery_lock_coherent.c

by Raghupathy Krishnamurthy

Hello! Reposting this from (https://developer.trustedfirmware.org/T589). bakery_lock_get() uses a dmbld() after lock acquisition which is insufficient in a lock acquire situation. With just dmbld(), stores in a critical section can be reordered before the dmbld() and indeed before the lock acquisition has taken place. similarly, bakery_lock_release() only uses dmbst(). A load in the critical section could be reordered after the dmbst() and write to the lock data structure releasing the lock. This is likely less of a problem but lock release needs to provide release semantics, and dmbst() is insufficient. For ex: A load in the critical section of CPU1 can be reordered after the store for the lock release, and it could read from a store that is executed on CPU2 in the same critical section, since CPU2 saw the store for the lock release first, and raced into the critical section. Also the dsb() after the write to the lock seems unnecessary. Am I missing something here ? It looks like the same issue is present even in bakery_lock_normal. Thanks Raghu

5 years, 5 months

1
0
0 0

Review hiccups

by Julius Werner

Hi Soby (and others), We've had a couple of MT8183 platform patches on Gerrit waiting for review/merge for a while (one over a week). Could you please help make sure they are in someone's queue at Arm? https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2379 (passed CI) https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2175 (passed CI) https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2401 (need kick off CI) Let me know if there's anything else we can do to help increase turnaround time on Gerrit. Thanks, Julius

5 years, 5 months

2
1
0 0

How to verify image BL1

by Iñigo Vicente Waliño

Hi, I am using QEMu to simulate the ARMv8 platform. How can I verify that the BL1 image is in the ROM? And if not, can I not find it? Thanks, Iñigo.

5 years, 5 months

1
0
0 0

TF-A Public Presentations collection

by Matteo Carlini

Hi all, I finally got round to collating links to all TF-A public presentations done over the years in our wiki page here https://developer.trustedfirmware.org/w/tf_a/ I intend to keep the list updated with all future appearances as well. Let me know if you spot any error or inconsistency. Thanks Matteo

5 years, 5 months

1
0
0 0

Design proposal: Property Access Layer

by Louis Mayencourt

Hi everyone, Please let me introduce the `Property Access Layer` prototype: The Property Access Layer (PAL) is an abstraction layer for platform specific data, allowing a "property" to be queried and a value retrieved without the requesting entity knowing what backing store is being used to hold the data. It is used to bridge new and old ways of providing platform-specific data: Today, information like the Chain of Trust is held within several, nested platform-defined tables. In the future, it may be provided as part of a device tree blob, along with the information about images to load. Introducing this abstraction layer will make migration easier and will preserve functionality for platforms that cannot / don't want to use device tree. Please have a look at the patches: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2559/1 Regards, Louis 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, 5 months

1
0
0 0

[RFC] New feature in TF-A to load encrypted FIP payloads

by Sumit Garg

Hi Everyone, The motivation behind this new feature comes from DRM robustness rules. DRM content vendors want to make it even harder to reverse engineer Trusted Execution Environment (TEE) and therefore would like to see that Trusted OS (BL32 payload) is not just signed, but also encrypted. Dan, Matteo, In continuation to our discussions at Linaro Connect SAN19 regarding support for encrypted firmwares (especially encrypted Trusted OS as BL32 payload) in TF-A. I have tried to come up with below RFC patch-set based on TBBR [1] optional requirement: R070_TBBR_FUNCTION. RFC patch-set: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2494 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2496 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2497 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2498 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2499 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2500 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2501 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2502 Also, I have used QEMU as a reference platform to test this feature (instructions documented as part of "[PATCH 9/9] docs: qemu: Add instructions to boot using FIP image"). So that it's easier for people interested in this feature to test. I look forward to hear feedback/comments on this new feature. [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… Regards, Sumit

5 years, 6 months

1
0
0 0

Notice of SPCI-SPM Prototype Removal

by Paul Beesley

Hello, This message is to provide advance notice that the experimental Secure Partition Manager (SPM) component - based around the SPCI Alpha 1 specification - will be removed from the codebase within the next few weeks. This component was deprecated for the v2.2 release. Normally a component stays in the codebase for one full release cycle after being deprecated but that does not apply to experimental and/or prototype features such as this one. The intention is not to replace this component directly with a similar SPM component but to instead implement an EL3 SPCI dispatcher component that enables the use of secure partitions with an SPM at either S-EL1 or at S-EL2 (v8.4 or later). This dispatcher would be compliant with the latest public draft of the Secure Partition Client Interface (SPCI) specification at the time. Please note that the SPM-MM (Management Mode) component is *not* going to be removed as part of this work. If you have any questions or concerns about this change then please get in touch either via this mailing list or via your Arm partner manager (where applicable). Thanks, Paul

5 years, 6 months

1
0
0 0

Re: [TF-A] [RFC] BL2 MTD frameworks

by Lionel DEBIEVE

Hi, Just to clarify a little bit more. There is no link here about a 32/64 bit architecture. The content of this change is to take care about new memory introduce (mtd devices) that are not based on size * LBA (where LBA=512) but size * LBA where (LBA=1) and in such case, the size could exceed the 4GB. It is not platform dependent and not architecture dependent, it's link to the connected MTD device only. I'm not sure that a new type is useful except if you want a type is modified regarding a platform flag such as USE_LARGE_MTD_DEVICE. Hope it's more clear. BR, Lionel On 11/5/19 3:20 PM, Gyorgy Szing via TF-A wrote: > Hi, > > I did not investigated all the details so what stays below may contain mistakes, but still I would like to add some comments. > > "using a type for the offset" > The type we use for this purpose seems to be a configuration parameter for the IO layer as it depends on the upper layer being used with the IO library. For example libc uses "long int" to specify the file offset (fseek, ftell), using a different type while running below libc does not seem to be a good idea. > The best option seems to be to define a type like (as Olivier mentioned) lib/zlib does. How we set this configuration parameter during the build is a question. The offset type could be dictated by the platform, the architecture (aarch32 or aarch64) or by the user. Which one is worth to implement needs investigation. > > If it is a good idea to use the same name "off_t" as zlib uses (or even the same type) is be questionable. It may give us more flexibility if we use a dedicated name, and the configuration maps the IO type to the one used by the upper layer. > > "32 bit backward compatibility" > Another angle worth to consider is the 32/64 bit compatibility. I.e.: newlib can use 64 bit offsets even on 32 bit architectures, and they use some wrappers to maintain binary compatibility with old builds. When built in a compatible manner, functions using the standardized names use 32 bit wide offsets and call the real 64 bit implementation as a wrapper. > To solve compatibility issues we could use a similar pattern. Instead of changing the existing function, we could add a new one (i.e. seek64). Then new 64 bit aware code could use the new function if available, and legacy code could call the old one. Longer term it is an option to deprecate the 32 bit version. > > "use stdint.h types" > And a finally: when selecting the type used for off_t (or whatever we are going to call it) please consider using stdint.h types (i.e. int_fast64_t). > > /George > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Olivier Deprez via TF-A > Sent: 25 October 2019 14:42 > To: tf-a(a)lists.trustedfirmware.org; Lionel DEBIEVE <lionel.debieve(a)st.com> > Subject: Re: [TF-A] [RFC] BL2 MTD frameworks > > Hi Lionel, > > On https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283 > I'm extending the discussion to the TF-A ML, to get people's opinion. > > The idea is to extend the io_seek offset parameter from ssize_t to unsigned long long. > There are indeed good reasons for that as flash storage density grows over the years. > > Now on the change, the struct io_dev_funcs seek function pointer is generic for the whole codebase / drivers. > So currently the change breaks the builds for at least rcar, stratix10 (did not check others from that point). > > An alternative is defining offset as an off_t type which is ssize_t by default, and only unsigned long long based on the platform (using _FILE_OFFSET_BITS=64). This pattern actually already exists in lib/zlib > > Other option is to change the generic prototype for all platform drivers (then we ensure all platforms build and supply platform patches). > > What do ML people think? > > Regards, > Olivier. > > > > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 18 October 2019 17:26 > To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > Subject: [TF-A] [RFC] BL2 MTD frameworks > > Hello Maintainers, > > I've sent a patch series around MTD framework management into BL2 stage (cf https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283). > > This patch series will add following frameworks: > > - a raw NAND framework implementation to support SLC NAND devices. Current implementation is limited to read operations without ECC corrections. Overrides are available to use hardware ECC from controller or low-level drivers. It also supports ONFI detection management but this can also be disabled or overridden by platform specific data. > - a SPI-MEM framework (inspired from kernel/u-boot implementation) that encapsulates all SPI operations to SPI low level drivers. > - a SPI-NAND framework based on SPI-MEM to support SPI NAND devices. This framework is also limited to the read operation. It uses single command, address and data bus width as legacy but can be overridden by platform. > - a SPI-NOR framework based on SPI-MEM to manage SPI NOR devices. It is also limited to read operations using single command, address and data bus width as legacy (override still possible by platform). The framework embeds some specific implementations for manufacturers specific behavior in case of quad mode configuration activation. > > This patch series also includes: > > - a new io_mtd interface to manage a generic access to all these frameworks. > - a NAND core driver that accesses independently to raw NAND or SPI-NAND framework. This core driver requires a scratch buffer defined by platform to manage unaligned pages (could be defined to 0 in case of aligned page) and limits access to a single NAND instance management. > - a complete integration is available based on STM32MP1 platform. > > Tests have been performed with the following devices: > > SLC NAND: > - Micron MT29F8G08ABACAH4 (ONFI) > - Micron MT29F8G16ABACAH4 (ONFI) > - Toshiba TH58NVG3S0HTAI0 (Non ONFI) > - Toshiba TC58BVG1S3HTAI0 (On die ECC) > > SPI NOR: > - Macronix MX25L51245G > - Cypress/Spansion S25FL512 > - Micron n25q512ax3 > > SPI-NAND: > - Micron MT29F2G01ABAGD > > Waiting for your comments. > > Best regards, Lionel > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > 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, 6 months

1
0
0 0

[RFC] Multiple Signing Domains

by Sandrine Bailleux

Hello all, As you may know, the Trusted Board Boot (TBB) code relies on the platform to define a chain of trust (CoT). Today, the only example of CoT present in the code base is the one used on Arm platforms, which is described: - in the TBBR specification [1]. - in the TF-A documentation [2] [3]. The entire TBBR CoT is built upon the root-of-trust public key (ROTPK), which is used to authenticate all subsequent firmware binaries and certificates, either directly or indirectly through some intermediate certificates. The TBBR CoT is only one example of a possible certificate chain and key ownership model. It might not suit all platforms and market segments but the TBBR implementation in TF-A leaves some freedom for other CoTs. Today, we are publishing some proof-of-concept code that shows one way the existing TBBR CoT may be modified in order to detach the BL33 image from the rest of the CoT. This effectively splits it into 2 CoTs: - 1 CoT for all secure world images (BL2, BL31, BL32). - 1 CoT for the normal world bootloader (BL33). If you are interested, please have a look at the related patch as well as the companion documentation: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2443 https://developer.trustedfirmware.org/w/tf_a/poc-multiple-signing-domains/ Note that at this stage, this is only prototype code and we do not plan to integrate it in the code base as is, because it does not implement what we would consider as a clean solution and uses a number of workarounds. We are considering cleaning this patch up and providing it as an alternate CoT on FVP platform in the future. For now, the intent is to provide some material, which we can base a discussion on. We're hoping to gather feedback from interested parties on the suitability of this approach. Regards, Sandrine [1] https://developer.arm.com/docs/den0006/d/trusted-board-boot-requirements-cl… (see page 21) [2] https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boo… [3] https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.ht…

5 years, 6 months

1
0
0 0

Re: [TF-A] [RFC] BL2 MTD frameworks

by Gyorgy Szing

Hi, I did not investigated all the details so what stays below may contain mistakes, but still I would like to add some comments. "using a type for the offset" The type we use for this purpose seems to be a configuration parameter for the IO layer as it depends on the upper layer being used with the IO library. For example libc uses "long int" to specify the file offset (fseek, ftell), using a different type while running below libc does not seem to be a good idea. The best option seems to be to define a type like (as Olivier mentioned) lib/zlib does. How we set this configuration parameter during the build is a question. The offset type could be dictated by the platform, the architecture (aarch32 or aarch64) or by the user. Which one is worth to implement needs investigation. If it is a good idea to use the same name "off_t" as zlib uses (or even the same type) is be questionable. It may give us more flexibility if we use a dedicated name, and the configuration maps the IO type to the one used by the upper layer. "32 bit backward compatibility" Another angle worth to consider is the 32/64 bit compatibility. I.e.: newlib can use 64 bit offsets even on 32 bit architectures, and they use some wrappers to maintain binary compatibility with old builds. When built in a compatible manner, functions using the standardized names use 32 bit wide offsets and call the real 64 bit implementation as a wrapper. To solve compatibility issues we could use a similar pattern. Instead of changing the existing function, we could add a new one (i.e. seek64). Then new 64 bit aware code could use the new function if available, and legacy code could call the old one. Longer term it is an option to deprecate the 32 bit version. "use stdint.h types" And a finally: when selecting the type used for off_t (or whatever we are going to call it) please consider using stdint.h types (i.e. int_fast64_t). /George -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Olivier Deprez via TF-A Sent: 25 October 2019 14:42 To: tf-a(a)lists.trustedfirmware.org; Lionel DEBIEVE <lionel.debieve(a)st.com> Subject: Re: [TF-A] [RFC] BL2 MTD frameworks Hi Lionel, On https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283 I'm extending the discussion to the TF-A ML, to get people's opinion. The idea is to extend the io_seek offset parameter from ssize_t to unsigned long long. There are indeed good reasons for that as flash storage density grows over the years. Now on the change, the struct io_dev_funcs seek function pointer is generic for the whole codebase / drivers. So currently the change breaks the builds for at least rcar, stratix10 (did not check others from that point). An alternative is defining offset as an off_t type which is ssize_t by default, and only unsigned long long based on the platform (using _FILE_OFFSET_BITS=64). This pattern actually already exists in lib/zlib Other option is to change the generic prototype for all platform drivers (then we ensure all platforms build and supply platform patches). What do ML people think? Regards, Olivier. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 October 2019 17:26 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] [RFC] BL2 MTD frameworks Hello Maintainers, I've sent a patch series around MTD framework management into BL2 stage (cf https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283). This patch series will add following frameworks: - a raw NAND framework implementation to support SLC NAND devices. Current implementation is limited to read operations without ECC corrections. Overrides are available to use hardware ECC from controller or low-level drivers. It also supports ONFI detection management but this can also be disabled or overridden by platform specific data. - a SPI-MEM framework (inspired from kernel/u-boot implementation) that encapsulates all SPI operations to SPI low level drivers. - a SPI-NAND framework based on SPI-MEM to support SPI NAND devices. This framework is also limited to the read operation. It uses single command, address and data bus width as legacy but can be overridden by platform. - a SPI-NOR framework based on SPI-MEM to manage SPI NOR devices. It is also limited to read operations using single command, address and data bus width as legacy (override still possible by platform). The framework embeds some specific implementations for manufacturers specific behavior in case of quad mode configuration activation. This patch series also includes: - a new io_mtd interface to manage a generic access to all these frameworks. - a NAND core driver that accesses independently to raw NAND or SPI-NAND framework. This core driver requires a scratch buffer defined by platform to manage unaligned pages (could be defined to 0 in case of aligned page) and limits access to a single NAND instance management. - a complete integration is available based on STM32MP1 platform. Tests have been performed with the following devices: SLC NAND: - Micron MT29F8G08ABACAH4 (ONFI) - Micron MT29F8G16ABACAH4 (ONFI) - Toshiba TH58NVG3S0HTAI0 (Non ONFI) - Toshiba TC58BVG1S3HTAI0 (On die ECC) SPI NOR: - Macronix MX25L51245G - Cypress/Spansion S25FL512 - Micron n25q512ax3 SPI-NAND: - Micron MT29F2G01ABAGD Waiting for your comments. Best regards, Lionel -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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. -- 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

New "memory map" tool

by Louis Mayencourt

Hi all, We are introducing a new "memory map" tool part of the build system. The tool parse the blx.map files and print a representation of the memory layout for the latest build. It can be invoked by adding "memmap" in the make build command. If you are interested, please have a look at the related patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2413/1 Regards, Louis 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, 6 months

1
0
0 0

Design proposal: firmware debugfs interface

by Olivier Deprez

Hi All, We are proposing a new firmware debug interface in the form of a "debug filesystem". The intent is to expose live firmware data or firmware driver HAL to the upper layers, in debug builds. For people interested, please review and comment the design proposal: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2381 The design is not closed, the intent is to collect opinions, and have a discussion on options and implications. Thanks & Regards, Olivier. 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, 6 months

1
0
0 0

Re: [TF-A] [RFC] BL2 MTD frameworks

by Olivier Deprez

Hi Lionel, On https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283 I'm extending the discussion to the TF-A ML, to get people's opinion. The idea is to extend the io_seek offset parameter from ssize_t to unsigned long long. There are indeed good reasons for that as flash storage density grows over the years. Now on the change, the struct io_dev_funcs seek function pointer is generic for the whole codebase / drivers. So currently the change breaks the builds for at least rcar, stratix10 (did not check others from that point). An alternative is defining offset as an off_t type which is ssize_t by default, and only unsigned long long based on the platform (using _FILE_OFFSET_BITS=64). This pattern actually already exists in lib/zlib Other option is to change the generic prototype for all platform drivers (then we ensure all platforms build and supply platform patches). What do ML people think? Regards, Olivier. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 October 2019 17:26 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] [RFC] BL2 MTD frameworks Hello Maintainers, I've sent a patch series around MTD framework management into BL2 stage (cf https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283). This patch series will add following frameworks: - a raw NAND framework implementation to support SLC NAND devices. Current implementation is limited to read operations without ECC corrections. Overrides are available to use hardware ECC from controller or low-level drivers. It also supports ONFI detection management but this can also be disabled or overridden by platform specific data. - a SPI-MEM framework (inspired from kernel/u-boot implementation) that encapsulates all SPI operations to SPI low level drivers. - a SPI-NAND framework based on SPI-MEM to support SPI NAND devices. This framework is also limited to the read operation. It uses single command, address and data bus width as legacy but can be overridden by platform. - a SPI-NOR framework based on SPI-MEM to manage SPI NOR devices. It is also limited to read operations using single command, address and data bus width as legacy (override still possible by platform). The framework embeds some specific implementations for manufacturers specific behavior in case of quad mode configuration activation. This patch series also includes: - a new io_mtd interface to manage a generic access to all these frameworks. - a NAND core driver that accesses independently to raw NAND or SPI-NAND framework. This core driver requires a scratch buffer defined by platform to manage unaligned pages (could be defined to 0 in case of aligned page) and limits access to a single NAND instance management. - a complete integration is available based on STM32MP1 platform. Tests have been performed with the following devices: SLC NAND: - Micron MT29F8G08ABACAH4 (ONFI) - Micron MT29F8G16ABACAH4 (ONFI) - Toshiba TH58NVG3S0HTAI0 (Non ONFI) - Toshiba TC58BVG1S3HTAI0 (On die ECC) SPI NOR: - Macronix MX25L51245G - Cypress/Spansion S25FL512 - Micron n25q512ax3 SPI-NAND: - Micron MT29F2G01ABAGD Waiting for your comments. Best regards, Lionel -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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, 6 months

1
0
0 0

Re: [TF-A] compile toolchain

by Alexei Fedorov

Hi Feng, user-guide.rst references GCC 9.1 and later versions. The code was also tested with GCC 10.0.0. Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Chen Feng via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 24 October 2019 14:32 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] compile toolchain hi expects， from the atf2.2 release notes,I can see the tf-a already supported pac bti and mte feature. I want to enable and test it on fvp platform. I want to know which tool chain to use for compiling code for theses. Cheers Feng -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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, 6 months

1
0
0 0

compile toolchain

by Chen Feng

hi expects， from the atf2.2 release notes,I can see the tf-a already supported pac bti and mte feature. I want to enable and test it on fvp platform. I want to know which tool chain to use for compiling code for theses. Cheers Feng

5 years, 6 months

1
0
0 0

Trusted Firmware version 2.2 is now available

by Bipin Ravi

Hi all, Trusted Firmware version 2.2 is now available and can be found here: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.2 Please refer to the readme and change log for further information. Thanks & best regards, [cid:image001.jpg@01D588EA.577B7090] Bipin Ravi | Principal Design Engineer Bipin.Ravi(a)arm.com<mailto:Joshua.Sunil@arm.com> | Skype: Bipin.Ravi.ARM Direct: +1-512-225 -1071 | Mobile: +1-214-212-0794 5707 Southwest Parkway, Suite 100, Austin, TX 78735

5 years, 6 months

1
0
0 0

[RFC] BL2 MTD frameworks

by Lionel DEBIEVE

Hello Maintainers, I've sent a patch series around MTD framework management into BL2 stage (cf https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283). This patch series will add following frameworks: - a raw NAND framework implementation to support SLC NAND devices. Current implementation is limited to read operations without ECC corrections. Overrides are available to use hardware ECC from controller or low-level drivers. It also supports ONFI detection management but this can also be disabled or overridden by platform specific data. - a SPI-MEM framework (inspired from kernel/u-boot implementation) that encapsulates all SPI operations to SPI low level drivers. - a SPI-NAND framework based on SPI-MEM to support SPI NAND devices. This framework is also limited to the read operation. It uses single command, address and data bus width as legacy but can be overridden by platform. - a SPI-NOR framework based on SPI-MEM to manage SPI NOR devices. It is also limited to read operations using single command, address and data bus width as legacy (override still possible by platform). The framework embeds some specific implementations for manufacturers specific behavior in case of quad mode configuration activation. This patch series also includes: - a new io_mtd interface to manage a generic access to all these frameworks. - a NAND core driver that accesses independently to raw NAND or SPI-NAND framework. This core driver requires a scratch buffer defined by platform to manage unaligned pages (could be defined to 0 in case of aligned page) and limits access to a single NAND instance management. - a complete integration is available based on STM32MP1 platform. Tests have been performed with the following devices: SLC NAND: - Micron MT29F8G08ABACAH4 (ONFI) - Micron MT29F8G16ABACAH4 (ONFI) - Toshiba TH58NVG3S0HTAI0 (Non ONFI) - Toshiba TC58BVG1S3HTAI0 (On die ECC) SPI NOR: - Macronix MX25L51245G - Cypress/Spansion S25FL512 - Micron n25q512ax3 SPI-NAND: - Micron MT29F2G01ABAGD Waiting for your comments. Best regards, Lionel

5 years, 7 months

1
0
0 0

Re: [TF-A] Boot getting stuck on RK3399 Rockpro64 board

by Joanna Farley

Hi Hugh, Ccing the Rockchip maintainers from https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/maint… as neither appear to be subscribed to this mailing list. Joanna On 08/10/2019, 21:45, "TF-A on behalf of Hugh Cole-Baker via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi folks, I've been using TF-A with mainline U-Boot recently as firmware & boot loader for a RK3399 Rockpro64 board. I'm compiling TF-A and U-boot based on this guide [1], using gcc 8.3.0 from Debian. TF-A v2.1 works fine for this, but I recently tried to switch to TF-A latest master and found U-Boot gets stuck with this version. The symptoms are: U-Boot TPL and SPL print starting messages like this: U-Boot TPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50) Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50 +0000) Trying to boot from MMC2 ...and then there is no more output when normally U-Boot proper would start, and go on to load the Linux kernel, etc. Starting from v2.1, with git bisect I found the first 'bad' commit is: 0aad563c7480 rockchip: Update BL31_BASE to 0x40000 and that commit does change some RK3399-related files so seems likely. I'm not sure how to debug further, any ideas on why boot is hanging after that change or how to get more debugging information? Best regards, Hugh Cole-Baker [1] https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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] Hercules-AE I$ problems

by Olivier Deprez

Hi Varun, TF-A v1.4 is rather old codebase, can you provide the exact patchset you cherry-picked on top of it? e.g. you need the Hercules CPU support patch (a4668c36f1fca75b), but possibly also all which is related to HW_ASSISTED_COHERENCY option? Also, can you pls provide your build cmd line? Thanks & Regards, Olivier. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Soby Mathew via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 11 October 2019 11:21 To: Varun Wadekar <vwadekar(a)nvidia.com>; Joanna Farley <Joanna.Farley(a)arm.com>; Matteo Carlini <Matteo.Carlini(a)arm.com> Cc: Julius Werner via TF-A <tf-a(a)lists.trustedfirmware.org>; nd <nd(a)arm.com> Subject: Re: [TF-A] Hercules-AE I$ problems On 10/10/2019 20:46, Varun Wadekar wrote: > Hello, > > First of all, thanks a lot for posting the Hercules-AE patches. > > We picked them up and used them internally. Unfortunately, the CPU sees > garbage in it's I$ when we enable the I cache for the processor. If we > keep I$ disabled, TF-A boots properly. We are using TF-A v1.4 for > verification. > > We booted Linux kernel v4.14 on the processor and don't see this problem > there. So, we suspect something going wrong inside TF-A. Have you seen > this problem internally? Any hints or clues to solve it would be helpful. > > Thanks. Hi Varun, As indicated in the commit message of the patch, we have not tested the CPU support internally due to non-availability of FVP for the CPU. TF-A assumes that I$ will be invalidated when CPU is reset. Perhaps this is not true for your setup. Could you try adding a `IC IALLU` in the CPU reset handler prior to I$ enable and see if that improves anything ? Best Regards Soby Mathew > > > ------------------------------------------------------------------------ > This email message is for the sole use of the intended recipient(s) and > may contain confidential information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy all > copies of the original message. > ------------------------------------------------------------------------ -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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

1
0
0 0

Hercules-AE I$ problems

by Varun Wadekar

Hello, First of all, thanks a lot for posting the Hercules-AE patches. We picked them up and used them internally. Unfortunately, the CPU sees garbage in it's I$ when we enable the I cache for the processor. If we keep I$ disabled, TF-A boots properly. We are using TF-A v1.4 for verification. We booted Linux kernel v4.14 on the processor and don't see this problem there. So, we suspect something going wrong inside TF-A. Have you seen this problem internally? Any hints or clues to solve it would be helpful. Thanks. ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

5 years, 7 months

2
1
0 0

Documentation and Website Updates

by Paul Beesley

Hi everyone, This post is to let you know about some changes to the TrustedFirmware.org website and to the TF-A documentation. It briefly covers what's new, what has moved, and what happens to any existing resources you may be using. First of all, we are making it more obvious where to access the documentation and the Gerrit review system. The front page of trustedfirmware.org has grown new "Documentation" and "Review" menus with links to this content. Dashboard and Wiki items have moved under the Documentation menu. Secondly, the online version of the documentation has moved to www.trustedfirmware.org/docs/tf-a<http://www.trustedfirmware.org/docs/tf-a>. This is a pre-rendered, HTML copy of the content that is found under the "docs" directory of the TF-A repository. The content here will remain synchronised with the master branch of the repository. Following the v2.2 release, you will also be able to access a static version of the documentation that corresponds to that tag, via a version selection drop-down menu on the site. The intention behind this change is to make it easier to find the docs, to improve the output quality and to make the content more modular and readable. The new setup has a persistent table of contents (displayed to the left of the page content) and a search feature, making it easier to find what you're looking for and easier to move between documents and topics. You may be used to viewing the docs through either the git viewer (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/) or through the Github mirror (https://github.com/ARM-software/arm-trusted-firmware/). The landing pages of these sites now contain links to the new content. While you can still use these sites to access other documentation content, you may find that there are some formatting warnings displayed if you do so. Finally, if you prefer to read a local copy of the documentation on your machine then you can build the same HTML output following the instructions at https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/docs-bui… (or docs/getting_started/docs-build.rst, for the equivalent file in the repository). As always, let us know if you have any comments or if there are other changes you would like to see. Thanks, Paul

5 years, 7 months

1
0
0 0

Boot getting stuck on RK3399 Rockpro64 board

by Hugh Cole-Baker

Hi folks, I've been using TF-A with mainline U-Boot recently as firmware & boot loader for a RK3399 Rockpro64 board. I'm compiling TF-A and U-boot based on this guide [1], using gcc 8.3.0 from Debian. TF-A v2.1 works fine for this, but I recently tried to switch to TF-A latest master and found U-Boot gets stuck with this version. The symptoms are: U-Boot TPL and SPL print starting messages like this: U-Boot TPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50) Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50 +0000) Trying to boot from MMC2 ...and then there is no more output when normally U-Boot proper would start, and go on to load the Linux kernel, etc. Starting from v2.1, with git bisect I found the first 'bad' commit is: 0aad563c7480 rockchip: Update BL31_BASE to 0x40000 and that commit does change some RK3399-related files so seems likely. I'm not sure how to debug further, any ideas on why boot is hanging after that change or how to get more debugging information? Best regards, Hugh Cole-Baker [1] https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip

5 years, 7 months

1
0
0 0

Forthcoming Trusted Firmware-A 2.2 release

by Bipin Ravi

Hi, This is to notify that we are planning to target the Trusted Firmware-A 2.2 release during the third week of October as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.1 release. As part of this, a release candidate tag will be created and release activities will commence from Monday October 7th. 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.2 release are submitted in good time to be complete by Friday October 4th. Any major enhancement PR's still open after that date will not be merged until after the release. Thanks & best regards, [cid:image001.jpg@01D57244.98C07530] Bipin Ravi | Principal Design Engineer Bipin.Ravi(a)arm.com<mailto:Joshua.Sunil@arm.com> | Skype: Bipin.Ravi.ARM Direct: +1-512-225 -1071 | Mobile: +1-214-212-0794 5707 Southwest Parkway, Suite 100, Austin, TX 78735

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. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 349459: (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 349459: (ARRAY_VS_SINGLETON) /plat/mediatek/mt8183/drivers/sspm/sspm.c: 150 in sspm_alive_show() 144 145 if (sspm_ipi_send_non_blocking(IPI_ID_PLATFORM, &ipi_data) != 0) { 146 ERROR("sspm init send fail! ret=%d\n", ret); 147 return -1; 148 } 149 >>> CID 349459: (ARRAY_VS_SINGLETON) >>> Passing "&ipi_data" to function "sspm_ipi_recv_non_blocking" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 150 while (sspm_ipi_recv_non_blocking(IPI_ID_PLATFORM, 151 &ipi_data, 152 sizeof(ipi_data)) 153 && count) { 154 mdelay(100); 155 count--; 156 } 157 158 return (ipi_data == 1) ? 0 : -1; /plat/mediatek/mt8183/drivers/sspm/sspm.c: 145 in sspm_alive_show() 139 uint32_t ipi_data, count; 140 int ret = 0; 141 142 count = 5; 143 ipi_data = 0xdead; 144 >>> CID 349459: (ARRAY_VS_SINGLETON) >>> Passing "&ipi_data" to function "sspm_ipi_send_non_blocking" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 145 if (sspm_ipi_send_non_blocking(IPI_ID_PLATFORM, &ipi_data) != 0) { 146 ERROR("sspm init send fail! ret=%d\n", ret); 147 return -1; 148 } 149 150 while (sspm_ipi_recv_non_blocking(IPI_ID_PLATFORM, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

5 years, 8 months

1
0
0 0

Coverity Scan subscription confirmation

by scan-admin＠coverity.com

Hi tf-a(a)lists.trustedfirmware.org, Your email was added by sandrine.bailleux(a)arm.com to receive software defect notifications from [1]Coverity Scan for the ARM-software/arm-trusted-firmware project. To confirm and activate these notifications, [2]click here. If you do not wish to receive these emails, you may safely ignore this message. References 1. https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… 2. https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

5 years, 8 months

1
0
0 0

Re: [TF-A] Defects detected by Coverity Scan Online

by Sandrine Bailleux

Hi, We are going to configure Coverity Scan Online to make it send notifications to this mailing list. This way, everyone subscribed on this mailing list will be aware of newly detected/eliminated defects found by the tool. The report will provide a summary of the findings (their nature, location in the source code). In order to look up the details or to triage them, you will still need to access the database through the web portal on https://scan.coverity.com/projects/arm-software-arm-trusted-firmware . As a reminder, you will need to create an account to view the defects there (it's possible to use your Github account). This is expected to generate a low volume of emails, as we typically do 1 analysis per week day. As a heads up, the web interface mentions that "an authorization confirmation will be sent to each newly provided email address and must be acknowledged before notifications will be sent". In which case, please ignore these emails. Regards, Sandrine

5 years, 8 months

1
0
0 0

Re: [TF-A] License

by Joanna Farley

Hi Tristan, Can you please clarify what your exact concern is? Which files and what text exactly? That will help us answer your concern. Thanks Joanna On 16/09/2019, 23:48, "TF-A on behalf of Tristan Muntsinger via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hello all, It looks like the copyright guidance on this project changed about a year ago (Nov 13, 2018) to a placeholder and hasn't been corrected yet. Can this be fixed to make the license valid so the project can be legally redistributed per BSD-3 as intended? Thanks, Tristan Muntsinger -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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, 8 months

2
2
0 0

Re: [TF-A] SMC to intentionally trigger a panic in TF-A

by Julius Werner

Hi Dan, Whoops, sorry, this fell through the cracks for me since I wasn't on the to: line. Thanks for your response! > OK I can see the use of that, although I'd be a bit concerned about such a thing being available as a general service in case it gets used as an attack vector. For example, a test program could aggressively use this service to try to get the firmware to leak secure world information or something about its behaviour. Yes, of course, we can gate this with a build option so it would only be available where desired. > However, I think there might already be support for what you need. PSCI is part of the standard service and the function SYSTEM_RESET2 allows for both architectural and vendor-specific resets. The latter allows for vendor-specific semantics, which could include crashing the firmware as you suggest. > > Chrome OS could specify what such a vendor-specific reset looks like and each Chromebook's platform PSCI hooks could be implemented accordingly. Right, but defining a separate vendor-specific reset type for each platform is roughly the same as defining a separate SiP SMC for each of them. It's the same problem that the SMC/PSCI spec and the TF repository layout is only designed to deal with generic vs. SoC-vendor-specific differentiation. If the normal world OS needs a feature, we can only make it generic or duplicate it across all vendors running that OS. > Alternatively, this could potentially be defined as an additional architectural reset. This would enable a generic implementation but would require approval/definition by Arm's Architecture team. Like me they might have concerns about this being defined at a generic architectural level. Yes, I think that would be the best option. Could you kick off that process with the Architecture team? Or tell me who I should talk to about this? Thanks, Julius

5 years, 8 months

2
1
0 0

License

by Tristan Muntsinger

Hello all, It looks like the copyright guidance on this project changed about a year ago (Nov 13, 2018) to a placeholder and hasn't been corrected yet. Can this be fixed to make the license valid so the project can be legally redistributed per BSD-3 as intended? Thanks, Tristan Muntsinger

5 years, 8 months

1
0
0 0

Re: [TF-A] About next release

by Joanna Farley

Hi Yann, You are quite correct. We will be looking to create a v2.2 tag release sometime early to mid October. You can expect a more formal notification and a request to get any patches submitted in the next week or so. As in previous releases master will be generally locked for a week or so while closedown testing is performed although we will assess incoming patches to see if they can be taken with low risk. Joanna On 16/09/2019, 13:19, "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, From the wiki page https://developer.trustedfirmware.org/w/tf_a/tf-a_release_information/, the next v2.2 tag may be released soon. But the exact timeframe is not yet published. The wiki page might be updated if you have more information. When do you expect to release tag v2.2? What will be the deadline to send patches upstream? Thanks, Yann -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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, 8 months

1
0
0 0

About next release

by Yann GAUTIER

Hi, >From the wiki page https://developer.trustedfirmware.org/w/tf_a/tf-a_release_information/, the next v2.2 tag may be released soon. But the exact timeframe is not yet published. The wiki page might be updated if you have more information. When do you expect to release tag v2.2? What will be the deadline to send patches upstream? Thanks, Yann

5 years, 8 months

1
0
0 0

Re: [TF-A] On supporting unmaintained platforms and downstream projects

by Julius Werner

Hi Soby, > Hi Julius, > Apologize for the radio silence as I was on sabbatical. Yes, I agree the > project needs to have a clear policy around platforms. We will get this > started on our end and send a policy proposal for review. No problem, thanks to Sandrine for taking care of it so quickly. Unfortunately we now discovered that we're still stuck on the same issue with MT8173. Could one of you please help getting https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/990/31 landed to fix that too? Thanks, Julius

5 years, 8 months

1
0
0 0

Merge Tegra platform changes

by Varun Wadekar

Hello Soby/Joanna, We would like to upstream support for a new Tegra platform along with some other changes. The last time I checked, there were more than 400 changes waiting to be upstreamed. Can someone help me with the best/fastest approach to start upstreaming? Previously, we would upstream changes in big chunks (as branches) but I don't know if that approach still works. Thanks. ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

5 years, 8 months

3
6
0 0

Re: [TF-A] On supporting unmaintained platforms and downstream projects

by Julius Werner

Hi Soby, > Hmm, if we merge a non-trivial patch and ensure the build works, then we > do not know whether it runs correctly, whether there are any runtime > effects that would affect stability/robustness of the platform that even > might have security implications. Hence, in my view, it is better to > have a broken build for the platform, rather than have runtime problems. > > The project could form a policy that if a platform remains broken for > more than 2 releases (1 year by current release intervals), then it will > get removed from the tree after giving enough notifications. Thanks, yes, I think it would be good to have a clear policy on this, whatever it is. I would still like to make a case for keeping these platforms in the tree on a best-effort basis. You're right that there's a chance for untested patches to cause all sorts of runtime errors, but I think that may still be better than a platform that doesn't build at all. A platform that doesn't build doesn't benefit anyone. A platform that may have errors still has a chance of working, and even if it doesn't it gives a third-party contributor or hobby developer who wants to start using it a chance to fix it up again. This is something we occasionally see happening with some of our older, less maintained platforms in coreboot. But if it doesn't even build, the chance of someone coming along to fix it seem very slim, because then more and more build issues will keep piling up over time. (In fact, I doubt there's even any point in keeping broken stuff in the tree for another year as you proposed... likely all that would do is confuse people who are trying to refactor project-wide APIs. Code that's never build-tested just bit rots very quickly. I think at that point you might as well remove it from the repo immediately.) It's true that there may also be security issues (which is more serious), but I'm skeptical that this really makes a lot of difference. After all, this may happen even while the platform is still actively maintained. Just testing whether it boots doesn't make sure you have no security issues anyway. Maybe a way to make this more visible instead could be to introduce a new ALLOW_UNMAINTAINED_PLATFORM=1 make variable that the user has to explicitly set to build a platform without active maintainer? That could serve as a warning that the code may not be safe to use for critical applications anymore while still giving developers access to something if they're willing to deal with possible issues. Anyway, whatever the policy may be, a more defined process would help. I think the initial messaging around the console deprecation plan was fine, but it would have been good to have another explicit announcement when the CI actually gets turned off for a platform.

5 years, 8 months

2
1
0 0

Re: [TF-A] broken link in phabricator wiki

by Sandrine Bailleux

Hi Leif, On 9/3/19 3:16 AM, Leif Lindholm via TF-A wrote: > On page https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/ > the link to "new TF-A Contribution Guidelines" points at > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/contribut…, > which is a dead link. > I expect it is meant to be pointing to > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/proc…. You're right, thanks for pointing it out. We forgot to update this page when the docs hierarchy got restructured some time ago. This is now fixed. Regards, Sandrine

5 years, 8 months

1
0
0 0

broken link in phabricator wiki

by Leif Lindholm

Hi there, On page https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/ the link to "new TF-A Contribution Guidelines" points at https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/contribut…, which is a dead link. I expect it is meant to be pointing to https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/proc…. Best Regards, Leif

5 years, 8 months

1
0
0 0

Re: [TF-A] On supporting unmaintained platforms and downstream projects

by Sandrine Bailleux

Hi Julius, On 8/27/19 9:55 PM, Julius Werner via TF-A wrote: > Could either of you please help get the Tegra fix in > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1192 > landed (and subsequently CI for Tegra re-enabled)? It has been > reviewed and approved for two weeks but nobody is merging it. This is > blocking more and more work across all coreboot-based platforms so I > would appreciate if we could get it resolved quickly. Apologies for the delay. As you may have seen, the patch has now been merged, and we've also re-enabled the Tegra builds in the CI. Regards, Sandrine

5 years, 8 months

2
1
0 0

Re: [TF-A] On supporting unmaintained platforms and downstream projects

by Julius Werner

Hi Soby, Joanna, Could either of you please help get the Tegra fix in https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1192 landed (and subsequently CI for Tegra re-enabled)? It has been reviewed and approved for two weeks but nobody is merging it. This is blocking more and more work across all coreboot-based platforms so I would appreciate if we could get it resolved quickly. Thanks, Julius

5 years, 8 months

2
1
0 0

Ultra96-V1 stops booting since b8e39f49e634

by Jan Kiszka

Hi all, I've bisected a boot issue of my Ultra96 version 1 down to commit [1]. U-Boot plays no role, I tried current master, 2019.07 and 2019.01. What might be related: I'm using pre-built fsbl, pmu-fw and bitstream from Alex' OpenSUSE packages [2][3][4]. Build steps are as described in [5]. Meanwhile, I rebuilt at least the pmu-fw from current embeddedsw git (c12743e5d7b0), but also without any impact on the issue. Any idea what could be wrong and why specifically this commit triggers it? I'd like to lift everything to a recent ATF version because of compilation issues with currently used 1.6 and newer gcc releases. Thanks, Jan [1] https://github.com/ARM-software/arm-trusted-firmware/commit/b8e39f49e634 [2] https://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Zy… [3] https://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Zy… [4] https://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Zy… [5] https://github.com/siemens/jailhouse-images/blob/v0.11/recipes-bsp/u-boot/f…

5 years, 8 months

2
2
0 0

Re: [TF-A] SMC to intentionally trigger a panic in TF-A

by Dan Handley

Hi Julius > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius > Werner via TF-A > Sent: 20 August 2019 02:15 > > Hi Soby et. al., > > I'd like to implement a small new feature and ask some guidance for how to go > about it: Chrome OS has the ability to automatically collect crash reports > from runtime crashes in Trusted Firmware, and we would like to set up > automated tests to ensure this feature stays working. > In order to do this we need a way for the non-secure OS to intentionally > trigger a panic in EL3. The obvious solution would be to implement a new SMC > for that. (It's common for operating systems to have similar facilities, e.g. > Linux can force a kernel panic by writing 'c' into /proc/sysrq-trigger.) > OK I can see the use of that, although I'd be a bit concerned about such a thing being available as a general service in case it gets used as an attack vector. For example, a test program could aggressively use this service to try to get the firmware to leak secure world information or something about its behaviour. > My main question is: where should I get an SMC function ID for this? > This is not a silicon or OEM specific feature, so the SiP Service Calls and > OEM Service Calls ID ranges seem inappropriate (or do you think it would make > sense to treat Google or Chrome OS as the "OEM" > here, even though that's not quite accurate?). I guess in theory you could mandate that all Chrome OS SiPs provide a specific function ID in their own specific SiP service, but I don't think that's the right solution here... > There are ranges for Trusted > Applications and the Trusted OS but unfortunately none for the normal world > OS. I don't think the TOS range is right either. > Is this something that would make sense to allocate under Standard > Service Calls? Could you just find an ID for me to use there or does > everything in that range need a big specification document written by Arm? > For sure everything in the standard or architectural ranges require specification by Arm, although this does not necessarily need to be big. However, I think there might already be support for what you need. PSCI is part of the standard service and the function SYSTEM_RESET2 allows for both architectural and vendor-specific resets. The latter allows for vendor-specific semantics, which could include crashing the firmware as you suggest. Chrome OS could specify what such a vendor-specific reset looks like and each Chromebook's platform PSCI hooks could be implemented accordingly. Alternatively, this could potentially be defined as an additional architectural reset. This would enable a generic implementation but would require approval/definition by Arm's Architecture team. Like me they might have concerns about this being defined at a generic architectural level. Regards Dan. 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, 9 months

1
0
0 0

SMC to intentionally trigger a panic in TF-A

by Julius Werner

Hi Soby et. al., I'd like to implement a small new feature and ask some guidance for how to go about it: Chrome OS has the ability to automatically collect crash reports from runtime crashes in Trusted Firmware, and we would like to set up automated tests to ensure this feature stays working. In order to do this we need a way for the non-secure OS to intentionally trigger a panic in EL3. The obvious solution would be to implement a new SMC for that. (It's common for operating systems to have similar facilities, e.g. Linux can force a kernel panic by writing 'c' into /proc/sysrq-trigger.) My main question is: where should I get an SMC function ID for this? This is not a silicon or OEM specific feature, so the SiP Service Calls and OEM Service Calls ID ranges seem inappropriate (or do you think it would make sense to treat Google or Chrome OS as the "OEM" here, even though that's not quite accurate?). There are ranges for Trusted Applications and the Trusted OS but unfortunately none for the normal world OS. Is this something that would make sense to allocate under Standard Service Calls? Could you just find an ID for me to use there or does everything in that range need a big specification document written by Arm? Thanks, Julius

5 years, 9 months

1
0
0 0

Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Alexei Fedorov

Hi Marek The patch is available at https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1789 Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 19 August 2019 11:41 To: Marek <marek.bykowski(a)gmail.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching Hi Marek, Changes are in review so hopefully soon. Joanna On 19/08/2019, 10:56, "TF-A on behalf of Marek via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Dan, Are there any time estimates when the fix should be in? Thanks, Marek On Sat, 10 Aug 2019 at 22:46, Marek via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Thank you Dan for checking this out. Looking forward into the fix. > > Marek > > On Thu, 8 Aug 2019 at 17:52, Dan Handley via TF-A > <tf-a(a)lists.trustedfirmware.org> wrote: > > > > Hi Marek > > > > Thanks for pointing this out. Typically we expect any timing sensitive secure operations to be implemented at Secure-EL1 or lower, which the current code does protect. However, you are correct that all secure world code including EL3 should not expose timing information. A fix is in progress to address this. > > > > Regards > > > > Dan. > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > > > Bykowski via TF-A > > > Sent: 03 August 2019 07:37 > > > To: tf-a(a)lists.trustedfirmware.org; David Cunado <David.Cunado(a)arm.com> > > > Subject: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the > > > PMCR_EL0 across world switching > > > > > > Hi David/ATF Support, > > > > > > An excerpt from the commit message to CVE-2017-15031 is "Additionally, > > > PMCR_EL0 is added to the list of registers that are saved and restored during > > > a world switch." > > > > > > My question is why it is only being saved/restored across the world switch > > > and not during a "normal" SMC call? When I do modify the > > > PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter > > > counts during the smc call and does expose secure world timing information to > > > NonSecure in that matter. > > > > > > Thanks, > > > Marek > > > -- > > > TF-A mailing list > > > TF-A(a)lists.trustedfirmware.org > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > 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. > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > -- > Slán, > Marek > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- Slán, Marek -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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, 9 months

1
0
0 0

Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Joanna Farley

Hi Marek, Changes are in review so hopefully soon. Joanna On 19/08/2019, 10:56, "TF-A on behalf of Marek via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Dan, Are there any time estimates when the fix should be in? Thanks, Marek On Sat, 10 Aug 2019 at 22:46, Marek via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Thank you Dan for checking this out. Looking forward into the fix. > > Marek > > On Thu, 8 Aug 2019 at 17:52, Dan Handley via TF-A > <tf-a(a)lists.trustedfirmware.org> wrote: > > > > Hi Marek > > > > Thanks for pointing this out. Typically we expect any timing sensitive secure operations to be implemented at Secure-EL1 or lower, which the current code does protect. However, you are correct that all secure world code including EL3 should not expose timing information. A fix is in progress to address this. > > > > Regards > > > > Dan. > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > > > Bykowski via TF-A > > > Sent: 03 August 2019 07:37 > > > To: tf-a(a)lists.trustedfirmware.org; David Cunado <David.Cunado(a)arm.com> > > > Subject: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the > > > PMCR_EL0 across world switching > > > > > > Hi David/ATF Support, > > > > > > An excerpt from the commit message to CVE-2017-15031 is "Additionally, > > > PMCR_EL0 is added to the list of registers that are saved and restored during > > > a world switch." > > > > > > My question is why it is only being saved/restored across the world switch > > > and not during a "normal" SMC call? When I do modify the > > > PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter > > > counts during the smc call and does expose secure world timing information to > > > NonSecure in that matter. > > > > > > Thanks, > > > Marek > > > -- > > > TF-A mailing list > > > TF-A(a)lists.trustedfirmware.org > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > 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. > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > -- > Slán, > Marek > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- Slán, Marek -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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, 9 months

1
0
0 0

Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Marek

Hi Dan, Are there any time estimates when the fix should be in? Thanks, Marek On Sat, 10 Aug 2019 at 22:46, Marek via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Thank you Dan for checking this out. Looking forward into the fix. > > Marek > > On Thu, 8 Aug 2019 at 17:52, Dan Handley via TF-A > <tf-a(a)lists.trustedfirmware.org> wrote: > > > > Hi Marek > > > > Thanks for pointing this out. Typically we expect any timing sensitive secure operations to be implemented at Secure-EL1 or lower, which the current code does protect. However, you are correct that all secure world code including EL3 should not expose timing information. A fix is in progress to address this. > > > > Regards > > > > Dan. > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > > > Bykowski via TF-A > > > Sent: 03 August 2019 07:37 > > > To: tf-a(a)lists.trustedfirmware.org; David Cunado <David.Cunado(a)arm.com> > > > Subject: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the > > > PMCR_EL0 across world switching > > > > > > Hi David/ATF Support, > > > > > > An excerpt from the commit message to CVE-2017-15031 is "Additionally, > > > PMCR_EL0 is added to the list of registers that are saved and restored during > > > a world switch." > > > > > > My question is why it is only being saved/restored across the world switch > > > and not during a "normal" SMC call? When I do modify the > > > PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter > > > counts during the smc call and does expose secure world timing information to > > > NonSecure in that matter. > > > > > > Thanks, > > > Marek > > > -- > > > TF-A mailing list > > > TF-A(a)lists.trustedfirmware.org > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > 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. > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > -- > Slán, > Marek > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- Slán, Marek

5 years, 9 months

1
0
0 0

Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Marek

Thank you Dan for checking this out. Looking forward into the fix. Marek On Thu, 8 Aug 2019 at 17:52, Dan Handley via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Marek > > Thanks for pointing this out. Typically we expect any timing sensitive secure operations to be implemented at Secure-EL1 or lower, which the current code does protect. However, you are correct that all secure world code including EL3 should not expose timing information. A fix is in progress to address this. > > Regards > > Dan. > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > > Bykowski via TF-A > > Sent: 03 August 2019 07:37 > > To: tf-a(a)lists.trustedfirmware.org; David Cunado <David.Cunado(a)arm.com> > > Subject: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the > > PMCR_EL0 across world switching > > > > Hi David/ATF Support, > > > > An excerpt from the commit message to CVE-2017-15031 is "Additionally, > > PMCR_EL0 is added to the list of registers that are saved and restored during > > a world switch." > > > > My question is why it is only being saved/restored across the world switch > > and not during a "normal" SMC call? When I do modify the > > PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter > > counts during the smc call and does expose secure world timing information to > > NonSecure in that matter. > > > > Thanks, > > Marek > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > 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. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- Slán, Marek

5 years, 9 months

1
0
0 0

Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Dan Handley

Hi Marek Thanks for pointing this out. Typically we expect any timing sensitive secure operations to be implemented at Secure-EL1 or lower, which the current code does protect. However, you are correct that all secure world code including EL3 should not expose timing information. A fix is in progress to address this. Regards Dan. > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > Bykowski via TF-A > Sent: 03 August 2019 07:37 > To: tf-a(a)lists.trustedfirmware.org; David Cunado <David.Cunado(a)arm.com> > Subject: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the > PMCR_EL0 across world switching > > Hi David/ATF Support, > > An excerpt from the commit message to CVE-2017-15031 is "Additionally, > PMCR_EL0 is added to the list of registers that are saved and restored during > a world switch." > > My question is why it is only being saved/restored across the world switch > and not during a "normal" SMC call? When I do modify the > PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter > counts during the smc call and does expose secure world timing information to > NonSecure in that matter. > > Thanks, > Marek > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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, 9 months

1
0
0 0

On supporting unmaintained platforms and downstream projects

by Julius Werner

Hi Soby et. al., I wanna kick off a little discussion about how TF-A intends to deal with in-tree platform ports as they get older and the interest in maintaining them drops off. Concretely, I noticed that the plat/nvidia/tegra platforms no longer build since the removal of the deprecated console API in https://review.trustedfirmware.org/842 last month. There has been a patch suggestion to fix it uploaded at https://review.trustedfirmware.org/1192 for two months, but it hasn't moved forward because it seems that Arm thinks it's on the platform maintainer (Nvidia) to finish up and test the patch, and they don't seem to be responding. This creates a problem for downstream projects like coreboot and Chrome OS that use Trusted Firmware on Tegra chips and build-test them in their CI systems. My assumption when setting up the Trusted Firmware integration for them was that the Trusted Firmware CI would build test all in-tree platforms for every commit anyway, so we could always assume that all platforms build on the current master... but clearly, that assumption broke in this case. (I guess because you manually overrode the CI in https://review.trustedfirmware.org/842? Or does it not test all platforms anyway?) So now, coreboot is stuck on an old TF-A version and cannot move forward for any platform until we either kick out the Tegra SoCs or get the problem fixed in TF-A (which is a problem with the testing because I don't have a Tegra board on hand either). How do you think we should solve issues like this? Is keeping platforms that don't build in the tree an intended state? Is there some deadline after which you intend to remove the platform completely? Or would it be better to just merge "best effort" commits like https://review.trustedfirmware.org/1192 that we think should do the right thing for the platform (and at least makes it build again), even if nobody is around to test it on real hardware? To give some experience from the coreboot project, I think it's an unfortunate truth that SoC vendors just tend to lose interest in maintaining hardware once it's more than 2-3 years old. At that point the open-source community has to jump in to continue maintenance, and they can only do it on a best effort basis. It's not possible to always find someone with the right hardware and time to test it for all these old platforms whenever you're trying to do some large, project wide API change, so eventually you'll just have to accept patches that haven't been tested for them. Most of the times (if reviewers pay attention) it works well, sometimes they break. If they do, eventually someone will notice and then they'll have to bisect and fix it. I believe Linux is essentially doing the same thing for lesser-used hardware. It's either that, or you have to constantly kick out old platforms after a few years. (From the coreboot point of view, kicking the Tegra platforms out of TF-A would mean we're forced to remove them from coreboot as well, which would be unfortunate.) Let me know what you think! Julius

5 years, 9 months

3
4
0 0

Re: [TF-A] On supporting unmaintained platforms and downstream projects

by Joanna Farley

Hi Julius, It’s a valid issue you have raised. In general we rely on the platform maintainer to work with us to keep their platform port fresh and in this case we proposed some changes and was looking for feedback from the maintainer. We try in our internal standups at least once a week to look for patch reviews that have had no work on them for 21 days and if we do identify any we start chasing to progress these. Eventually if after several attempts we cannot get the patch to progress we would generally look to abandon if it’s the patch originator we cannot contact. In this case it was the platform maintainer who we needed a review from and you managed to get Varun to notice the patches. If we had not managed to contact them then we would have had to make a call on if to submit the changes or not to at least get the build working even though we would not be able to test them. I would like to think in the case of a broken build we would take that option rather than abandon. I think this issue is made a little worse in that the CI results are not yet open so not obvious to everybody although hopefully that will be eventually addressed with the proposed Open CI system on trustedfirmware.org where build results will be available. On top of that if partners want to engage in providing a board available that could be integrated into the LAVA farm that’s part of the CI system and would also be tested. Joanna On 03/08/2019, 01:10, "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: > Thanks for the email, Julius. To be clear, we very well intend to be part of the TF-A project. Having said that, I was not aware of the two commits you mentioned in the email and di not know that Tegra builds are broken in the master branch. Thanks. You were CCed on the patch so I assumed you would've seen it. If not, maybe your email address isn't set correctly in your Gerrit account or something? I've already pushed an update to https://review.trustedfirmware.org/1192 which I think should fix the issue for Tegra, but I need someone to test it. Nevertheless, I think it's a good idea to answer these questions in a general case (e.g. whether we can make sure that we won't break the build on master even if there are temporary issues with certain platforms), because it's probably going to become relevant again sooner or later even if the Tegra issue gets fixed now. 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, 9 months

1
0
0 0

Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Marek Bykowski

Hi David/ATF Support, An excerpt from the commit message to CVE-2017-15031 is "Additionally, PMCR_EL0 is added to the list of registers that are saved and restored during a world switch." My question is why it is only being saved/restored across the world switch and not during a "normal" SMC call? When I do modify the PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter counts during the smc call and does expose secure world timing information to NonSecure in that matter. Thanks, Marek

5 years, 9 months

1
0
0 0

Raspberry Pi 4 ATF port

by Andre Przywara

Hi, (BCC:ing Antonio as well) not sure if someone gets notified, but I pushed a patch set to add Raspberry Pi 4 support to Trusted Firmware: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1629 This port is quite a departure from the existing RPi3 port, that's why I wanted to start a discussion about it here. I originally started by copying files. But for the sake of simplicity, also to get away without a BL33 loader, it turned into just a BL31-only port (for now?). This ties more into the existing RPi Foundation boot style, as the resulting bl31.bin is a drop-in replacement for the existing armstub8.bin. So you put your AArch64 kernel into kernel8.img and copy bl31.bin to armstub8.bin (or use the respective config.txt options to point to any other filename), and it should work (TM). The code will pick up the actual kernel and DTB load address from the GPU firmware, patch the DT to use PSCI instead of spin tables, then will drop into EL2 at the kernel load address. There could (should?) be U-Boot or EDK-II there as well, or any other kernel, for that matter. The only thing Linux specific we do is to put the DTB address into x0. I guess this doesn't hurt, even if the BL33 payload does not use this information. I would be grateful to hear some opinions about this approach. Does that sound sensible? Is the split of the platform directory (plat/rpi3 -> plat/rpi/rpi[34]) reasonable? Shall we add this design as a build option to RPi3 as well? Shall we add the "full featured" RPi3 design to RPi4 also? Looking forward to any feedback! Cheers, Andre.

5 years, 9 months

3
2
0 0

Re: [TF-A] Defects detected by Coverity Scan Online

by Sandrine Bailleux

Hi, On 7/3/19 11:15 AM, Sandrine Bailleux via TF-A wrote: > We would need help from the TF-A community for analyzing and fixing > them, especially those in platform ports and drivers. Note that there > might be false positives, in which case we would just triage them as > such in the tool's database. > > Hopefully everyone should be able to view the defects, according to the > tool's settings. You might need to create an account on > https://scan.coverity.com for that. We've received a couple of requests from users to get access to the TF-A defects database in the Coverity Scan Online service. I think it's worth clarifying the different levels of access the tool offers and how we envisage the defects triaging. In Coverity Scan Online, users can have any of the following 4 roles (in ascending order of permissions): - Observer/User: Only sees defects summary. - Defect Viewer. - Contributor/Member: Can also triage defects. - Maintainer/Owner: Also has some admin powers, like managing users and submitting builds to be analyzed. Right now, all users should be able to see the project summary and view the defects in read-only mode so this is equivalent to the "Defect viewer" role. I suspect people still need to create an account in Coverity Scan Online and be logged in to see the data. We would expect subsystems and platforms maintainers (i.e. people listed in docs/maintainers.rst [1]) to manage the defects in the part of the codebase they own, as they know best how to assess the severity of these defects and how to fix or triage them. As such, they need to have the "contributor/member" role in the tool. If you are such a maintainer, please feel free to create an account and request this role. If you would like to delegate part/all of the triaging process to a peer, that is also possible. In this case, could you please send me an email to indicate who you have chosen for this task? This is just to make sure that whoever requests the "contributor/member" role has done so with the relevant maintainer's approval. Please be aware that those with "contributor/member" role will be able to triage any defects in any part of the codebase, and not just in the subsystem/platform they maintain. "Maintainer/Owner" role will be reserved to the main maintainers (i.e. people listed at the top of docs/maintainers.rst) for now. Best regards, Sandrine [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/maint…

5 years, 10 months

1
0
0 0

Re: [TF-A] How can I check detail error of CI failure?

by Sandrine Bailleux

Hi Jun, On 7/16/19 11:30 AM, John Tsichritzis via TF-A wrote: > Thank you for your email. Unfortunately detailed information is not available in Gerrit since CI is hosted internally. The maintainers post detailed information of the errors in case there is something that needs fixing. In this case I will post the error details in the Gerrit review itself. > > When a patch stack is submitted, usually we launch the tests on the topmost patch on the stack. In this case the entire branch gets tested, not a single commit. In other words, the testing doesn't do any "cherry-picking" on the patches, so even if there are dependencies between the patches this doesn't affect the test. That's why we usually launch the tests on the topmost patch. To add on top of what John said, I would like to mention that we are working with Linaro to have the CI loop opened up to all contributors in the future. When this day comes, you will be able to check the error log by yourself. In the meantime, I'm afraid you'll have to rely on Arm maintainers to give you the details, as John said. If they forget, please feel free to ping them in Gerrit (like you've already done for this patch). Best regards, Sandrine

5 years, 10 months

1
0
0 0

Re: [TF-A] How can I check detail error of CI failure?

by John Tsichritzis

Dear Jun, Thank you for your email. Unfortunately detailed information is not available in Gerrit since CI is hosted internally. The maintainers post detailed information of the errors in case there is something that needs fixing. In this case I will post the error details in the Gerrit review itself. When a patch stack is submitted, usually we launch the tests on the topmost patch on the stack. In this case the entire branch gets tested, not a single commit. In other words, the testing doesn't do any "cherry-picking" on the patches, so even if there are dependencies between the patches this doesn't affect the test. That's why we usually launch the tests on the topmost patch. Kind regards, John -- John Tsichritzis | Graduate Software Engineer Email: john.tsichritzis(a)arm.com<mailto:john.tsichritzis@arm.com> 110 Fulbourn Road, Cambridge, CB1 9NJ, United Kingdom https://www.arm.com/ On 16/07/2019 09.24, Jun Nie via TF-A wrote: Hi, I see below failure in this link: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1367 How can I check the error log? I am not sure it is due to lack of earlier patch in patch set or something. Because local build is OK. Patch Set 4: Verified-1 Build Failed https://jenkins.oss.arm.com/job/tf-gerrit-tforg-l1/221/ : FAILURE Jun

5 years, 10 months

1
0
0 0

How can I check detail error of CI failure?

by Jun Nie

Hi, I see below failure in this link: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1367 How can I check the error log? I am not sure it is due to lack of earlier patch in patch set or something. Because local build is OK. Patch Set 4: Verified-1 Build Failed https://jenkins.oss.arm.com/job/tf-gerrit-tforg-l1/221/ : FAILURE Jun

5 years, 10 months

1
0
0 0

Header file re-org

by Soby Mathew

Hi Everyone, This is regarding the header file re-organization patch that was submitted by Julius https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/1207/. It is necessary for the headers which form the ABI/handover interface for BL31 to be able to copied separately and included in other projects. The current approach taken in the patch is to define a "raw" version of such headers and have the original header include them. This certainly is the easiest way to solve the problem. But if it possible to have a more refined solution, that would be preferable. For that I have the following questions : 1. Should the project recognize these special headers and have them organized together in a folder ? It is important to recognize that the ABI can be extended by the platform. I would expect even if these "common" headers are organized into a folder, the platform specific ones need not go together with them. 2. Should the header be restricted from including standard C library headers ? 3. Should these ABI headers be allowed to include each other ? Forward declaration might be able to solve some of the issues, but good to have a policy on this. The current patch as such can be treated as step towards the ideal solution, if that solution needs more work/churn in the code base. Comments welcome. Best Regards Soby Mathew

5 years, 10 months

3
8
0 0

Re: [TF-A] [RFC] isolate the memory into different pagetable for TF-A

by feng chen

Hi Soby Mathew, Thanks for your reply. IMHO, the isolate pagetable is much more heavy. It looks like a big idea. And if we have a dynamic mapping function, which map the service's needed memory in the service's call can also mitigate this. But this can be more slower. For accessing limited resource, what's your idea? -Feng On 2019/7/9 4:27 下午, Soby Mathew wrote: > Hi Feng, > Thanks for your email. This is an interesting topic and this is an active area of work for us but in a slightly different manner. Could you please send this message to the mailing list tf-a(a)lists.trustedfirmware.org , so we can continue conversation on the list ? > > The mailing list info can be found here : > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > Thanks & Regards > Soby Mathew > >> -----Original Message----- >> From: feng chen <puck.chen(a)foxmail.com> >> Sent: 08 July 2019 16:24 >> To: Dan Handley <Dan.Handley(a)arm.com>; Soby Mathew >> <Soby.Mathew(a)arm.com>; Sandrine Bailleux <Sandrine.Bailleux(a)arm.com>; >> Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Paul Beesley >> <Paul.Beesley(a)arm.com>; John Tsichritzis <John.Tsichritzis(a)arm.com> >> Subject: [RFC] isolate the memory into different pagetable for TF-A >> >> Hello maintainers, >> >> Is it possible for mapping the memory into different page-tables for TF-A? >> >> Since the ATF is running in EL3 mode, which is the highest level of ARM SoCs. >> >> And for security reason, once one service provided in TF has some >> vulnerabilities, It can access all the memory TF mapped. And it could be more >> acceptable. >> >> Thinking about the userland goto kernelland, the process use isolated page >> tables. >> >> So I want to implement this for TF-A, different memory-mapping for different >> service, and it can also use a shared mem-mapping space which all the service >> need to use. >> >> >> I want to know how do you think about this? Does this make sense to you? >> >> >> Cherrs, >> >> Feng >> > > 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, 10 months

2
1
0 0

Re: [TF-A] [RFC] isolate the memory into different pagetable for TF-A

by Chen Feng

Move this folk to list > 在 2019年7月9日，下午4:27，Soby Mathew <Soby.Mathew(a)arm.com> 写道： > > Hi Feng, > Thanks for your email. This is an interesting topic and this is an active area of work for us but in a slightly different manner. Could you please send this message to the mailing list tf-a(a)lists.trustedfirmware.org , so we can continue conversation on the list ? > > The mailing list info can be found here : > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > Thanks & Regards > Soby Mathew > >> -----Original Message----- >> From: feng chen <puck.chen(a)foxmail.com> >> Sent: 08 July 2019 16:24 >> To: Dan Handley <Dan.Handley(a)arm.com>; Soby Mathew >> <Soby.Mathew(a)arm.com>; Sandrine Bailleux <Sandrine.Bailleux(a)arm.com>; >> Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Paul Beesley >> <Paul.Beesley(a)arm.com>; John Tsichritzis <John.Tsichritzis(a)arm.com> >> Subject: [RFC] isolate the memory into different pagetable for TF-A >> >> Hello maintainers, >> >> Is it possible for mapping the memory into different page-tables for TF-A? >> >> Since the ATF is running in EL3 mode, which is the highest level of ARM SoCs. >> >> And for security reason, once one service provided in TF has some >> vulnerabilities, It can access all the memory TF mapped. And it could be more >> acceptable. >> >> Thinking about the userland goto kernelland, the process use isolated page >> tables. >> >> So I want to implement this for TF-A, different memory-mapping for different >> service, and it can also use a shared mem-mapping space which all the service >> need to use. >> >> >> I want to know how do you think about this? Does this make sense to you? >> >> >> Cherrs, >> >> Feng >> > > 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, 10 months

1
0
0 0

Defects detected by Coverity Scan Online

by Sandrine Bailleux

Hello, As you may be aware, Trusted Firmware-A source code regularly gets analyzed by Coverity Scan Online [1]. This is a free service offered by Synopsys for open source projects, that TF-A has used since 2015. The analysis currently gets driven by Arm's internal CI system. We've recently made some improvements to this setup, which led to the tool analyzing more files. The latest analysis report from this morning shows 65 newly-found defects, scattered across the code base. We would need help from the TF-A community for analyzing and fixing them, especially those in platform ports and drivers. Note that there might be false positives, in which case we would just triage them as such in the tool's database. Hopefully everyone should be able to view the defects, according to the tool's settings. You might need to create an account on https://scan.coverity.com for that. Best regards, Sandrine [1] https://scan.coverity.com/projects/arm-software-arm-trusted-firmware

5 years, 10 months

1
0
0 0

Why is assembly macro used for registering multi-console driver?

by Masahiro Yamada

Hi, Probably, I should have asked this before pushing my code. I have a question about finalize_console_register. Platforms call console_*_register() from C code. I do not know why we need to fill the callbacks in the assembler macro, finalize_console_register. We could call console_register() directly from C code, like this: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1426/3/plat/… Maybe, we may want to register the console so early in order to enable plat/common/aarch64/crash_console_helpers.S in the boot-up code?

5 years, 10 months

2
1
0 0

Re: [TF-A] Armv8A Suspend/Resume reference code

by Soby Mathew

> -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Gutierrez, > Hernan Ildefonso (Boise R&D, FW) via TF-A > Sent: 24 June 2019 22:35 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Armv8A Suspend/Resume reference code > > Hi, > > I am looking for reference code for ArmV8A core suspend/resume. > Are there code references that are suggested to look for? > Application notes to read? > Hi Hernan, The PSCI Spec[1] specifies power management on ARM CPUs and this includes suspend and resume. The TF-A provides an implementation of PSCI with appropriate hooks to plug-in in platform specifics. There are documents in the `docs` folder which cover different aspects of PSCI implementation like PSCI topology [2], CPU specifics [3], and platform porting guide [4]. In terms of adding support for a new platform, it is most likely that all the architectural (as in ARMv8A reference manual) and the CPU specific power management as specified in the TRM are covered already (see lib/cpus/ folder for CPUs already supported). So it’s a matter of implementing the platform hooks as mentioned in the porting guide [4]. With respect to implementing platform hooks, the ARM reference platforms like FVP provide an example of how the hooks can be implemented (see fvp_pm.c/fvp_topology.c ). So if you platform is a GICv3 system and the power controller already uses SCMI as the protocol for communication, then most of the code in FVP can be reused for your platform. Hope that provides a starting point for you to begin. [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coord… [2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/desi… [3] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/desi… (see CPU specific operations framework) [4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/gett… (see Power State Coordination Interface) > Any pointers will be appreciated, thanks. > > Hernan > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 10 months

1
0
0 0

Armv8A Suspend/Resume reference code

by Gutierrez, Hernan Ildefonso (Boise R&D, FW)

Hi, I am looking for reference code for ArmV8A core suspend/resume. Are there code references that are suggested to look for? Application notes to read? Any pointers will be appreciated, thanks. Hernan

5 years, 10 months

1
0
0 0

Re: [TF-A] New console interface porting examples

by Soby Mathew

Hi, We are planning merge the patch removing support for legacy console support this week. This is a gentle reminder for platforms not yet migrated to the MULTI_CONSOLE_API. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Ambroise > Vincent via TF-A > Sent: 31 May 2019 10:40 > To: jens.wiklander(a)linaro.org; yamada.masahiro(a)socionext.com; > siva.durga.paladugu(a)xilinx.com; vwadekar(a)nvidia.com; > bryan.odonoghue(a)linaro.org; jun.nie(a)linaro.org > Cc: tf-a(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: [TF-A] New console interface porting examples > > Hi, > > An update on the new console API > (https://github.com/ARM-software/tf-issues/issues/692): > > You will find patches below for the platforms that haven't done the migration > to the new interface yet, in order to give them something to test and > potentially adapt if it doesn't work as intended. The commits are independent > from each other and can be easily cherry-picked. > > Tegra: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1192/ > > Zynqmp: https://review.trustedfirmware.org/c/TF-A/trusted-firmware- > a/+/1193/ > > Uniphier: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1194/ > > Qemu: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1195/ > > Warp7: a very small patch to look at, removing a soon to be deleted legacy file > from the platform makefile: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1191/ > > > As you know, the old interface is going to be removed at the end of June > by https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/842/ > > > Regards > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 10 months

2
1
0 0

Re: [TF-A] Can 1 Core in EL3 elevate other 3 cores to EL3?

by Soby Mathew

> -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Thor > Thayer via TF-A > Sent: 20 June 2019 09:05 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Can 1 Core in EL3 elevate other 3 cores to EL3? > > Hi, > > I have a quad-core ARM64 Cortex-A53 where 1 core is executing in EL3 while > the other 3 cores are in EL1. The 3 cores in EL1 are spinning in a WFI loop. The > EL3 CPU transitioned to EL3 as a result of the PSCI RESET2 call from Linux. > > Is there a way for the EL3 core to switch the other cores into EL3 easily? Hi Thor, One way to do this to configure an IPI (SGI in GICv3 terminology) to be an EL3 interrupt (Group 0). Trigger this IPI from the first core to all the other 3 cores. This will cause the 3 cores to transition to EL3 to handle the EL3 interrupt and you will have to configure a suitable interrupt handler. Implication of this new EL3 IPI is that it can also cause the core to transition to EL3 if triggered when executing in Secure world. Also be aware that configuration of any EL3 interrupt will affect the routing model and change the behaviour of normal world interrupts when executing in Secure world. The secure world executing a "yielding" SMC request will get pre-empted on occurrence of normal world interrupt and the secure world may not get a chance to do a "controlled exit". Usually the PSCI_RESET2 can work without all the cores being in EL3. Could you elaborate why the other cores need to be in EL3 for this reset? > > As far as I know, the communication between cores takes place through the IPI. > Unfortunately, in my case, an SError has occurred that is masking the IPI. > If I understand correctly, the PSCI_RESET2 is being issued after the SError has happened on other cores. The EL3 IPI should cause these cores to transition to EL3 regardless of the interrupt mask state at lower Els. > Thanks, > > Thor > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 11 months

2
1
0 0

Can 1 Core in EL3 elevate other 3 cores to EL3?

by Thor Thayer

Hi, I have a quad-core ARM64 Cortex-A53 where 1 core is executing in EL3 while the other 3 cores are in EL1. The 3 cores in EL1 are spinning in a WFI loop. The EL3 CPU transitioned to EL3 as a result of the PSCI RESET2 call from Linux. Is there a way for the EL3 core to switch the other cores into EL3 easily? As far as I know, the communication between cores takes place through the IPI. Unfortunately, in my case, an SError has occurred that is masking the IPI. Thanks, Thor

5 years, 11 months

1
0
0 0

Re: [TF-A] Arm trusted firmware reads wrong fip file from flash on hikey960v2

by Soby Mathew

> -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of David > Cerdeira via TF-A > Sent: 04 June 2019 10:04 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Arm trusted firmware reads wrong fip file from flash on > hikey960v2 > > Greetings, > i’m having trouble getting arm trusted firmware to work on hikey960v2 I > followed all the steps in this guide https://github.com/ARM-software/arm- > trusted-firmware/blob/master/docs/plat/hikey960.rst, > and the steps in https://optee.readthedocs.io/building/devices/hikey960.html > The problem seems to be in reading the fip.bin, or rather the problem is > writing the fip file as it seems it is not properly flashed. > ATF bl2 fails to find the UUID of the BL2_SCP image in the fip.bin output by the > build process, the fip file it reads from flash only has the BL31 and BL33 UUIDs. > > I tried checking older versions of ATF, as I figured it might be a problem in > current versions, but the same problems occurred. Hi David, I don’t have much insight into platform specifics. One suggestion is to try with pre-built binaries and once they are working, replace with your custom ones. This page may help : http://releases.linaro.org/96boards/hikey/linaro/debian/15.11/ The Hikey Platform maintainers may be able to help more in this regard. Best Regards Soby Mathew > > At this moment I feel the problem is in the flashing step. > I tried moving the partitions in the partition tables, as well as the value of the > macro HIKEY960_FIP_BASE present in hikey960_def.h to match what I thought > would be the writing position of the file in the partition, but without success. > > If anyone could give me any idea as to what the problem might be, that’d be > great Best regards, David Cerdeira > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A