- TF-A - lists.trustedfirmware.org

Protecting Secure World Translation Tables

by Petre-Ionut Tudor

Hello Everyone, For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map. A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-andro…. A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only. It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant. Best wishes Petre 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, 2 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 354061: Memory - illegal accesses (OVERRUN) /plat/amlogic/axg/axg_pm.c: 124 in axg_pwr_domain_off() ________________________________________________________________________________________________________ *** CID 354061: Memory - illegal accesses (OVERRUN) /plat/amlogic/axg/axg_pm.c: 124 in axg_pwr_domain_off() 118 PLAT_LOCAL_STATE_OFF); 119 120 axg_pm_reset(mpidr, -1); 121 122 gicv2_cpuif_disable(); 123 >>> CID 354061: Memory - illegal accesses (OVERRUN) >>> Overrunning array "target_state->pwr_domain_state" of 2 bytes at byte offset 2 using index "2ULL". 124 if (target_state->pwr_domain_state[MPIDR_AFFLVL2] == 125 PLAT_LOCAL_STATE_OFF) 126 system_state = SCPI_POWER_OFF; 127 128 if (target_state->pwr_domain_state[MPIDR_AFFLVL1] == 129 PLAT_LOCAL_STATE_OFF) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 2 months

1
0
0 0

TF-A on iMX8M Mini

by Iñigo Vicente Waliño

Hi, I am using an iMX8M mini, I have flashed the image with uuu.auto of L4.14.98_2.0.0_ga_images_MX8MMEVK and I have a Linux image with OP-TEE. Now I want to use TF-A but I don't know the steps to continue. I am reading this document ( https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4/gui… and https : //trustedfirmware-a.readthedocs.io/en/latest/plat/imx8m.html <https://trustedfirmware-a.readthedocs.io/en/latest/plat/imx8m.html>) but I don't know how to get these files: u-boot.bin, u-boot-nodtb.bin, u-boot-spl.bin , DTB U-Boot file (for example, fsl-imx8mq-evk.dtb). Can anyone tell me the steps to follow? Thanks, best regards Iñigo.

5 years, 2 months

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 354003: Integer handling issues (NO_EFFECT) /drivers/arm/css/scp/css_pm_scmi.c: 228 in css_scp_on() ________________________________________________________________________________________________________ *** CID 354003: Integer handling issues (NO_EFFECT) /drivers/arm/css/scp/css_pm_scmi.c: 228 in css_scp_on() 222 SCMI_SET_PWR_STATE_LVL(scmi_pwr_state, lvl, 223 scmi_power_state_on); 224 225 SCMI_SET_PWR_STATE_MAX_PWR_LVL(scmi_pwr_state, lvl - 1); 226 227 core_pos = plat_core_pos_by_mpidr(mpidr); >>> CID 354003: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "core_pos >= 0U". 228 assert(core_pos >= 0 && (core_pos < PLATFORM_CORE_COUNT)); 229 230 css_scp_core_pos_to_scmi_channel(core_pos, &domain_id, 231 &channel_id); 232 ret = scmi_pwr_state_set(scmi_handles[channel_id], 233 domain_id, scmi_pwr_state); ** CID 354002: Memory - corruptions (OVERRUN) /plat/arm/css/sgi/sgi_bl31_setup.c: 80 in plat_css_get_scmi_info() ________________________________________________________________________________________________________ *** CID 354002: Memory - corruptions (OVERRUN) /plat/arm/css/sgi/sgi_bl31_setup.c: 80 in plat_css_get_scmi_info() 74 scmi_channel_plat_info_t *plat_css_get_scmi_info(int channel_id) 75 { 76 if (sgi_plat_info.platform_id == RD_N1E1_EDGE_SID_VER_PART_NUM || 77 sgi_plat_info.platform_id == RD_DANIEL_SID_VER_PART_NUM) { 78 if (channel_id >= sizeof(rd_n1e1_edge_scmi_plat_info)) 79 panic(); >>> CID 354002: Memory - corruptions (OVERRUN) >>> "&rd_n1e1_edge_scmi_plat_info[channel_id]" evaluates to an address that is at byte offset 1560 of an array of 40 bytes. 80 return &rd_n1e1_edge_scmi_plat_info[channel_id]; 81 } 82 else if (sgi_plat_info.platform_id == SGI575_SSC_VER_PART_NUM) 83 return &sgi575_scmi_plat_info; 84 else 85 panic(); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 2 months

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 353989: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 353989: Integer handling issues (INCOMPATIBLE_CAST) /plat/intel/soc/common/socfpga_psci.c: 138 in socfpga_system_reset() 132 133 extern uint64_t intel_rsu_update_address; 134 135 static void __dead2 socfpga_system_reset(void) 136 { 137 if (intel_rsu_update_address) >>> CID 353989: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&intel_rsu_update_address" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 138 mailbox_rsu_update((uint32_t *)&intel_rsu_update_address); 139 else 140 mailbox_reset_cold(); 141 142 while (1) 143 wfi(); ** CID 353988: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 353988: Integer handling issues (INCOMPATIBLE_CAST) /plat/intel/soc/common/socfpga_sip_svc.c: 526 in sip_smc_handler() 520 521 case INTEL_SIP_SMC_RSU_NOTIFY: 522 status = intel_rsu_notify(x1); 523 SMC_RET1(handle, status); 524 525 case INTEL_SIP_SMC_RSU_RETRY_COUNTER: >>> CID 353988: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "rsu_respbuf" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 526 status = intel_rsu_retry_counter((uint32_t *)rsu_respbuf, 527 ARRAY_SIZE(rsu_respbuf), &val); 528 if (status) { 529 SMC_RET1(handle, status); 530 } else { 531 SMC_RET2(handle, status, val); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 2 months

1
0
0 0

FIP header flags available for feature selection

by Scott Branden

Hello, The fip header has reserved fields available for platform specific use. The fiptool allows these header fields to be filled in using the --plat-toc-flags. A call needs to be available in the ATF framework to get these flags without accessing the FIP file again to get these flags. We have a solution we've used for ATF for quite some time to access these flags. It's finally being upstreamed here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2839 If there are any other efficient methods to access these flags or a better proposal please suggest. Thanks, Scott

5 years, 2 months

1
0
0 0

Re: [TF-A] [EXT] RE: Issue with addition of NXP Platform support on TFA v2.2

by Alexei Fedorov

Hi Pankaj, Would it be possible to provide more information on your platform (what CPU, its revision, number of clusters/CPUs per cluster, etc.)? Is your platform code publically available? Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Pankaj Gupta via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 07 February 2020 10:57 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; nd <nd(a)arm.com> Subject: Re: [TF-A] [EXT] RE: Issue with addition of NXP Platform support on TFA v2.2 Hi, Please find the comments in-line. Regards Pankaj -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Wednesday, February 5, 2020 6:54 PM To: Pankaj Gupta <pankaj.gupta(a)nxp.com> Cc: nd <nd(a)arm.com>; tf-a(a)lists.trustedfirmware.org Subject: [EXT] RE: Issue with addition of NXP Platform support on TFA v2.2 >Caution: EXT Email >Hi Pankaj, >Can you pls provide a bit more background: >Which boot stage (BL1/BL2/BL31...) get affected? BL2 >Is there any crash report to console? No. But, using the external debugger, it is found that core gets to non-responding. >Is this an aarch64/or aarch32 platform? aarch64 >There can be different root causes to this e.g. >1. a stale translation in TLB, or a dirty cache line remnant from earlier boot stages. If this is the case, it would need invalidating TLB and/or caches on BL entry. >2. the empty table ptr given by xlat_table_get_empty is pointing nowhere sensible because of this specific platform layout >There are multiple calls to xlat_clean_dcache_range in this file, do you confirm the crash happen within xlat_tables_map_region? Yes. Basis of saying 'yes' is: if this function is commented, the BL2 comes up successfully. Flow in the code base is : mmap_add_dynamic_region -> mmap_add_dynamic_region_ctx -> xlat_tables_map_region-> xlat_table_get_empty //....issue is seen. >Can you try one or both statements below after the call to xlat_table_get_empty (and uncomment calls to clean_dcache_range): > > inv_dcache_range((uintptr_t)subtable, XLAT_TABLE_SIZE); > > xlat_arch_tlbi_va((uintptr_t)subtable, ctx->xlat_regime); > xlat_arch_tlbi_va_sync(); mmap_add_dynamic_region -> mmap_add_dynamic_region_ctx -> xlat_tables_map_region-> xlat_table_get_empty-> xlat_arch_tlbi_va //issue is resolved. The root cause of this issue is race condition. Please correct me if I am wrong. Another observation: mmap_add_dynamic_region -> mmap_add_dynamic_region_ctx (Putting console debug logs in this function)-> xlat_tables_map_region-> xlat_table_get_empty //issue is resolved. Please share your view for this observation as well. Regards, Olivier. -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Pankaj Gupta via TF-A Sent: 05 February 2020 11:45 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Issue with addition of NXP Platform support on TFA v2.2 Hi, In the TFA v2.2 code base, the file "lib/xlat_tables_v2/xlat_tables_core.c" has the implementation for function "xlat_tables_map_region()". The implementation for this function is changed in TFAv2.2 (compared TFAv1.5), with addition of function "xlat_clean_dcache_range()". Due to this addition, my earlier* working platform on TFAv1.5, is hanging here. If the function call for the function "xlat_clean_dcache_range()", is comment, then the platform works well. Code snippet: static inline __attribute__((unused)) void xlat_clean_dcache_range(uintptr_t addr, size_t size) { if (is_dcache_enabled()) clean_dcache_range(addr, size); // On commenting this line, my platform works fine with TFAv2.2 } Please share your views on what could I be missing here. Thanks. Regards Pankaj *Earlier raised patch for this platform was not merged due to review comments are not disposed-off in time; and TF-A got migrated from github to gerrit. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- 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, 2 months

1
0
0 0

Re: [TF-A] Issue with addition of NXP Platform support on TFA v2.2

by Olivier Deprez

Hi Pankaj, Can you pls provide a bit more background: Which boot stage (BL1/BL2/BL31...) get affected? Is there any crash report to console? Is this an aarch64/or aarch32 platform? There can be different root causes to this e.g. 1. a stale translation in TLB, or a dirty cache line remnant from earlier boot stages. If this is the case, it would need invalidating TLB and/or caches on BL entry. 2. the empty table ptr given by xlat_table_get_empty is pointing nowhere sensible because of this specific platform layout There are multiple calls to xlat_clean_dcache_range in this file, do you confirm the crash happen within xlat_tables_map_region? Can you try one or both statements below after the call to xlat_table_get_empty (and uncomment calls to clean_dcache_range): inv_dcache_range((uintptr_t)subtable, XLAT_TABLE_SIZE); xlat_arch_tlbi_va((uintptr_t)subtable, ctx->xlat_regime); xlat_arch_tlbi_va_sync(); Regards, Olivier. -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Pankaj Gupta via TF-A Sent: 05 February 2020 11:45 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Issue with addition of NXP Platform support on TFA v2.2 Hi, In the TFA v2.2 code base, the file "lib/xlat_tables_v2/xlat_tables_core.c" has the implementation for function "xlat_tables_map_region()". The implementation for this function is changed in TFAv2.2 (compared TFAv1.5), with addition of function "xlat_clean_dcache_range()". Due to this addition, my earlier* working platform on TFAv1.5, is hanging here. If the function call for the function "xlat_clean_dcache_range()", is comment, then the platform works well. Code snippet: static inline __attribute__((unused)) void xlat_clean_dcache_range(uintptr_t addr, size_t size) { if (is_dcache_enabled()) clean_dcache_range(addr, size); // On commenting this line, my platform works fine with TFAv2.2 } Please share your views on what could I be missing here. Thanks. Regards Pankaj *Earlier raised patch for this platform was not merged due to review comments are not disposed-off in time; and TF-A got migrated from github to gerrit. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 2 months

2
1
0 0

Re: [TF-A] CI status update - end to end boot testing on Juno

by Matteo Carlini

Hi Fathi, Thanks for the below write-up, this is really great news! > Note: this is in silent mode (links to the build job are currently disabled, > and will be re-enableb today). Please go ahead in re-enabling those jobs, so that people can see the results of the build jobs (while we work on propagating back to Gerrit also the results of the LAVA boot jobs). Thanks Matteo > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Fathi > Boudra via TF-A > Sent: 05 February 2020 12:45 > To: TF-A(a)lists.trustedfirmware.org > Cc: Ryan Arnold <ryan.arnold(a)linaro.org> > Subject: [TF-A] CI status update - end to end boot testing on Juno > > Hi, > > The end-to-end testing prototype is now completed and enabled. > This encompases an end-to-end testing pipeline whereby TF-A code > submission to gerrit results in a TF build (based on the code submission) > being injected into a file system (recovery image) and booted on a Juno > device in the Linaro TF LAVA instance with the results of the boot test > available in the LAVA instance. > > Here's the explanation of the CI pipeline: > 1. Trigger - capture gerrit events: > https://ci.trustedfirmware.org/job/trigger-tf-a-builder/ > All changes made to the trusted-firmware A repository are captured by > the trigger event and result in a build. > e.g., triggering commit: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3100 > Note: this is in silent mode (links to the build job are currently disabled, > and will be re-enableb today). > 2. Build Binary Artifacts - Binary artifacts built via: > https://ci.trustedfirmware.org/job/tf-a-builder/ > e.g., https://ci.trustedfirmware.org/job/tf-a-builder/631/ > (with a link to the accompanying LAVA job and a link to the trigger job in > gerrit) 3. Recovery/Flash submission to LAVA - Used to flash the binary to the > board: > https://ci.trustedfirmware.org/job/post-build-lava/ > 4. LAVA tests results > e.g., Specific example of the template applied to a specific build > (631 above) > https://tf.validation.linaro.org/scheduler/job/895/definition > Results: https://tf.validation.linaro.org/results/895 > Link to all jobs: https://tf.validation.linaro.org/scheduler/alljobs > > Some additional information: > * tf-a-ci-scripts git repository has been set up and contains the CI scripts for > TF-A. > https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/ > * tf-a-job-configs git repository has been set up and contains the Jenkins jobs > configurations automatically deployed on https://ci.trustedfirmware.org > Jenkins instance. > https://git.trustedfirmware.org/ci/tf-a-job-configs.git/ > > Cheers, > -- > Fathi Boudra > Linaro.org | Open source software for ARM SoCs > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 2 months

1
0
0 0

CI status update - end to end boot testing on Juno

by Fathi Boudra

Hi, The end-to-end testing prototype is now completed and enabled. This encompases an end-to-end testing pipeline whereby TF-A code submission to gerrit results in a TF build (based on the code submission) being injected into a file system (recovery image) and booted on a Juno device in the Linaro TF LAVA instance with the results of the boot test available in the LAVA instance. Here's the explanation of the CI pipeline: 1. Trigger - capture gerrit events: https://ci.trustedfirmware.org/job/trigger-tf-a-builder/ All changes made to the trusted-firmware A repository are captured by the trigger event and result in a build. e.g., triggering commit: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3100 Note: this is in silent mode (links to the build job are currently disabled, and will be re-enableb today). 2. Build Binary Artifacts - Binary artifacts built via: https://ci.trustedfirmware.org/job/tf-a-builder/ e.g., https://ci.trustedfirmware.org/job/tf-a-builder/631/ (with a link to the accompanying LAVA job and a link to the trigger job in gerrit) 3. Recovery/Flash submission to LAVA - Used to flash the binary to the board: https://ci.trustedfirmware.org/job/post-build-lava/ 4. LAVA tests results e.g., Specific example of the template applied to a specific build (631 above) https://tf.validation.linaro.org/scheduler/job/895/definition Results: https://tf.validation.linaro.org/results/895 Link to all jobs: https://tf.validation.linaro.org/scheduler/alljobs Some additional information: * tf-a-ci-scripts git repository has been set up and contains the CI scripts for TF-A. https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/ * tf-a-job-configs git repository has been set up and contains the Jenkins jobs configurations automatically deployed on https://ci.trustedfirmware.org Jenkins instance. https://git.trustedfirmware.org/ci/tf-a-job-configs.git/ Cheers, -- Fathi Boudra Linaro.org | Open source software for ARM SoCs

5 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A