- TF-A - lists.trustedfirmware.org

by Ming Huang

Hi, We use TF-A v2.5 with ENABLE_SVE_FOR_NS=1 and SPM_MM=1 and boot linux kernel is ok. Atfer upgrade TF-A with patch fix(spm_mm): do not compile if SVE/SME is enabled (4333f95bedb), we set ENABLE_SVE_FOR_NS=0 to fix compile error, but we get exception and hang in EL3 when boot kernel: ----------------------------------------------------------------------------------- [ 0.000000] Linux version 5.10.23-003debug.ali5000.alios7.aarch64 (root(a)j66e01291.sqa.eu95) (gcc (GCC) 10.2.1 20200825 (Alibaba 10.2.1-3 2.17) ...... [ 0.000000] pcpu-alloc: [1] 80 [1] 81 [1] 82 [1] 83 [1] 84 [1] 85 [1] 86 [1] 87 [ 0.000000] pcpu-alloc: [1] 88 [1] 89 [1] 90 [1] 91 [1] 92 [1] 93 [1] 94 [1] 95 ERROR: Excepton received on 0x81000000, spsr_el3:89,reason:1 esr_el3:0x66000000 Exception Class = 19: Access to SVE functionality trapped as a result of CPACR_EL1.ZEN,CPTR_EL2.ZEN, CPTR_EL2.TZ, or CPTR_EL3.EZ. ----------------------------------------------------------------------------------- How to fix the exception issue? Can we remove the below lines? ifeq (${ENABLE_SVE_FOR_NS},1) $(error "Error: SPM_MM is not compatible with ENABLE_SVE_FOR_NS") endif Regards, Ming Huang

3 years, 10 months

2
2
0 0

Trusted Firmware-A v2.7 release activities in May

by Daniel Boulby

TF-A Community, This is to notify that we are planning to target the Trusted Firmware-A 2.7 release during the 4th week of May as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.6 release. As part of this, a release candidate tag will be created and release activities will commence from 23rd May across all TF-A repositories. Essentially, we will not merge any major enhancements from this date until the release is made. Please ensure any patches desired to make the 2.7 release are submitted in good time to be complete by 20th May. Any major enhancement patches still open after that date will not be merged until after the release. This will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Jobs. We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start. Thanks, Daniel

3 years, 10 months

1
0
0 0

Issue in HW config consumption by secure BL components

by Manish Badarkhe

Hi All, Currently, in Arm platforms, BL2 loads HW config in the non-secure memory so that it can be consumed by both non-secure components (BL33) and secure (BL31, BL32) components. In most cases, this shouldn't be an issue since no software runs in non-secure world at this time (i.e. non-secure world has not been started yet) However, it doesn't provide a guarantee though since any malicious external NS-agents (such as an external debugger)can take control of this memory region for update/corruption after BL2 loads this region and before BL31 consumes it. Consider below scenario: 1. BL2 loads HW_CONFIG from flash to NS DRAM. 2. BL2 authenticates HW_CONFIG in NS DRAM. 3. A malicious non-secure agent modifies the contents of HW_CONFIG in NS DRAM, such that it induces a different behaviour in BL31. 1. BL31 consumes HW_CONFIG without noticing it has changed. To overcome this issue, I created a patch [1] to load the HW-config into secure memory, and that eventually will be used by BL31/sp_min and BL32 components. Additionally, BL31/sp_min copies the HW-config present in secure memory to a non-secure location before passing it on to BL33. In order to accomplish this, mapped secure DRAM in BL31/sp_min and BL32, and non-secure DRAM in BL31/sp_min. I believe some platforms may have similar kind of issue i.e. HW config placed in non-secure memory consumed by both secure and non-secure components. It is appreciated if you review the patch [1] I posted and provide feedback. This patch [1] also mitigates threat ID #3 for FVP platform as per the TF-A threat model [2] (Bypass image authentication scenario). [1]: https://review.trustedfirmware.org/q/topic:%22refactor-hw-config-load%22+(s… [2]: https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_mode… Thanks, Manish Badarkhe

3 years, 10 months

1
1
0 0

TF-A Tech-Forum Agenda for Thursday 05-May-22 at 4pm BST

by Bipin Ravi

Topic: FF-A v1.1 Boot protocol implementation Presented by: Joao Alves Agenda: This session presents the recently introduced FF-A v1.1 Boot protocol implementation, motivations and challenges. The change set spans across TF-A, Hafnium and TF-A-tests repositories. The presentation covers the TF-A build flow and Secure Partitions packaging, how Hafnium consumes the new SP package format and passes boot data to SPs. Link to changes: FF-A v1.1 boot protocol<https://review.trustedfirmware.org/q/topic:%22ja%252Fboot_protocol%22+(stat…> ================================================= We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/https://www.g… Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974https://www.google.com/url?q=https://zoom.us/j/… Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7hhttps://www.google.com/url?q=https://zoom.us/u/… Thanks & best regards, --Bipin Ravi

3 years, 10 months

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 378361: Null pointer dereferences (NULL_RETURNS) /plat/arm/board/fvp/fvp_bl2_setup.c: 84 in plat_get_next_bl_params() ________________________________________________________________________________________________________ *** CID 378361: Null pointer dereferences (NULL_RETURNS) /plat/arm/board/fvp/fvp_bl2_setup.c: 84 in plat_get_next_bl_params() 78 79 /* To retrieve actual size of the HW_CONFIG */ 80 param_node = get_bl_mem_params_node(HW_CONFIG_ID); 81 assert(param_node != NULL); 82 83 /* Copy HW config from Secure address to NS address */ >>> CID 378361: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "hw_config_info", which is known to be "NULL". 84 memcpy((void *)hw_config_info->ns_config_addr, 85 (void *)hw_config_info->config_addr, 86 (size_t)param_node->image_info.image_size); 87 88 /* 89 * Ensure HW-config device tree committed to memory, as there is ** CID 378360: (NULL_RETURNS) /plat/renesas/rzg/bl2_plat_setup.c: 411 in bl2_plat_handle_post_image_load() /plat/renesas/rcar/bl2_plat_setup.c: 446 in bl2_plat_handle_post_image_load() /plat/st/stm32mp1/bl2_plat_setup.c: 466 in bl2_plat_handle_post_image_load() /plat/renesas/rcar/bl2_plat_setup.c: 465 in bl2_plat_handle_post_image_load() /plat/renesas/rzg/bl2_plat_setup.c: 407 in bl2_plat_handle_post_image_load() /plat/st/stm32mp1/bl2_plat_setup.c: 472 in bl2_plat_handle_post_image_load() /plat/renesas/rcar/bl2_plat_setup.c: 448 in bl2_plat_handle_post_image_load() /plat/renesas/rcar/bl2_plat_setup.c: 440 in bl2_plat_handle_post_image_load() /plat/renesas/rzg/bl2_plat_setup.c: 397 in bl2_plat_handle_post_image_load() /plat/renesas/rzg/bl2_plat_setup.c: 404 in bl2_plat_handle_post_image_load() /plat/st/stm32mp1/bl2_plat_setup.c: 529 in bl2_plat_handle_post_image_load() ________________________________________________________________________________________________________ *** CID 378360: (NULL_RETURNS) /plat/renesas/rzg/bl2_plat_setup.c: 411 in bl2_plat_handle_post_image_load() 405 } 406 407 memcpy(&params->bl32_ep_info, &bl_mem_params->ep_info, 408 sizeof(entry_point_info_t)); 409 break; 410 case BL33_IMAGE_ID: >>> CID 378360: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "&bl_mem_params->ep_info" when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] 411 memcpy(&params->bl33_ep_info, &bl_mem_params->ep_info, 412 sizeof(entry_point_info_t)); 413 break; 414 default: 415 break; 416 } /plat/renesas/rcar/bl2_plat_setup.c: 446 in bl2_plat_handle_post_image_load() 440 bl_mem_params->image_info.image_base = dest; 441 break; 442 case BL32_IMAGE_ID: 443 ret = rcar_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 444 &dest); 445 if (!ret) >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "bl_mem_params", which is known to be "NULL". 446 bl_mem_params->image_info.image_base = dest; 447 448 memcpy(&params->bl32_ep_info, &bl_mem_params->ep_info, 449 sizeof(entry_point_info_t)); 450 break; 451 case BL33_IMAGE_ID: /plat/st/stm32mp1/bl2_plat_setup.c: 466 in bl2_plat_handle_post_image_load() 460 switch (image_ids[i]) { 461 case BL32_IMAGE_ID: 462 bl_mem_params->ep_info.pc = config_info->config_addr; 463 464 /* In case of OPTEE, initialize address space with tos_fw addr */ 465 pager_mem_params = get_bl_mem_params_node(BL32_EXTRA1_IMAGE_ID); >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "pager_mem_params", which is known to be "NULL". 466 pager_mem_params->image_info.image_base = config_info->config_addr; 467 pager_mem_params->image_info.image_max_size = 468 config_info->config_max_size; 469 470 /* Init base and size for pager if exist */ 471 paged_mem_params = get_bl_mem_params_node(BL32_EXTRA2_IMAGE_ID); /plat/renesas/rcar/bl2_plat_setup.c: 465 in bl2_plat_handle_post_image_load() 459 } else { 460 /* plain image, copy it in place */ 461 memcpy((void *)BL33_BASE, (void *)BL33_COMP_BASE, 462 bl_mem_params->image_info.image_size); 463 } 464 #endif >>> CID 378360: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "&bl_mem_params->ep_info" when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] 465 memcpy(&params->bl33_ep_info, &bl_mem_params->ep_info, 466 sizeof(entry_point_info_t)); 467 break; 468 } 469 470 return 0; /plat/renesas/rzg/bl2_plat_setup.c: 407 in bl2_plat_handle_post_image_load() 401 ret = rzg_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 402 &dest); 403 if (ret == 0U) { 404 bl_mem_params->image_info.image_base = dest; 405 } 406 >>> CID 378360: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "&bl_mem_params->ep_info" when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] 407 memcpy(&params->bl32_ep_info, &bl_mem_params->ep_info, 408 sizeof(entry_point_info_t)); 409 break; 410 case BL33_IMAGE_ID: 411 memcpy(&params->bl33_ep_info, &bl_mem_params->ep_info, 412 sizeof(entry_point_info_t)); /plat/st/stm32mp1/bl2_plat_setup.c: 472 in bl2_plat_handle_post_image_load() 466 pager_mem_params->image_info.image_base = config_info->config_addr; 467 pager_mem_params->image_info.image_max_size = 468 config_info->config_max_size; 469 470 /* Init base and size for pager if exist */ 471 paged_mem_params = get_bl_mem_params_node(BL32_EXTRA2_IMAGE_ID); >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "paged_mem_params", which is known to be "NULL". 472 paged_mem_params->image_info.image_base = STM32MP_DDR_BASE + 473 (dt_get_ddr_size() - STM32MP_DDR_S_SIZE - 474 STM32MP_DDR_SHMEM_SIZE); 475 paged_mem_params->image_info.image_max_size = STM32MP_DDR_S_SIZE; 476 break; 477 /plat/renesas/rcar/bl2_plat_setup.c: 448 in bl2_plat_handle_post_image_load() 442 case BL32_IMAGE_ID: 443 ret = rcar_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 444 &dest); 445 if (!ret) 446 bl_mem_params->image_info.image_base = dest; 447 >>> CID 378360: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "&bl_mem_params->ep_info" when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] 448 memcpy(&params->bl32_ep_info, &bl_mem_params->ep_info, 449 sizeof(entry_point_info_t)); 450 break; 451 case BL33_IMAGE_ID: 452 #if RCAR_GEN3_BL33_GZIP == 1 453 if ((mmio_read_32(BL33_COMP_BASE) & 0xffff) == 0x8b1f) { /plat/renesas/rcar/bl2_plat_setup.c: 440 in bl2_plat_handle_post_image_load() 434 435 switch (image_id) { 436 case BL31_IMAGE_ID: 437 ret = rcar_get_dest_addr_from_cert(SOC_FW_CONTENT_CERT_ID, 438 &dest); 439 if (!ret) >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "bl_mem_params", which is known to be "NULL". 440 bl_mem_params->image_info.image_base = dest; 441 break; 442 case BL32_IMAGE_ID: 443 ret = rcar_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 444 &dest); 445 if (!ret) /plat/renesas/rzg/bl2_plat_setup.c: 397 in bl2_plat_handle_post_image_load() 391 392 switch (image_id) { 393 case BL31_IMAGE_ID: 394 ret = rzg_get_dest_addr_from_cert(SOC_FW_CONTENT_CERT_ID, 395 &dest); 396 if (ret == 0U) { >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "bl_mem_params", which is known to be "NULL". 397 bl_mem_params->image_info.image_base = dest; 398 } 399 break; 400 case BL32_IMAGE_ID: 401 ret = rzg_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 402 &dest); /plat/renesas/rzg/bl2_plat_setup.c: 404 in bl2_plat_handle_post_image_load() 398 } 399 break; 400 case BL32_IMAGE_ID: 401 ret = rzg_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 402 &dest); 403 if (ret == 0U) { >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "bl_mem_params", which is known to be "NULL". 404 bl_mem_params->image_info.image_base = dest; 405 } 406 407 memcpy(&params->bl32_ep_info, &bl_mem_params->ep_info, 408 sizeof(entry_point_info_t)); 409 break; /plat/st/stm32mp1/bl2_plat_setup.c: 529 in bl2_plat_handle_post_image_load() 523 bl_mem_params->ep_info.args.arg1 = 0; /* Unused */ 524 bl_mem_params->ep_info.args.arg2 = 0; /* No DT supported */ 525 } else { 526 #if !STM32MP_USE_STM32IMAGE 527 bl_mem_params->ep_info.pc = bl_mem_params->image_info.image_base; 528 tos_fw_mem_params = get_bl_mem_params_node(TOS_FW_CONFIG_ID); >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "tos_fw_mem_params", which is known to be "NULL". 529 bl_mem_params->image_info.image_max_size += 530 tos_fw_mem_params->image_info.image_max_size; 531 #endif /* !STM32MP_USE_STM32IMAGE */ 532 bl_mem_params->ep_info.args.arg0 = 0; 533 } 534 break; ** CID 378359: Null pointer dereferences (NULL_RETURNS) /plat/st/common/bl2_io_storage.c: 413 in bl2_plat_handle_pre_image_load() ________________________________________________________________________________________________________ *** CID 378359: Null pointer dereferences (NULL_RETURNS) /plat/st/common/bl2_io_storage.c: 413 in bl2_plat_handle_pre_image_load() 407 image_block_spec.length = entry->length; 408 #endif 409 gpt_init_done = true; 410 } else { 411 bl_mem_params_node_t *bl_mem_params = get_bl_mem_params_node(image_id); 412 >>> CID 378359: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "bl_mem_params", which is known to be "NULL". 413 mmc_block_dev_spec.buffer.offset = bl_mem_params->image_info.image_base; 414 mmc_block_dev_spec.buffer.length = bl_mem_params->image_info.image_max_size; 415 } 416 417 break; 418 #endif ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 10 months

1
0
0 0

Trusted Firmware-A v2.7 release activities in May 2022

by Joanna Farley

TF-A Community, This is to notify that we are planning to target the Trusted Firmware-A 2.7 release during the fourth week of May 2021 as part of the regular 6 month cadence. This is a little later than originally targeted due to the number of patches still under review from contributors. The aim is to consolidate all TF-A work since the 2.6 release. As part of this, a release candidate tag will be created and release activities will commence some time during the week ending 20th May 2022 across all TF-A repositories. Any major enhancement patches still open after that date will not be merged until after the release. This release will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Jobs. We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start. Thanks Joanna

3 years, 10 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 378231: Control flow issues (UNREACHABLE) /plat/intel/soc/common/socfpga_sip_svc.c: 312 in is_out_of_sec_range() ________________________________________________________________________________________________________ *** CID 378231: Control flow issues (UNREACHABLE) /plat/intel/soc/common/socfpga_sip_svc.c: 312 in is_out_of_sec_range() 306 static int is_out_of_sec_range(uint64_t reg_addr) 307 { 308 #if DEBUG 309 return 0; 310 #endif 311 >>> CID 378231: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "switch (reg_addr) { case ...". 312 switch (reg_addr) { 313 case(0xF8011100): /* ECCCTRL1 */ 314 case(0xF8011104): /* ECCCTRL2 */ 315 case(0xF8011110): /* ERRINTEN */ 316 case(0xF8011114): /* ERRINTENS */ 317 case(0xF8011118): /* ERRINTENR */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 10 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Apr 21, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Topic: Feature Detection MechanismPresented by : Jayanth ChidanandAgenda:Feature detection mechanism is a diagnostic tool to quickly check and get assured of whether the architectural features enabled by software match with the given hardware implementation at an early stage of booting. It aims at mitigating the runtime-exceptions.I will be covering the implementation work completed so far and the impact ofReferences:TF-A Mailing List PostPatchesDocumentation=================================================We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   (changed) When: Thu Apr 21, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organizer's request) Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 10 months

1
0
0 0

TF-A Tech-Forum Agenda for Thursday 21-Apr-22 at 4pm BST

by Joanna Farley

Topic: Feature Detection Mechanism Presented by : Jayanth Chidanand Agenda: Feature detection mechanism is a diagnostic tool to quickly check and get assured of whether the architectural features enabled by software match with the given hardware implementation at an early stage of booting. It aims at mitigating the runtime-exceptions. I will be covering the implementation work completed so far and the impact of References: TF-A Mailing List Post<https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…> Patches<https://review.trustedfirmware.org/q/topic:%22jc%252Fdetect_feat%22+(status…> Documentation<https://trustedfirmware-a.readthedocs.io/en/latest/search.html?q=FEATURE_DE…> ================================================= We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https://www.trustedfirmware.org/meetings/tf-a-…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https://zoom.us/j/9159704974&sa=D&source=calen…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https://zoom.us/u/ad27hc6t7h&sa=D&source=calen…>

3 years, 10 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Apr 21, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Topic: Feature Detection MechanismPresented by : Jayanth ChidanandAgenda:Feature detection mechanism is a diagnostic tool to quickly check and get assured of whether the architectural features enabled by software match with the given hardware implementation at an early stage of booting. It aims at mitigating the runtime-exceptions.I will be covering the implementation work completed so far and the impact ofReferences:TF-A Mailing List PostPatchesDocumentation=================================================We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   (changed) When: Thu Apr 21, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 10 months

1
0
0 0

Status of MTE for bl31

by Okash Khawaja

Hi, I wanted to check the status of MTE support for bl31 itself. It seems like the support was added [1] for clang and armclang but I couldn't find the memory attribute to map pages as tag checked [2]. Is there something I missed? Thanks, Okash [1] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/… [2] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/…

3 years, 10 months

3
7
0 0

MTE support at S-EL1

by Jens Wiklander

Hi, I've started to experiment with MTE in OP-TEE at S-EL1. I've compiled TF-A with CTX_INCLUDE_MTE_REGS and I'm testing this on QEMU. Before trying to use MTE in OP-TEE I check id_aa64pfr1_el1 and skip MTE initializations if unavailable. This works as long as TF-A always is compiled with CTX_INCLUDE_MTE_REGS if MTE is available. If TF-A is compiled without CTX_INCLUDE_MTE_REGS OP-TEE will be trapped into EL3 when trying to access one of the MTE registers. I suppose this is because SCR_EL3.ATA is 0. Is there a way for OP-TEE to tell if the MTE registers are safe to access? Thanks, Jens

3 years, 10 months

2
2
0 0

TF-a would not handle PSCI_CPU_ON_AARCH64 if forwarded by a hypervisor

by Mushahid Hussain

Hi, I'm working on a hobby project: AARCH64 Hypervisor on Raspberry Pi 4b. I have a problem with trapping a psci smc. I'll explain everything and what steps I have followed. Right now, I'm implementing SMC trapping. I can successfully forward almost all SMCs except for PSCI_CPU_ON_AARCH64. Linux makes these SMCs to bring up secondary CPUs during booting. Here's what I'm trying to do: - trap the PSCI_CPU_ON_AARCH64 SMC, - preserve the entry_point address in global variable - replace the entrypoint with my entrypoint and make the smc to tf-a(or simply forward it.) - when secondary cpus come online at the given address, where I set their stack point and then eret the original address. Secondary cpus won't come online at the given address. Even if I don't change any arguments of CPU_ON smc and forward it as it is, the secondary cpus still won't come online. However, without trapping enabled(HCR_EL2.TSC=0), everything works fine. I tried to debug inside Trusted Firmware. I know that overall path for secondary CPU hotplug in is: CPU released from reset -> (ROM and possibly some other bootloader) -> bl31/aarch64/bl31_entrypoint.S:bl31_warm_entrypoint() -> lib/psci/psci_common.c:psci_warmboot_entrypoint() -> lib/psci/psci_on.c:psci_cpu_on_finish() -> rpi3_pwr_domain_on_finish() I printed at all these points in Trusted Firmware with and without trapping enabled. Here's what I found: Nothing gets printed anywhere in that path if trapping is enabled. However, without trapping enabled, I can print anywhere even in bl31_entrypoint.S:bl31_warm_entrypoint(). What could be the problem? Here's my code: https://github.com/SikkiLadho/Leo/blob/4f272eff39934058a7f989c91aad82eab810… -- Mushahid Hussain

3 years, 10 months

1
0
0 0

Cortex-X1 support

by Okash Khawaja

Hello, Are there any immediate plans to add support for Cortex-X1 in TF-A? If not then I'll be happy to submit CL for it. For start, it will cover a subset of errata workarounds. Then people can add more as needed. Let me know what you think. Thanks, Okash

3 years, 11 months

2
2
0 0

TF-A Tech Forum Agenda this week

by Joanna Farley

Session this week will be: * CCA Attestation and Measured boot * Presented by Tamas Ban * As a follow up to TF-A mailing list posting https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https://zoom.us/j/9159704974&sa=D&source=calen…> Meeting ID: 915 970 4974

3 years, 11 months

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Apr 7, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

3 years, 11 months

1
0
0 0

[Feedback required] Feature detection mechanism

by Manish Pandey2

Hello All, We are sending this note, to notify you of all the implementation details related to the Architectural Features Detection Mechanism. Summary: This is a diagnostic tool, which is targeted to mitigate the runtime exceptions due to incorrect feature enablement. This is currently marked as experimental and disabled by default, but our target is to make it mandatory over the time. All the platform owners are expected to read the details(and review the patch) and give it a try by enabling this mechanism and share your thoughts/feedback or any questions to @Jayanth Dodderi Chidanand<mailto:JAYANTHDODDERI.CHIDANAND@arm.com> or me. Patches under Review: https://review.trustedfirmware.org/q/topic:jc/detect_feat Details: 1. What is Feature Detection Mechanism? * Feature Detection is a procedure/mechanism aimed at identifying the features which are enabled ( by software) and not detected/supported in the hardware. * It could be considered as a diagnostic tool to quickly check and get assured which features are not supported by the hardware at an early stage of booting. 2. Why do we need it? Currently, most of the feature-specific register's context management, save and restore routines are conditionally controlled with the ARM_ARCH_AT_LEAST macro, which is primarily causing exceptions under various scenarios like: * For a given version of the architecture, the optional and mandatory features control the access to various registers. If the given version of implementation does not support both, unconditional access to such registers leads to undefined behaviour. * Accessing registers without verifying their actual presence for the given implementation. In general, the problem is broader than just this specific case. We should not rely on ARM_ARCH_AT_LEAST macro to associate with an architecture extension but rather supply the individual ENABLE_FEAT_xxx option for each feature. Again, having individual build flags, won't resolve this completely. There is still room for error as users may unknowingly enable the flags. So, the build flags still need to be validated before performing any action guarded by them. This mechanism helps in resolving this issue completely. It assists in detecting the features which are not present in the platform but are enabled by software unknowingly. It prevents the runtime exception, due to the consequences already mentioned. 3. How have we designed and implemented it? We are introducing a tri-state approach for each feature build flag. From now on, the build flags take three values/states ( 0,1 or 2), and they imply as follows: The 3 states are: * ENABLE_FEAT_xxx = 0: The feature is disabled statically at compile time. * ENABLE_FEAT_xxx = 1: The feature is enabled and must be present in hardware. There will be hard panic if the feature is not present at cold boot. * ENABLE_FEAT_xxx = 2: The feature is enabled and detected at runtime Based on the value defined for each feature flag, they get detected either at boot-time or at runtime, respectively. For simplicity, let's take FEAT_HCX which is available in arch version 8.7. We provide a build option for enabling this feature, say "ENABLE_FEAT_HCX". * ENABLE_FEAT_HCX=0; The feature is disabled statically at compile time. * ENABLE_FEAT_HCX=1; The feature is enabled and must be present in hardware. There will be hard panic if the feature is not present at cold boot. i.e., we detect, whether the HCX feature is present in the PE, by reading its ID register and if not, panic will be called. Thereby at an early boot phase, we stop and report that FEAT_HCX is not supported by PE. * ENABLE_FEAT_HCX=2; The feature is enabled but dynamically enabled at runtime depending on hardware capability. Here, a feature detection check will happen during runtime. 4. What is the status of this implementation? Is it completely implemented and tested? We have divided the entire implementation into two phases. In phase-1 FEAT_STATES { 0, 1} are handled and FEAT_STATE{2} will be handled ahead. Currently, we are in phase-1 delivery, wherein we are introducing a procedure, which will read through all the enabled feature build flags, and if they are defined to state1, ENABLE_FEAT_XXX=1 the respective feature will be detected. 5. Which all features are considered here? TF-A supports most arm architectural features from v8.0 and upwards. Some are mandatory and some are optional features as per the Arm ARM docs. So, both ( Mandatory and optional features from v8.0) are detected under this mechanism. 6. Does this mechanism modify or impact any existing implementation related to any of the architectural features supported in TF-A? * Yes. * Ideally, TF-A enables the architectural features which are mandatory by default from a particular arch version and upwards ( as per Arm-ARM docs ) and disables the optional features by default and allows the platforms to make the decision on enabling the optional feature based on their requirements. * This pattern is followed for most of the features. However, there are some cases wherein optional features are enabled by default within TF-A ( Eg; FEAT_SPE, FEAT_SVE ), which shouldn't have been handled this way. * With the feature detection mechanism in place, as stated earlier the procedure runs through all the enabled features(optional and mandatory) and identifies them. * Now, FEAT_SPE and FEAT_SVE are optional features, which are enabled by default and when detected will not be identified by the PE, if it doesn't support it and panics during booting. * So, since we have enabled these optional features within the TF-A build system, it would panic and stop booting. * If we upstream this mechanism, all the partner's platforms will be impacted involuntarily. This problem will not be seen in other cases like: * Mandatory Feature: Let's say FEAT_FGT which is mandatory from the 8.6 version. So, if a platform is based on v8.6 it will implement this, and this feature will be detected. So no issue here. If the platform is based on v8.5, this FEAT_FGT is not enabled by the TF-A. It gets enabled from 8.6. So here, in this case, the feature is disabled so nothing to worry about. * Optional Feature: Let's say FEAT_NV2 which is an optional feature from arch version 8.4. is supported by TF-A. Since it is an optional one as per Arm ARM, TF-A implements and disables it by default and allows the platforms to decide and enable them as per their requirements. So here, if the platform enables it, it implies they are sure this feature is implemented. If not, this mechanism will help them by detecting it, so that they disable it in future. In general, this would not break the boot flow in all scenarios. But if the optional feature is enabled by TF-A itself, will stop the boot flow in most of scenarios. So, to avoid breaking change, we have decided to overlook such optional features for now and update our partners and get their feedback. Based on that, in future, we will disable these optional features which were enabled by default and will send another email to enable it explicitly according to their requirements. 7. What should the platforms be aware of, with the upstreaming of this mechanism? * Currently, we are introducing this entire implementation as an experimental mechanism, wherein we provide an explicit build flag (FEATURE_DETECTION) to enable the feature detection mechanism itself. We urge the platforms to enable this mechanism, test it and get used to its behaviour before it gets mandated. * So, for now, it wouldn't cause any issue. But our plan is to make sure this mechanism runs by default, as we want to mitigate the runtime Exceptions. As part of the 2.7 release, we are targeting to upstream this implementation and later, have some time window, wherein our partners get used to it and provide feedback as well. 8. Will there be any breakdown during runtime, with respect to any of the platforms? Yes. It's explained in detail above. 9. What is the long-term plan with this mechanism? When will this be completely implemented and tested end to end? We target it to be implemented full-fledged by EoY 2022, but it depends on the feedback received from our partners and get this done. Thanks

3 years, 11 months

1
0
0 0

ENABLE_PIE with clang

by Okash Khawaja

Hi, It seems like setting ENABLE_PIE=1 and compiling with clang/LLVM results in linker errors. E.g. compiling ti/k3 which has ENABLE_PIE=1, with clang and lld version 14.0.1 results in linker errors like "ld.lld: error: can't create dynamic relocation R_AARCH64_ABS64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output". Is this expected? If not, are there any plans to fix this? Thanks, Okash

3 years, 11 months

2
2
0 0

CCA Attestation and Measured boot

by Tamas Ban

Hi, In Arm CCA the Security Model strongly recommends implementing the CCA HES functionality to ensure the system security properties. A way to achieve this is to add a trusted subsystem to the system, which behaves like a secure enclave. In ARM reference design this trusted subsystem is called to Runtime Security Subsystem (RSS). RSS can execute a firmware component that implements the functional requirements of the HES. But its firmware is not restricted to be only the HES, other tenants are also allowed. The goal of the CCA HES is to provide fundamental services to the AP to ensure its security properties. These fundamental services include secure boot, measured boot and attestation, etc. You can find more information about the role of CCA HES and about its functional requirements in the Arm CCA Security Model [1]. In ARM reference design the CCA HES is going to be executed by RSS. CCA HES is based on TF-M. In this patch series [2] the AP side support of the CCA HES functionalities is going to be introduced: - Communication over an MHU channel between the AP and RSS. - Communication abstracted by the PSA API. So, AP can leverage standard PSA calls to invoke these services on the RSS. - CCA HES provides a measured boot backend. Measurements are taken during AP boot can be stored by RSS and retrieved as part of the CCA Platform Attestation token. - CCA Platform Attestation token can be requested from RSS. Currently, there is no publicly available FVP platform to test these patches, but it will be available later this year. Some limited testing is available on the AEM FVP. Here the RSS based measured boot backend is enabled and mocked version of the measured boot and attestation APIs are available. Due to the lack of RSS in the FVP, the APIs do not communicate to RSS, instead just print the measurements to the console and return to a hard-coded attestation token. [1] https://developer.arm.com/documentation/DEN0096/latest [2] https://review.trustedfirmware.org/q/topic:%2522rss/mboot-attest%2522 Best regards, Tamas Ban

3 years, 11 months

1
0
0 0

Mbed TLS GitHub migration

by dave.rodgman＠arm.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

3 years, 11 months

1
0
1 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 376885: Integer handling issues (NEGATIVE_RETURNS) ________________________________________________________________________________________________________ *** CID 376885: Integer handling issues (NEGATIVE_RETURNS) /drivers/st/clk/clk-stm32-core.c: 343 in _clk_stm32_set_parent() 337 if (parents->id_parents[sel] == (uint16_t)clkp) { 338 bool clk_was_enabled = _clk_stm32_is_enabled(priv, clk); 339 int err = 0; 340 341 /* Enable the parents (for glitch free mux) */ 342 _clk_stm32_enable(priv, clkp); >>> CID 376885: Integer handling issues (NEGATIVE_RETURNS) >>> "old_parent" is passed to a parameter that cannot be negative. 343 _clk_stm32_enable(priv, old_parent); 344 345 err = clk_mux_set_parent(priv, pid, sel); 346 347 _clk_stm32_disable(priv, old_parent); 348 ** CID 376884: Error handling issues (CHECKED_RETURN) /drivers/nxp/ddr/phy-gen2/phy.c: 2219 in load_fw() ________________________________________________________________________________________________________ *** CID 376884: Error handling issues (CHECKED_RETURN) /drivers/nxp/ddr/phy-gen2/phy.c: 2219 in load_fw() 2213 ERROR("Unsupported DIMM type\n"); 2214 return -EINVAL; 2215 } 2216 2217 size = PHY_GEN2_MAX_IMAGE_SIZE; 2218 image_buf = (uintptr_t)phy_gen2_fw_img_buf; >>> CID 376884: Error handling issues (CHECKED_RETURN) >>> Calling "mmap_add_dynamic_region" without checking return value (as is done elsewhere 14 out of 16 times). 2219 mmap_add_dynamic_region(phy_gen2_fw_img_buf, 2220 phy_gen2_fw_img_buf, 2221 PHY_GEN2_MAX_IMAGE_SIZE, 2222 MT_MEMORY | MT_RW | MT_SECURE); 2223 ret = img_loadr(imem_id, &image_buf, &size); 2224 if (ret != 0) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 11 months

1
0
1 0

Canceled event: TF-A Tech Forum @ Thu Mar 24, 2022 9am - 10am (MST) (tf-a@lists.trustedfirmware.org)

by don.harbin＠linaro.org

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

3 years, 11 months

1
0
0 0

TF-A Tech Forum

by Joanna Farley

Not sure if the cancellation has gone out but just confirming this Tech Forum is cancelled. Thanks Joanna From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 24 March 2022 Subject: TF-A Tech Forum You have been invited to the following event. TF-A Tech Forum When Thu Mar 24, 2022 4pm – 5pm United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher - creator • marek.bykowski(a)gmail.com • okash.khawaja(a)gmail.com • tf-a(a)lists.trustedfirmware.org more details »<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? Yes<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> - Maybe<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> - No<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> more options »<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> Invitation from Google Calendar<https://calendar.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.

3 years, 11 months

1
0
0 0

TF-A Tech Forum @ Thu Mar 24, 2022 4pm - 5pm (GMT) CANCELLED

by Joanna Farley

Just confirming that the TF-A Tech forum this week is cancelled due to no subject/topic. Thanks Joanna

3 years, 11 months

1
0
0 0

Invitation: TF-A Tech Forum @ Thu Mar 24, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

3 years, 11 months

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Mar 24, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

3 years, 11 months

1
0
0 0

TrustedFirmware Code of Conduct

by Don Harbin

Hi All, Please find the link to the TrustedFirmware Community Code of Conduct here: https://developer.trustedfirmware.org/w/collaboration/community_guidelines/… Trusted Firmware has a very diverse and global developer community. It is important that we adhere to the code of conduct in all our interactions. For some of you all this may be new and for others just a gentle reminder. In either case, if you have any questions, please feel free to reach out to me directly. And thanks to you all for your contributions to the TrustedFirmware community! Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

3 years, 11 months

1
0
0 0

TF-A Technical Forum Session Agenda for Today

by Joanna Farley

I understand some people may not have seen the calendar invite for today’s Tech Forum session. It is in the archives but formatting has been lost so just confirming the agenda in plain email to the list. Joanna Agenda for Session on 10th March 2022 * Introduction to Arm DRTM specification and its support in TF-A * Stuart Yoder/Lucian Pau-Trifu will go through basic of Arm's DRTM specification, beta specification publicly released https://developer.arm.com/documentation/den0113/latest%C2%A0Manish * Pandey/Manish Badarkhe will go through implementation details and planned delivery in TF-A codebase. Details: * Dynamic Root of Trust for Measurement (DRTM) for Armv8-A is based on concepts from the TCG D-RTM Architecture. DRTM begins a new chain of trust by measuring and executing a protected payload which is in contrast to Static RTM(measured boot) where measurements are done at boot time. * Implementation of DRTM services in BL31 and various platform hooks required. Also, talk about initial support on FVP platform and limitations. We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https://www.trustedfirmware.org/meetings/tf-a-…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https://zoom.us/j/9159704974&sa=D&source=calen…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https://zoom.us/u/ad27hc6t7h&sa=D&source=calen…>

3 years, 12 months

1
1
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 376627: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 276 in pm_smc_handler() /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 553 in pm_smc_handler() ________________________________________________________________________________________________________ *** CID 376627: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 276 in pm_smc_handler() 270 SMC_RET1(handle, SMC_UNK); 271 272 pm_arg[0] = (uint32_t)x1; 273 pm_arg[1] = (uint32_t)(x1 >> 32); 274 pm_arg[2] = (uint32_t)x2; 275 pm_arg[3] = (uint32_t)(x2 >> 32); >>> CID 376627: (OVERRUN) >>> Overrunning array "pm_arg" of 4 4-byte elements at element index 4 (byte offset 19) using index "4". 276 pm_arg[4] = (uint32_t)x3; 277 278 api_id = smc_fid & FUNCID_NUM_MASK; 279 280 switch (api_id) { 281 /* PM API Functions */ /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 553 in pm_smc_handler() 547 SMC_RET2(handle, (uint64_t)ret | ((uint64_t)version << 32), 548 (uint64_t)bit_mask[0] | ((uint64_t)bit_mask[1] << 32)); 549 } 550 551 default: 552 /* Send request to the PMU */ >>> CID 376627: (OVERRUN) >>> Overrunning array "pm_arg" of 4 4-byte elements at element index 4 (byte offset 19) using index "4". 553 PM_PACK_PAYLOAD6(payload, api_id, pm_arg[0], pm_arg[1], 554 pm_arg[2], pm_arg[3], pm_arg[4]); 555 ret = pm_ipi_send_sync(primary_proc, payload, result, 556 PAYLOAD_ARG_CNT); 557 SMC_RET2(handle, (uint64_t)ret | ((uint64_t)result[0] << 32), 558 (uint64_t)result[1] | ((uint64_t)result[2] << 32)); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Mar 10, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Agenda for TF-A Tech Forum on 10th March 2022Introduction to Arm DRTM specification and its support in TF-AStuart Yoder/Lucian Pau-Trifu will go through basic of Arm's DRTM specification, beta specification publicly released https://developer.arm.com/documentation/den0113/latest M… Pandey/Manish Badarkhe will go through implementation details and planned delivery in TF-A codebase. Details:Dynamic Root of Trust for Measurement (DRTM) for Armv8-A is based on concepts from the TCG D-RTM Architecture. DRTM begins a new chain of trust by measuring and executing a protected payload which is in contrast to Static RTM(measured boot) where measurements are done at boot time.Implementation of DRTM services in BL31 and various platform hooks required. Also, talk about initial support on FVP platform and limitations.=========================We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   (changed) When: Thu Mar 10, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years

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. 12 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 4 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 12 of 12 defect(s) ** CID 376586: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 207 in psci_get_stat() ________________________________________________________________________________________________________ *** CID 376586: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 207 in psci_get_stat() 201 if (pwrlvl == PSCI_INVALID_PWR_LVL) { 202 ERROR("Invalid target power level for PSCI statistics operation\n"); 203 panic(); 204 } 205 206 /* Get the index into the stats array */ >>> CID 376586: Memory - illegal accesses (OVERRUN) >>> Overrunning array "state_info.pwr_domain_state" of 2 bytes at byte offset 3 using index "pwrlvl" (which evaluates to 3). 207 local_state = state_info.pwr_domain_state[pwrlvl]; 208 stat_idx = get_stat_idx(local_state, pwrlvl); 209 210 if (pwrlvl > PSCI_CPU_PWR_LVL) { 211 /* Get the power domain index */ 212 parent_idx = SPECULATION_SAFE_VALUE(psci_cpu_pd_nodes[target_idx].parent_node); ** CID 376585: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 495 in amu_context_save() /lib/extensions/amu/aarch32/amu.c: 337 in amu_context_save() ________________________________________________________________________________________________________ *** CID 376585: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 495 in amu_context_save() 489 * Save the counters to the local context. 490 */ 491 492 isb(); /* Ensure counters have been stopped */ 493 494 for (i = 0U; i < amcgcr_el0_cg0nc; i++) { >>> CID 376585: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 495 ctx->group0_cnts[i] = amu_group0_cnt_read(i); 496 } 497 498 #if ENABLE_AMU_AUXILIARY_COUNTERS 499 for (i = 0U; i < amcgcr_el0_cg1nc; i++) { 500 ctx->group1_cnts[i] = amu_group1_cnt_read(i); /lib/extensions/amu/aarch32/amu.c: 337 in amu_context_save() 331 * Save the counters to the local context. 332 */ 333 334 isb(); /* Ensure counters have been stopped */ 335 336 for (i = 0U; i < amcgcr_cg0nc; i++) { >>> CID 376585: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 337 ctx->group0_cnts[i] = amu_group0_cnt_read(i); 338 } 339 340 #if ENABLE_AMU_AUXILIARY_COUNTERS 341 for (i = 0U; i < amcgcr_cg1nc; i++) { 342 ctx->group1_cnts[i] = amu_group1_cnt_read(i); ** CID 376584: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 585 in amu_context_restore() /lib/extensions/amu/aarch32/amu.c: 396 in amu_context_restore() ________________________________________________________________________________________________________ *** CID 376584: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 585 in amu_context_restore() 579 580 /* 581 * Restore the counter values from the local context. 582 */ 583 584 for (i = 0U; i < amcgcr_el0_cg0nc; i++) { >>> CID 376584: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 585 amu_group0_cnt_write(i, ctx->group0_cnts[i]); 586 } 587 588 #if ENABLE_AMU_AUXILIARY_COUNTERS 589 for (i = 0U; i < amcgcr_el0_cg1nc; i++) { 590 amu_group1_cnt_write(i, ctx->group1_cnts[i]); /lib/extensions/amu/aarch32/amu.c: 396 in amu_context_restore() 390 391 /* 392 * Restore the counter values from the local context. 393 */ 394 395 for (i = 0U; i < amcgcr_cg0nc; i++) { >>> CID 376584: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 396 amu_group0_cnt_write(i, ctx->group0_cnts[i]); 397 } 398 399 #if ENABLE_AMU_AUXILIARY_COUNTERS 400 for (i = 0U; i < amcgcr_cg1nc; i++) { 401 amu_group1_cnt_write(i, ctx->group1_cnts[i]); ** CID 376583: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 309 in ddr3_get_parameter() /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 298 in ddr3_get_parameter() ________________________________________________________________________________________________________ *** CID 376583: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 309 in ddr3_get_parameter() 303 tmp = ((DDR3_TWTR * nmhz + (nmhz >> 1) + 999) / 1000); 304 pdram_timing->twtr = max(4, tmp); 305 pdram_timing->trtw = DDR3_TRTW; 306 pdram_timing->tras_max = 9 * pdram_timing->trefi; 307 pdram_timing->tras_min = ((DDR3_TRAS * nmhz + (nmhz >> 1) + 999) 308 / 1000); >>> CID 376583: (OVERRUN) >>> Overrunning array "ddr3_trc_tfaw" of 22 2-byte elements at element index 31 (byte offset 63) using index "ddr_speed_bin" (which evaluates to 31). 309 pdram_timing->tfaw = 310 (((ddr3_trc_tfaw[ddr_speed_bin] & 0x0ff) * nmhz + 999) 311 / 1000); 312 /* tRFC, 90ns(512Mb),110ns(1Gb),160ns(2Gb),300ns(4Gb),350ns(8Gb) */ 313 if (ddr_capability_per_die <= 0x4000000) 314 tmp = DDR3_TRFC_512MBIT; /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 298 in ddr3_get_parameter() 292 else 293 pdram_timing->mr[0] = DDR3_BL8 294 | DDR3_CL(pdram_timing->cl) 295 | DDR3_WR(tmp); 296 tmp = ((DDR3_TRTP * nmhz + (nmhz >> 1) + 999) / 1000); 297 pdram_timing->trtp = max(4, tmp); >>> CID 376583: (OVERRUN) >>> Overrunning array "ddr3_trc_tfaw" of 22 2-byte elements at element index 31 (byte offset 63) using index "ddr_speed_bin" (which evaluates to 31). 298 pdram_timing->trc = 299 (((ddr3_trc_tfaw[ddr_speed_bin] >> 8) * nmhz + 999) / 1000); 300 tmp = ((DDR3_TRRD * nmhz + 999) / 1000); 301 pdram_timing->trrd = max(4, tmp); 302 pdram_timing->tccd = DDR3_TCCD; 303 tmp = ((DDR3_TWTR * nmhz + (nmhz >> 1) + 999) / 1000); ** CID 376582: (UNINIT) ________________________________________________________________________________________________________ *** CID 376582: (UNINIT) /drivers/st/clk/stm32mp1_clk.c: 1928 in stm32mp1_clk_init() 1922 if ((mmio_read_32(rcc_base + RCC_MP_RSTSCLRR) & 1923 RCC_MP_RSTSCLRR_MPUP0RSTF) != 0) { 1924 pll3_preserve = stm32mp1_check_pll_conf(_PLL3, 1925 clksrc[CLKSRC_PLL3], 1926 pllcfg[_PLL3], 1927 plloff[_PLL3]); >>> CID 376582: (UNINIT) >>> Using uninitialized value "*pllcfg[_PLL4]" when calling "stm32mp1_check_pll_conf". 1928 pll4_preserve = stm32mp1_check_pll_conf(_PLL4, 1929 clksrc[CLKSRC_PLL4], 1930 pllcfg[_PLL4], 1931 plloff[_PLL4]); 1932 } 1933 /* Don't initialize PLL4, when used by BOOTROM */ /drivers/st/clk/stm32mp1_clk.c: 1924 in stm32mp1_clk_init() 1918 if (ret != 0) { 1919 return ret; 1920 } 1921 1922 if ((mmio_read_32(rcc_base + RCC_MP_RSTSCLRR) & 1923 RCC_MP_RSTSCLRR_MPUP0RSTF) != 0) { >>> CID 376582: (UNINIT) >>> Using uninitialized value "*pllcfg[_PLL3]" when calling "stm32mp1_check_pll_conf". 1924 pll3_preserve = stm32mp1_check_pll_conf(_PLL3, 1925 clksrc[CLKSRC_PLL3], 1926 pllcfg[_PLL3], 1927 plloff[_PLL3]); 1928 pll4_preserve = stm32mp1_check_pll_conf(_PLL4, 1929 clksrc[CLKSRC_PLL4], ** CID 376581: Memory - illegal accesses (OVERRUN) /plat/brcm/common/brcm_io_storage.c: 389 in plat_get_image_source() ________________________________________________________________________________________________________ *** CID 376581: Memory - illegal accesses (OVERRUN) /plat/brcm/common/brcm_io_storage.c: 389 in plat_get_image_source() 383 boot_source = boot_source_get(); 384 if (image_id == FIP_IMAGE_ID) 385 policy = &boot_source_policies[boot_source]; 386 else 387 policy = &policies[image_id]; 388 >>> CID 376581: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 48 bytes at byte offset 168 by dereferencing pointer "policy". 389 result = policy->check(policy->image_spec); 390 if (result == 0) { 391 *image_spec = policy->image_spec; 392 *dev_handle = *(policy->dev_handle); 393 394 if (image_id == TRUSTED_BOOT_FW_CERT_ID) { ** CID 376580: Memory - illegal accesses (OVERRUN) /drivers/nxp/crypto/caam/src/caam.c: 245 in run_descriptor_jr() ________________________________________________________________________________________________________ *** CID 376580: Memory - illegal accesses (OVERRUN) /drivers/nxp/crypto/caam/src/caam.c: 245 in run_descriptor_jr() 239 int i = 0, ret = 0; 240 uint32_t *desc_addr = jobdesc->desc; 241 uint32_t desc_len = desc_length(jobdesc->desc); 242 uint32_t desc_word; 243 244 for (i = 0; i < desc_len; i++) { >>> CID 376580: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 64 4-byte elements at element index 126 (byte offset 507) by dereferencing pointer "desc_addr + i". 245 desc_word = desc_addr[i]; 246 VERBOSE("%x\n", desc_word); 247 sec_out32((uint32_t *)&desc_addr[i], desc_word); 248 } 249 dsb(); 250 ** CID 376579: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_client.c: 220 in pm_client_set_wakeup_sources() /plat/xilinx/zynqmp/pm_service/pm_client.c: 217 in pm_client_set_wakeup_sources() /plat/xilinx/versal/pm_service/pm_client.c: 149 in pm_client_set_wakeup_sources() /plat/xilinx/versal/pm_service/pm_client.c: 156 in pm_client_set_wakeup_sources() ________________________________________________________________________________________________________ *** CID 376579: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_client.c: 220 in pm_client_set_wakeup_sources() 214 node = irq_to_pm_node(irq); 215 reg &= ~lowest_set; 216 217 if ((node != NODE_UNKNOWN) && 218 (!pm_wakeup_nodes_set[node])) { 219 ret = pm_set_wakeup_source(NODE_APU, node, 1); >>> CID 376579: (OVERRUN) >>> Overrunning array "pm_wakeup_nodes_set" of 78 bytes at byte offset 127 using index "node" (which evaluates to 127). 220 pm_wakeup_nodes_set[node] = !ret; 221 } 222 } 223 } 224 } 225 /plat/xilinx/zynqmp/pm_service/pm_client.c: 217 in pm_client_set_wakeup_sources() /plat/xilinx/versal/pm_service/pm_client.c: 149 in pm_client_set_wakeup_sources() 143 break; 144 } 145 146 node_idx = irq_to_pm_node_idx(irq); 147 reg &= ~lowest_set; 148 >>> CID 376579: (OVERRUN) >>> Overrunning array "pm_wakeup_nodes_set" of 84 bytes at byte offset 127 using index "node_idx" (which evaluates to 127). 149 if ((node_idx != XPM_NODEIDX_DEV_MIN) && 150 (pm_wakeup_nodes_set[node_idx] == 0U)) { 151 /* Get device ID from node index */ 152 device_id = PERIPH_DEVID(node_idx); 153 ret = pm_set_wakeup_source(node_id, 154 device_id, 1, /plat/xilinx/versal/pm_service/pm_client.c: 156 in pm_client_set_wakeup_sources() 150 (pm_wakeup_nodes_set[node_idx] == 0U)) { 151 /* Get device ID from node index */ 152 device_id = PERIPH_DEVID(node_idx); 153 ret = pm_set_wakeup_source(node_id, 154 device_id, 1, 155 SECURE_FLAG); >>> CID 376579: (OVERRUN) >>> Overrunning array "pm_wakeup_nodes_set" of 84 bytes at byte offset 127 using index "node_idx" (which evaluates to 127). 156 pm_wakeup_nodes_set[node_idx] = (uint8_t)(!ret); 157 } 158 } 159 } 160 } 161 ** CID 376578: Uninitialized variables (UNINIT) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 533 in pm_smc_handler() ________________________________________________________________________________________________________ *** CID 376578: Uninitialized variables (UNINIT) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 533 in pm_smc_handler() 527 528 case PM_CLOCK_GETRATE: 529 { 530 uint64_t value; 531 532 ret = pm_clock_getrate(pm_arg[0], &value); >>> CID 376578: Uninitialized variables (UNINIT) >>> Using uninitialized value "value". 533 SMC_RET2(handle, (uint64_t)ret | 534 (((uint64_t)value & 0xFFFFFFFFU) << 32U), 535 (value >> 32U) & 0xFFFFFFFFU); 536 537 } 538 ** CID 376577: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 236 in ddr3_get_parameter() /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 235 in ddr3_get_parameter() ________________________________________________________________________________________________________ *** CID 376577: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 236 in ddr3_get_parameter() 230 /* when dll bypss cl = cwl = 6 */ 231 if (nmhz < 300) { 232 pdram_timing->cl = 6; 233 pdram_timing->cwl = 6; 234 } else { 235 pdram_timing->cl = (ddr3_cl_cwl[ddr_speed_bin][tmp] >> 4) & 0xf; >>> CID 376577: (OVERRUN) >>> Overrunning array "ddr3_cl_cwl" of 22 7-byte elements at element index 31 (byte offset 223) using index "ddr_speed_bin" (which evaluates to 31). 236 pdram_timing->cwl = ddr3_cl_cwl[ddr_speed_bin][tmp] & 0xf; 237 } 238 239 switch (timing_config->dramds) { 240 case 40: 241 tmp = DDR3_DS_40; /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 235 in ddr3_get_parameter() 229 230 /* when dll bypss cl = cwl = 6 */ 231 if (nmhz < 300) { 232 pdram_timing->cl = 6; 233 pdram_timing->cwl = 6; 234 } else { >>> CID 376577: (OVERRUN) >>> Overrunning array "ddr3_cl_cwl" of 22 7-byte elements at element index 31 (byte offset 223) using index "ddr_speed_bin" (which evaluates to 31). 235 pdram_timing->cl = (ddr3_cl_cwl[ddr_speed_bin][tmp] >> 4) & 0xf; 236 pdram_timing->cwl = ddr3_cl_cwl[ddr_speed_bin][tmp] & 0xf; 237 } 238 239 switch (timing_config->dramds) { 240 case 40: ** CID 376576: Uninitialized variables (UNINIT) /plat/mediatek/mt8195/plat_sip_calls.c: 48 in mediatek_plat_sip_handler() ________________________________________________________________________________________________________ *** CID 376576: Uninitialized variables (UNINIT) /plat/mediatek/mt8195/plat_sip_calls.c: 48 in mediatek_plat_sip_handler() 42 ret = dfd_smc_dispatcher(x1, x2, x3, x4); 43 SMC_RET1(handle, ret); 44 break; 45 case MTK_SIP_APUSYS_CONTROL_AARCH32: 46 case MTK_SIP_APUSYS_CONTROL_AARCH64: 47 ret = apusys_kernel_ctrl(x1, x2, x3, x4, &ret_val); >>> CID 376576: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret_val". 48 SMC_RET2(handle, ret, ret_val); 49 break; 50 default: 51 ERROR("%s: unhandled SMC (0x%x)\n", __func__, smc_fid); 52 break; 53 } 54 55 SMC_RET1(handle, SMC_UNK); ** CID 375635: Integer handling issues (BAD_SHIFT) /lib/zlib/inflate.c: 263 in inflatePrime() ________________________________________________________________________________________________________ *** CID 375635: Integer handling issues (BAD_SHIFT) /lib/zlib/inflate.c: 263 in inflatePrime() 257 state->hold = 0; 258 state->bits = 0; 259 return Z_OK; 260 } 261 if (bits > 16 || state->bits + (uInt)bits > 32) return Z_STREAM_ERROR; 262 value &= (1L << bits) - 1; >>> CID 375635: Integer handling issues (BAD_SHIFT) >>> In expression "(unsigned int)value << state->bits", left shifting by more than 31 bits has undefined behavior. The shift amount, "state->bits", is as much as 32. 263 state->hold += (unsigned)value << state->bits; 264 state->bits += (uInt)bits; 265 return Z_OK; 266 } 267 268 /* ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years

1
0
0 0

[MPAM] Removing initialization of MPAM EL2 registers when EL2 is used

by Zelalem Aweke

Hi all, The small patch below [1] removes initialization of MPAM EL2 registers when EL2 is used, with the assumption that if an EL2 software exists it should perform the necessary initializations. Please take a look at the patch and let me know if this change affects any downstream projects. Thanks! Zelalem [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/13805/7

4 years

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 376573: Control flow issues (NO_EFFECT) /plat/intel/soc/common/socfpga_sip_svc.c: 142 in intel_fpga_config_completed_write() ________________________________________________________________________________________________________ *** CID 376573: Control flow issues (NO_EFFECT) /plat/intel/soc/common/socfpga_sip_svc.c: 142 in intel_fpga_config_completed_write() 136 137 while (*count < 3) { 138 139 status = mailbox_read_response(job_id, 140 resp, &resp_len); 141 >>> CID 376573: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "resp_len < 0U". 142 if (resp_len < 0) 143 break; 144 145 max_blocks++; 146 147 if (mark_last_buffer_xfer_completed( ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Feb 24, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

4 years

1
0
0 0

Re: please fix incomplete distclean Makefile target

by Nicolas Boulenguez

Hello. This threads originates in a trivial fix for the 'clean' Makefile target. All contributions, even cosmetic and/or from the outside world, must follow the same formal process. Apparently, the process fails for external contributors. The discussion is visible there: https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… At this moment, there were more people involved in the discussion than letters affected by the patch, so I was invited to switch to a private mail exchange. I was asked to describe the error messages, did so, and was forgotten ever since. Almost a year has passed, the patch is neither refused nor applied. The connection error still prevents some/all external contributions. The only effect of my request so far is that I have been obliged to create accounts on github and your gerrit instance. Is there hope for a more satisfying conclusion?

4 years

2
1
0 0

Canceled event with note: TF-A Tech Forum @ Thu Feb 10, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

4 years

1
0
0 0

Is there any development roadmap(plan) for the Arm CCA features?

by Sangwan Kwon

Hi, I checked that TF-A supports FEAT_RME since v2.6. (https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html) And those are developed on rme_prototype branch. ( https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/log/?h=topics/r… ) But it is not updated since last year (September, 2021). I was wondering if there is a development plan or active branch about Arm CCA features (like RME RMM). BRs, Sangwan Kwon

4 years

2
1
0 0

Cannot successfully jump to the UEFI Boot Loader in the normal world with the RME enabled FVP_Base_RevC_2xAEMvA

by Beom Heyn Kim

Hi, With RME enabled FVP_Base_RevC_2xAEMvA, we are trying to have TF-A's BL31 successfully exit EL3 and jump to a normal world boot firmware (edk2 UEFI boot loader) instead of tftf.bin. Yet, it fails with the following log messages (showing the last 3): INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x88000000 INFO: SPSR = 0x3c9 We could boot and run RMM and tftf.bin successfully following the instructions on the TF-A documentation page ( https://trustedfirmware-a.readthedocs.io/en/latest/components/realm-managem…). While keeping build and run commands same, we tried to just replace the tftf.bin with FVP_AARCH64_EFI.fd, the build artifact of the edk2-platform for ARM ( https://github.com/tianocore/edk2-platforms/tree/master/Platform/ARM) We checked both tftf.bin and FVP_AARCH64_EFI.fd cases result in the same entry point address 0x88000000. Yet, the latter stops after exiting EL3 as aforementioned, unlike tftf.bin which successfully proceeds to run some tests afterwards. Also, we found that FVP_AARCH64_EFI.fd can boot successfully with the same fast model but without RME enabled. What is the possible reason for this symptom and the necessary tweaks we should do to address this issue? What should we look for to get some clue? Cheers,

4 years, 1 month

2
1
0 0

Re: How secondary core(s) move from TF-A into Kernel space using PSCI - 4 x A55 ?

by Manish Pandey2

Hi Yusuf, I hope you have gone through https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-… 1. Distinguishing between a cold boot and a warm boot. 2. In the case of a cold boot and the CPU being a secondary CPU, ensuring that the CPU is placed in a platform-specific state until the primary CPU performs the necessary steps to remove it from this state. 3. In the case of a warm boot, ensuring that the CPU jumps to a platform- specific address in the BL31 image in the same processor mode as it was when released from reset. Secondary cores are kept in TF-A holding pen until primary core makes a request to start secondary core(from OS through PSCI CPU_ON). On receiving this call primary breaks the condition which held secondary. For example, investigate a5ds platform's plat_secondary_cold_boot_setup() & a5ds_pwr_domain_on(). Platform also provides warm_boot_entrypoint (most platform uses bl31_warm_entrypoint) from where secondary starts execution. Primary core is responsible for platform initialization using platform helper functions mentioned https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-… (make sure your platform has implemented all the mandatory hooks). Hope this helps thanks Manish ________________________________ From: Mohd Yusuf Abdul Hamid via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 07 February 2022 02:32 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] How secondary core(s) move from TF-A into Kernel space using PSCI - 4 x A55 ? Hi, I have been stuck at this problem for more than a week. Hopefully good folks here can help clarify a few things. Platform 4x Cortex A55 single cluster. What I got working: 1. I can boot single core kernel to shell using TFA bl31 Baremetal (bare minimum startup + platform specific SOC enablement, EL3) -> TFA bl31 -> Kernel 2. I added PSCI in DT and can see the hook trigger service and hotplug secondary core in. Secondary core woke up: 1. Bare minimum startup (skip SOC specific enablement) -> TFA bl31 -> go thru 'plat_secondary_cold_boot_setup' path, using 'RESET_TO_BL31:=1' Now, I am not sure how from there, the secondary core would jump to: a. If jump to kernel's 'secondary_holding_pen' it looks like it would drop from EL3 -> EL1 and wait (however at this point Core0 is already in cpu_idle) and won't continue a.1 For this case, I am also not sure why I hit "instruction abort" in core1 - from what I read MMU hasnt been set up, which is true. I also wonder at what point MMU is set up for this path in the secondary core? b. If jump to 'secondary_entry' I believe the core is still in EL3 at this point and I will get an exception at 'set_cpu_boot_mode_flag' c. If someone can summarize what are the minimum requirements for the secondary core to get set up before jumping to 'secondary_holding_pen'/'secondary_entry' whichever is applicable. Any pointers would be much appreciated. ps: I have access to Trace32. Mohd Yusuf Abdul Hamid

4 years, 1 month

2
1
0 0

What Doc / NDA doc do I need when I want to add a new platfrom in TF-A / OPTEE? (i.e., RK3566 )

by 起飞的老杨

Hello, Everyone, If I want to add a new platform support in TF-A for RK3566 as an example, what Documentation do I need to read. Using RK3399 as a contrast ( because most of RK3399 doc is opened in internet ), we already know this SoC is supported in OPTEE and TF-A. And I can get RK3399 Docs:* TRM V1.3 Part 1*, T*RM V1.3 Part2*, *TRM V1.4 Part 1*, *Datasheet V2.1*. I can see in *TRM chapter 16 System Security, *there are some descriptions about system security, and references to other system registers, like *SGRF, *etc, but it still seems to me insufficiently ( No SGRF description ) to finish a full support platform implementation in TF-A. Some people said I need to sign an NDA with Rockchip to get Security related part docs. But when I reach to Rockchip, they said all docs are opened already, No NDA options. When I talked to one partner/distributor of Rockchip, only security related doc is also some doc I can find on internet. So I am curious and confused, can I, as a third party developer, develop a new platform implementation for TF-A / OPTEE ( specially for Rockchip Platform )? Thanks

4 years, 1 month

2
2
0 0

How secondary core(s) move from TF-A into Kernel space using PSCI - 4 x A55 ?

by Mohd Yusuf Abdul Hamid

Hi, I have been stuck at this problem for more than a week. Hopefully good folks here can help clarify a few things. Platform 4x Cortex A55 single cluster. What I got working: 1. I can boot single core kernel to shell using TFA bl31 Baremetal (bare minimum startup + platform specific SOC enablement, EL3) -> TFA bl31 -> Kernel 2. I added PSCI in DT and can see the hook trigger service and hotplug secondary core in. Secondary core woke up: 1. Bare minimum startup (skip SOC specific enablement) -> TFA bl31 -> go thru 'plat_secondary_cold_boot_setup' path, using 'RESET_TO_BL31:=1' Now, I am not sure how from there, the secondary core would jump to: a. If jump to kernel's 'secondary_holding_pen' it looks like it would drop from EL3 -> EL1 and wait (however at this point Core0 is already in cpu_idle) and won't continue a.1 For this case, I am also not sure why I hit "instruction abort" in core1 - from what I read MMU hasnt been set up, which is true. I also wonder at what point MMU is set up for this path in the secondary core? b. If jump to 'secondary_entry' I believe the core is still in EL3 at this point and I will get an exception at 'set_cpu_boot_mode_flag' c. If someone can summarize what are the minimum requirements for the secondary core to get set up before jumping to 'secondary_holding_pen'/'secondary_entry' whichever is applicable. Any pointers would be much appreciated. ps: I have access to Trace32. Mohd Yusuf Abdul Hamid

4 years, 1 month

1
0
0 0

Re: GIC-600 errata 1717652: missed wake requests

by Bipin Ravi

Hi Okash, In TF-A project, we haven't supported errata patches for system IP's like GIC-600 until now. We typically support Cat B errata patches for Arm CPU implementations that are made public. Additionally we also support DSU errata patches for the TF-A supported CPUs as applicable. But we are more than happy to support any code reviews required for the implementation of the below said errata. Thanks, Bipin -----Original Message----- From: tf-a-request(a)lists.trustedfirmware.org <tf-a-request(a)lists.trustedfirmware.org> Sent: Thursday, January 27, 2022 6:00 PM To: tf-a(a)lists.trustedfirmware.org Subject: TF-A Digest, Vol 37, Issue 16 1. GIC-600 errata 1717652: missed wake requests (Okash Khawaja) ---------------------------------------------------------------------- Message: 1 Date: Thu, 27 Jan 2022 13:36:32 +0000 From: Okash Khawaja <okash(a)google.com> Subject: [TF-A] GIC-600 errata 1717652: missed wake requests To: tf-a(a)lists.trustedfirmware.org Message-ID: <CAGjWKv6TTLVvF7GfsmY76QFjSzcSX8DqPuPukJQAOH-AqAvuLg(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Hi, It seems like TF-A's GIC600 driver currently doesn't have support for the Cat B errata 1717652 "Wake_request may not be delivered if multiple cores are woken by PPIs at the same time". Are there plans to support this? Thanks, Okash ------------------------------ Subject: Digest Footer TF-A mailing list -- tf-a(a)lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org ------------------------------ End of TF-A Digest, Vol 37, Issue 16 ************************************

4 years, 1 month

2
1
1 0

GIC-600 errata 1717652: missed wake requests

by Okash Khawaja

Hi, It seems like TF-A's GIC600 driver currently doesn't have support for the Cat B errata 1717652 "Wake_request may not be delivered if multiple cores are woken by PPIs at the same time". Are there plans to support this? Thanks, Okash

4 years, 1 month

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Jan 27, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Agenda for Session on 27th January 2020Introduction of Arm CCA Context ManagementSession Presented by: Manish Pandey, Soby Mathew and Zelalem AwekeDetails: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3.We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   (changed) When: Thu Jan 27, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 1 month

1
0
1 0

TF-A Technical Forum Session Agenda this week

by Joanna Farley

Agenda for Session on 27th January 2020 * Introduction of Arm CCA Context Management * Session Presented by: Manish Pandey, Soby Mathew and Zelalem Aweke * Details: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3. We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https://www.trustedfirmware.org/meetings/tf-a-…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https://zoom.us/j/9159704974&sa=D&source=calen…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https://zoom.us/u/ad27hc6t7h&sa=D&source=calen…>

4 years, 1 month

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Jan 27, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Agenda for Session on 27th January 2020introduction of Arm CCA Context ManagementSession Presented by: Manish Pandy, Soby Mathew and Zelalem AwekeDetails: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3.We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   (changed) When: Thu Jan 27, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 1 month

1
0
0 0

RFC for context management refactoring in TF-A

by Soby Mathew

Hello Everyone, We have a proposal to refactor the Context management framework in TF-A and an RFC is pushed for review here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/13651 . The abstract of the RFC is given below: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3. The plus point here is that many of the design principles are already adhered to in one way or other in the current the implementation so much of the work can be done in an incremental fashion without much disruption. Along with @Zelalem Aweke<mailto:Zelalem.Aweke@arm.com> and @Manish Pandey2<mailto:Manish.Pandey2@arm.com>, we hope to discuss the this RFC and how this translates to code changes in TF-A during the Tech Forum this week. Best Regards Soby Mathew

4 years, 1 month

1
0
0 0

About arm_validate_ns_entrypoint in arm_pm.c

by Ming Huang

Hi, arm_validate_ns_entrypoint() in plat/arm/common/arm_pm.c check ARM_NS_DRAM1_BASE and ARM_NS_DRAM2_BASE only, for some platform there are include more than two non-secure dram areas. It will bring dependencies between TF-A and physical memory space which can get from uefi atfer memory initialization, if arm_validate_ns_entrypoint() include the entire physical memory space. In my mind, the kernel should guarantee the validity of entry point. So why this check is need? Thanks, Ming

4 years, 1 month

3
3
0 0

imx8mm-evk does not boot kernel 5.16 with mainline TF-A

by Fabio Estevam

Hi, I am running U-Boot 2022.01 on imx8mm-evk. If I build the NXP vendor-based TF-A (imx_5.4.47_2.2.0) I am able to boot kernel 5.16 just fine. However, if I use the upstream TF-A (v2.5 or v2.6), the kernel fails to boot most of the attempts. Peng, Jacky, Could you please try booting kernel 5.16 + U-Boot 2022.01 built with TF-A v2.6? What is missing in upstream TF-A to be able to boot kernel 5.16? Thanks, Fabio Estevam

4 years, 1 month

2
1
0 0

fw update & anti-rollback versioning

by Etienne CARRIERE

Dear all, (and may the new year be happy to you and your beloved) In the course of evaluating the FW update flows for systems with FIP images, we identified the following requirements: Req1: The FIP image, or the components in the FIP, must have a version field. Each version field will be compared against the anti-rollback counter of the platform that the FIP or its component is bound to. Req2: We must be able to increment the FIP version field (though a FIP image FW update) without affecting the anti-rollback counter value. The anti-rollback counter should be incremented only for security updates upon explicit request. Req3: The version field should be present even if the FIP does not contain image certificates. Currently the FIP carries a version field in the different certificates, the anti-rollback counters are updated every time the root certificate value increased. This is not flexible enough and does not allow trial/acceptance of updates. Can we open a discussion on how to enhance the version/anti-rollback counter update in TF-A? Best regards, Etienne Carriere ST Restricted

4 years, 1 month

4
6
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A