July 2023 - TF-A - lists.trustedfirmware.org

Need a mechanism to easily define platform-independent SMC FIDs

by Julius Werner

Hi, I would like to restart a discussion that we already had a few years ago on a thread called "SMC to intentionally trigger a panic in TF-A" (https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…) but that petered out without any real resolution (and resulted in me ultimately not implementing the feature I was hoping to add). Basically, we are repeatedly stumbling over the problem that we have a use case for some platform-independent SMC API that we want to implement in TF-A, but don't have an appropriate SMC FID range to put it. My request from a few years ago was about implementing a call to intentionally trigger a panic in TF-A for test-automation purposes. Today we came up with a use case where a Trusted OS wants to query BL31 about the location of a shared log buffer: https://review.trustedfirmware.org/20478 . Currently, the available SMC ranges are Arm, CPU, SiP, OEM, Standard, Hypervisor, TA and TOS. The SiP, OEM and TOS ranges are all specific to a single silicon vendor, OEM or trusted OS implementation, so they are not good targets to implement APIs that would make sense to be shared among multiple of these. In theory, the Standard range would probably be the right target to implement calls that are independently useful for multiple platforms / OSes... but as far as I understand, adding a new call to that range requires petitioning Arm to update the SMC calling convention itself, which is a ridiculously high bar to implement a small utility API. In practice, the only choice we have for implementing these kinds of calls is to let every OEM, SiP or TOS assign its own (different) FID for it and then write separate SMC handlers for each in TF-A that all end up calling the same underlying function... which creates a lot of unnecessary code duplication and identifier soup (especially in the case of SMCs for the non-secure OS which would then be implemented by a platform-independent Linux driver that needs a big mapping table to decide which FID to use on which platform for the same API). I think it would be very useful if there was another range of easily allocatable FIDs that developers could just add to with a simple TF-A CL without having to go through a huge specification update process. There are still 41 OENs unused in the Arm SMCCC, and I don't think any new ones were added in the 10 years that the specification existed... so we are really not going to run out of them any time soon. If we could get even one of those OENs for this purpose, we would have 64K FIDs to use up for our small, simple platform-independent API needs, which should last us a long while. We could maybe call it the "Secure Monitor range" and say the FIDs are specific to a certain implementation of Secure Monitor (e.g. TF-A). Then there could just be a header file in the TF-A sources that serves as the authoritative FID assignment table for TF-A, and anyone with a sufficiently useful idea (subject to TF-A maintainer review) for a platform-independent API like this could add it there by just uploading a patch. I recently argued for a similar "simple tag allocation" concept on https://github.com/FirmwareHandoff/firmware_handoff and it found support there, so I hope I'll be able to convince you that it would be useful for SMC FIDs as well?

3 months

3
3
0 0

Convert fiptool to Python script

by Varun Wadekar

Hello, We use fiptool extensively to generate the FIP blobs for NVIDIA platforms. But, we encountered the following issues during deployment. 1. fiptool has a dependency on the host machine for OpenSSL and gcc. 2. fiptool resides under the TF-A repo and is used by Hafnium and SPs. This creates a cross-repository dependency. As a workaround, we ship a prebuilt fiptool. But, due to OS dependency, this approach is not scalable across OS versions. E.g. One OS distribution might be using a lower OpenSSL version compared another, creating an incompatibility. I was thinking if converting fiptool to a python script might help resolve these issues. Sptool was converted into a Python script, so was wondering if anyone has tried converting fiptool to a Python script too. -Varun

10 months

3
9
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 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 2 of 2 defect(s) ** CID 397932: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /lib/extensions/amu/aarch64/amu.c: 212 in amu_init_el3() ________________________________________________________________________________________________________ *** CID 397932: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /lib/extensions/amu/aarch64/amu.c: 212 in amu_init_el3() 206 } 207 } 208 209 void amu_init_el3(void) 210 { 211 uint64_t group0_impl_ctr = read_amcgcr_el0_cg0nc(); >>> CID 397932: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "1 << group0_impl_ctr" with type "int" (32 bits, signed) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 212 uint64_t group0_en_mask = (1 << (group0_impl_ctr)) - 1U; 213 uint64_t num_ctr_groups = read_amcfgr_el0_ncg(); 214 215 /* Enable all architected counters by default */ 216 write_amcntenset0_el0_px(group0_en_mask); 217 ** CID 397931: (DEADCODE) /plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c: 153 in bl31_early_platform_setup2() /plat/imx/imx8m/imx8mn/imx8mn_bl31_setup.c: 150 in bl31_early_platform_setup2() /plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c: 146 in bl31_early_platform_setup2() ________________________________________________________________________________________________________ *** CID 397931: (DEADCODE) /plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c: 153 in bl31_early_platform_setup2() 147 imx_csu_init(csu_cfg); 148 149 #if IMX_BOOT_UART_BASE 150 console_base = IMX_BOOT_UART_BASE; 151 #endif 152 if (console_base == 0U) { >>> CID 397931: (DEADCODE) >>> Execution cannot reach this statement: "console_base = imx8m_uart_g...". 153 console_base = imx8m_uart_get_base(); 154 } 155 156 console_imx_uart_register(console_base, IMX_BOOT_UART_CLK_IN_HZ, 157 IMX_CONSOLE_BAUDRATE, &console); 158 /* This console is only used for boot stage */ /plat/imx/imx8m/imx8mn/imx8mn_bl31_setup.c: 150 in bl31_early_platform_setup2() 144 mmio_write_32(IMX_IOMUX_GPR_BASE + 0x2c, val | 0x3DFF0000); 145 146 #if IMX_BOOT_UART_BASE 147 console_base = IMX_BOOT_UART_BASE; 148 #endif 149 if (console_base == 0U) { >>> CID 397931: (DEADCODE) >>> Execution cannot reach this statement: "console_base = imx8m_uart_g...". 150 console_base = imx8m_uart_get_base(); 151 } 152 153 console_imx_uart_register(console_base, IMX_BOOT_UART_CLK_IN_HZ, 154 IMX_CONSOLE_BAUDRATE, &console); 155 /* This console is only used for boot stage */ /plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c: 146 in bl31_early_platform_setup2() 140 mmio_write_32(IMX_IOMUX_GPR_BASE + 0x2c, val | 0x3DFF0000); 141 142 #if IMX_BOOT_UART_BASE 143 console_base = IMX_BOOT_UART_BASE; 144 #endif 145 if (console_base == 0U) { >>> CID 397931: (DEADCODE) >>> Execution cannot reach this statement: "console_base = imx8m_uart_g...". 146 console_base = imx8m_uart_get_base(); 147 } 148 149 console_imx_uart_register(console_base, IMX_BOOT_UART_CLK_IN_HZ, 150 IMX_CONSOLE_BAUDRATE, &console); 151 /* This console is only used for boot stage */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 year

1
0
0 0

FYI: Session on OpenCI and MISRA

by Don Harbin

Hi All, I wanted to let you know that next Thursday, July 27th, the TF-A Tech Forum will be hosting a presentation on OpenCI and MISRA presented by Paul Sokolovski of Linaro and Roberto Bagnara from Bugseng. MISRA is being enabled on both TF-A and TF-M in OpenCI, so sending this out to both lists since users in both domains may be interested in the session. Meeting time and dial up info can be found in the TF community calendar located here: https://www.trustedfirmware.org/meetings/ Best Regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

1 year

1
0
0 0

The increasing size of BL31

by Okash Khawaja

Hi, Typically, BL31 runs in SRAM which tends to be limited. As we add support for newer architectural features e.g. CCA, general features and standards, the size of BL31 image will grow and become harder to fit in most SRAMs. This email is to share ideas on how to address this problem. A simple approach will be to identify parts of NOBITS ELF sections of BL31 which can be moved out to DRAM. Since NOBITS sections aren't part of the file image, loading and authentication code doesn't have to change. The challenge will be to come up with some criteria to help decide what kind of buffers can be kept in DRAM vs SRAM. Other ideas are also welcome. Please share your thoughts. Thanks, Okash

1 year

3
2
0 0

Trusted Firmware-A LTS v2.8.7 Release Announcement

by Okash Khawaja

Hello, Trusted Firmware-A LTS version 2.8.7 is now available. This release contains the following patches. 37bee4983 fix(build): allow warnings when using lld [1] 8782b8849 build(makefile): add helper to detect linker options [2] 1fdc9797f feat(build): add support for new binutils versions [3] bb9d6faa4 feat(errata_abi): errata management firmware interface [4] 4a001ffb6 refactor(errata_abi): factor in non-arm interconnect [5] f718c8723 fix(cpus): workaround platforms non-arm interconnect [6] b8bb1e347 feat(fvp): enable errata management interface [7] 66dab5c69 docs(errata_abi): document the errata abi changes [8] [1] https://review.trustedfirmware.org/q/I70503ad03b3be7a18ffe29ef6f2127c3f4d54… [2] https://review.trustedfirmware.org/q/I236800852ece49948ff53a0b91fddba53c8f0… [3] https://review.trustedfirmware.org/q/I9430f5fa5036ca88da46cd3b945754d62616b… [4] https://review.trustedfirmware.org/q/I70f0e2569cf92e6e02ad82e3e77874546232b… [5] https://review.trustedfirmware.org/q/I47b03eaee5a0a763056ae71883fa30dfacb9b… [6] https://review.trustedfirmware.org/q/I35bd69d812dba37410dd8bc2bbde20d4955b0… [7] https://review.trustedfirmware.org/q/I30877a22ac1348906a6ddfb26f9e8839912d3… [8] https://review.trustedfirmware.org/q/Ieb2144a1bc38f4ed684fda8280842a18964ba… Thanks, Okash

1 year

1
0
0 0

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

by Olivier Deprez

Hi, We have two topics for the upcoming TF-A Tech Forum on Jul, 13th: Certificate signer-id retrieval - Manish Badarkhe * Quick recap * Authentication Mechanism * Role of public key * What is signer ID and its usage? * Design of signer ID retrieval for attestation Updates to EL3 vector entry path to cater for async EA(SError) exceptions - Manish Pandey * Description of error synchronization during EL3 entry. * Go through the implementation of handling of these errors in EL3 for Firmware First Handling (FFH) scenarios. * Reflecting it back in Kernel First Handling (KFH) scenario. * Description of the test scenarios introduced. Regards, Olivier. ________________________________ From: Trusted Firmware Public Meetings Sent: 14 June 2020 19:21 To: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) When: 13 July 2023 17:00-18:00. Where: You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

1 year

1
1
0 0

TF-A Tech Forum Jul 13th

by Olivier Deprez

Olivier Deprez is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://armltd.zoom.us/j/95599443425?pwd=UTRIZ2xSSHJ3K1EreHpkRmlDWmppdz09&f… Meeting ID: 955 9944 3425 Passcode: 572750 --- One tap mobile +442034815240,,95599443425#,,,,*572750# United Kingdom --- Dial by your location • +44 203 481 5240 United Kingdom • +1 408 638 0968 US (San Jose) • +1 646 518 9805 US (New York) • +1 346 248 7799 US (Houston) • +91 806 480 2722 India • +91 116 480 2722 India • +91 224 879 8012 India • +91 406 480 2722 India • +852 5803 3730 Hong Kong SAR • +46 8 4468 2488 Sweden • +47 2400 4735 Norway • +972 3 978 6688 Israel • +353 1 536 9320 Ireland • +36 1 408 8456 Hungary • +49 69 3807 9883 Germany • +33 1 7037 2246 France • +358 3 4109 2129 Finland • +45 32 70 12 06 Denmark • +1 438 809 7799 Canada • +82 2 3143 9611 Korea, Republic of • +65 3158 7288 Singapore • +27 87 550 3946 South Africa • +32 1579 5132 Belgium • +48 22 307 3488 Poland • +386 1600 3102 Slovenia • +60 3 3099 2229 Malaysia • +886 (2) 7741 7473 Taiwan • +81 3 4578 1488 Japan Meeting ID: 955 9944 3425 Passcode: 572750 Find your local number: https://armltd.zoom.us/u/as6SKF17s --- Join by SIP • 95599443425(a)zoomcrc.com --- Join by H.323 • 162.255.37.11 (US West) • 162.255.36.11 (US East) • 115.114.131.7 (India Mumbai) • 115.114.115.7 (India Hyderabad) • 213.19.144.110 (Amsterdam Netherlands) • 213.244.140.110 (Germany) • 103.122.166.55 (Australia Sydney) • 103.122.167.55 (Australia Melbourne) • 209.9.211.110 (Hong Kong SAR) • 149.137.40.110 (Singapore) • 64.211.144.160 (Brazil) • 69.174.57.160 (Canada Toronto) • 65.39.152.160 (Canada Vancouver) • 207.226.132.110 (Japan Tokyo) • 149.137.24.110 (Japan Osaka) Meeting ID: 955 9944 3425 Passcode: 572750

1 year

1
0
0 0

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

by Sandrine Bailleux

Hi Manish, I'll answer on behalf of Benjamin and Sieu because I think they are offline now. I reached out to these guys privately this morning and they said they will post patches to fix these defects. Cheers, Sandrine

1 year

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 5 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 395330: Code maintainability issues (UNUSED_VALUE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 182 in get_clk_freq() ________________________________________________________________________________________________________ *** CID 395330: Code maintainability issues (UNUSED_VALUE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 182 in get_clk_freq() 176 case 0: 177 pllm_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLM; 178 pllc_reg = CLKMGR_MAINPLL + main_pllc; 179 pllglob_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLGLOB; 180 break; 181 case CLKMGR_PSRC_PER: >>> CID 395330: Code maintainability issues (UNUSED_VALUE) >>> Assigning value "282132672U" to "pllm_reg" here, but that stored value is overwritten before it can be used. 182 pllm_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLM; 183 pllc_reg = CLKMGR_PERPLL + per_pllc; 184 pllglob_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLGLOB; 185 break; 186 default: 187 return 0; ** CID 395329: Code maintainability issues (UNUSED_VALUE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 183 in get_clk_freq() ________________________________________________________________________________________________________ *** CID 395329: Code maintainability issues (UNUSED_VALUE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 183 in get_clk_freq() 177 pllm_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLM; 178 pllc_reg = CLKMGR_MAINPLL + main_pllc; 179 pllglob_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLGLOB; 180 break; 181 case CLKMGR_PSRC_PER: 182 pllm_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLM; >>> CID 395329: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "282132604U + per_pllc" to "pllc_reg" here, but that stored value is overwritten before it can be used. 183 pllc_reg = CLKMGR_PERPLL + per_pllc; 184 pllglob_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLGLOB; 185 break; 186 default: 187 return 0; 188 } ** CID 395328: Control flow issues (DEADCODE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 181 in get_clk_freq() ________________________________________________________________________________________________________ *** CID 395328: Control flow issues (DEADCODE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 181 in get_clk_freq() 175 switch (clk_psrc) { 176 case 0: 177 pllm_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLM; 178 pllc_reg = CLKMGR_MAINPLL + main_pllc; 179 pllglob_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLGLOB; 180 break; >>> CID 395328: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "case 1U:". 181 case CLKMGR_PSRC_PER: 182 pllm_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLM; 183 pllc_reg = CLKMGR_PERPLL + per_pllc; 184 pllglob_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLGLOB; 185 break; 186 default: ** CID 395327: Code maintainability issues (UNUSED_VALUE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 184 in get_clk_freq() ________________________________________________________________________________________________________ *** CID 395327: Code maintainability issues (UNUSED_VALUE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 184 in get_clk_freq() 178 pllc_reg = CLKMGR_MAINPLL + main_pllc; 179 pllglob_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLGLOB; 180 break; 181 case CLKMGR_PSRC_PER: 182 pllm_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLM; 183 pllc_reg = CLKMGR_PERPLL + per_pllc; >>> CID 395327: Code maintainability issues (UNUSED_VALUE) >>> Assigning value "282132636U" to "pllglob_reg" here, but that stored value is overwritten before it can be used. 184 pllglob_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLGLOB; 185 break; 186 default: 187 return 0; 188 } 189 pllm_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLM; ** CID 395326: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 395326: Uninitialized variables (UNINIT) /plat/intel/soc/agilex5/bl2_plat_setup.c: 74 in bl2_el3_early_platform_setup() 68 { 69 static console_t console; 70 71 handoff reverse_handoff_ptr; 72 73 generic_delay_timer_init(); >>> CID 395326: Uninitialized variables (UNINIT) >>> Using uninitialized value "reverse_handoff_ptr.hps_osc_clk_hz" when calling "config_clkmgr_handoff". 74 config_clkmgr_handoff(&reverse_handoff_ptr); 75 mailbox_init(); 76 enable_nonsecure_access(); 77 78 deassert_peripheral_reset(); 79 if (combo_phy_init(&reverse_handoff_ptr) != 0) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 year

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

TF-A July 2023