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

Trusted Firmware v2.10 Release Announcement

by Olivier Deprez

Hi All, We are pleased to announce the formal release of Trusted Firmware-A version 2.10 bundle of project deliverables. This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, RMM and TF-A OpenCI Scripts/Jobs 2.10 releases involving the tagging of multiple repositories. These went live on 22nd November 2023. Please find references to tags and change logs at the end of this email. Many thanks to the community for the active engagement in delivering this release! Notable Features of the Version 2.10 Release are as follows: TF-A/EL3 Root World * New Features: * Firmware handoff library support * Improvements to BL31 runtime exception handling * Context management refactoring for RME/4 worlds * Gelas, Nevis & Travis CPUs support * V8.9 features enabled (FEAT_ HAFT, RPRFM, LRCPC3, MTE_PERM) TF-A Boot BL1/BL2 * New Features * Trusted Boot support for ECDSA (Elliptic Curve Digital Signature Algorithm) * Migrated to PSA crypto API’s * Improved the GUID Partition Table (GPT) parser. * Various security Improvements and threat Model updates for ARM CCA * Signer id extraction Implementation Hafnium/SEL2 SPM * New Features: * FF-A v1.2: FFA_YIELD with time-out; EL3 SPMDs LSPs communication; memory sharing updates. * Memory region relative base address field support in SP manifests. * Interrupt re-configuration hypervisor calls. * Memory management: S2 PT NS/S IPA split * SMCCCv1.2+ compliance fixes. * Feature parity test improvements, EL3 SPMC and Hafnium (S-EL2 SPMC) TF-RMM/REL2 * New Feature/Support * Fenimore v1.0 EAC5 aligned implementation. * TFTF Enhancements for RME testing * Initial CBMC support * NS SME support in RMM * BTI support for RMM Errata * Errata implemented (1xCortex-X2/ Matterhorn-ELP, 1xCortex-A710/Matterhorn, 1xNeoverse N2/Perseus, 2xNeoverse V2/Demeter, Makalu ELP/Cortex X3, Klein/Cortex-A510) * Fix some minor defects with version in a few errata that applies for some follow up revisions of the CPUs. (Neoverse V1, Cortex-X2, Cortex-A710) TF-A Tests * Core * Added errata management firmware interface tests. * Added firmware handoff tests. * Introduced RAS KFH support test. * SPM/FF-A * Support SMCCCv1.2 extended GP registers set. * Test SMCCC compliance at the non-secure physical instance. * Test secure eSPI interrupt handling. * Test FF-A v1.2 FFA_PARTITION_INFO_GET_REGS interface. * RMM * Added FPU/SVE/SME tests * Added multiple REC single CPU tests. * Added PAuth support in Realms tests. * Added PMU tests. Platform Support * New platforms added: * Aspeed AST2700, NXP IMX93, Intel Agilex5, Nuvoton NPCM845x, QTI MDM9607, MSM8909, MSM8939, ST STM32MP2 Release tags across repositories: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.10 https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/tf-a-job-configs.git/tag/?h=v2.10 https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/hafnium-ci-scripts.git/tag/?h=v2.10 https://git.trustedfirmware.org/ci/hafnium-job-configs.git/tag/?h=v2.10 https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tag/?h=tf-rmm-v0.4.0 Change logs: https://trustedfirmware-a.readthedocs.io/en/v2.10/change-log.html#id1 https://trustedfirmware-a-tests.readthedocs.io/en/v2.10/change-log.html#ver… https://hafnium.readthedocs.io/en/latest/change-log.html#v2-10 https://tf-rmm.readthedocs.io/en/tf-rmm-v0.4.0/about/change-log.html#v0-4-0 Regards, Olivier.

6 months, 4 weeks

1
1
0 0

Firmware-A v2.10 release code freeze notification

by Olivier Deprez

Hi All, The next release of the Firmware-A bundle of projects tagged v2.10 has an expected code freeze date of Nov, 7th 2023. Refer to the Release Cadence section from TF-A documentation (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about…). Closing out the release takes around 6-10 working days after the code freeze. Preparations tasks for v2.10 release should start in coming month. We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude. As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.: -For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run). -For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 in the middle of the patch stack). -Carefully analyze results and fix the change if required, before launching new jobs on the same change. -If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued. Thanks & Regards, Olivier.

7 months, 1 week

1
3
0 0

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?

8 months

3
3
0 0

All if...else if constructs shall be terminated with an else statement.

by Nithin G

Hello, In the file lib/xlat_tables/xlat_tables_common.c and other associated files, there are instances where if...else if constructs lack an else statement, resulting in violations during the Coverity MISRA-C analysis for the ZynqMP platform. Addressing this issue added empty else statement to resolve the issue but it is related to core translational table logic function. Is it possible to address this issue? Please provide your suggestions. Regards, Nithin G

9 months, 3 weeks

4
12
0 0

Handling of normal world interrupts with BL31 PSCI handler

by caleb.ethridge＠analog.com

Hello, If normal world interrupts are received while invoking TF-A's PSCI reset handler, we have observed that the reset can be aborted. In TF-A's PSCI reset handler, a call out to OP-TEE is made before performing the platform-specific reset: https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/p… https://github.com/ARM-software/arm-trusted-firmware/blob/master/services/s… When OP-TEE is entered, it is possible to receive foreign (normal world) interrupts, which invokes the procedure described here: https://optee.readthedocs.io/en/3.16.0/architecture/core.html#deliver-non-s… When the SMC call is aborted as described above, this results in the reboot failing. Linux does not retry the PSCI reset (https://github.com/torvalds/linux/blob/master/drivers/firmware/psci/psci.c#…). This makes sense because it is not expecting the SMC call to fail (it expected to make an uninterruptable SMC call into the secure monitor, not a call into OP-TEE). If OP-TEE itself is setup to handle PSCI reset calls, it also handles them in (uninterruptable) SMC context: https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/psci.c#L140 https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/sm_a32.S#L96 Based on this, we see two possible solutions: a) Masking the non-secure interrupts in BL31 while we are doing a reset b) Removing the call to OPTEE in the reset handler so that we never leave the SMC context Which option do you suggest? Or are we missing an important detail here? Thanks, Caleb

10 months, 3 weeks

6
11
0 0

Declaration uses a different parameter type than the function Definition.

by Nithin G

Hello, In the file /plat/xilinx/zynqmp/aarch64/zynqmp_common.c, there is a function named plat_get_syscnt_freq2 with its definition. Simultaneously, the declaration of this function is included in include/plat/common/platform.h with the name plat_get_syscnt_freq2 and a different parameter type, leading to a violation when running the Coverity MISRA-C analysis for the Zynqmp platform. Declaration uses a different parameter type than the function Definition. Addressing this issue by introducing a typedef for plat_get_syscnt_freq2 in platform.h and specifying its type as uint32_t resolves the violation. However, it introduces a challenge for other platforms, as this modification necessitates similar changes across various platforms, causing violations in those areas due to the adjusted typedef. Is it possible to fix with the typedef? Please suggest. Regards, Nithin

11 months

3
5
0 0

Cache Maintenance For SiP buffers

by Ahmad Fatoum

Hi, I was looking at imx_hab_handler, which forwards calls into the BootROM on i.MX SoCs in response to secure monitor calls. The BootROM call (and thus the SiP call) accepts two pointers as arguments, where it writes data. The plat/imx/imx8m/imx8m*/imx8m*_bl31_setup.c files map the RAM as MT_MEMORY | MT_RW, which would mean that not only is it writable from TF-A side, but it's also mapped cacheable. I see no explicit cache maintenance in the i.MX SiP code for these two pointer arguments and haven't been successful to find where in TF-A core code if at all, complete D-Cache is flushed on SMC exit. Therefore I ask: - Don't shared non-secure memory buffers between EL3 and lower EL require explicit cache maintenance? - Did I miss the place where this cache maintenance is done? - How did it work so far? barebox does explicit flushing before HAB SiP, invalidation after. U-Boot doesn't do cache maintenance. Both apparently work... Thanks, Ahmad --- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

11 months, 1 week

3
11
0 0

Violations MISRA_15.1 and 15.5 when running the Coverity MISRA-C analysis.

by Nithin G

1. misra_c_2012_rule_15_1_violation: Using "goto" statement. In the file common/bl_common.c and other related files, getting misra_c_2012_rule_15_1_violation: Using "goto" statement. during the Coverity MISRA-C analysis. if (...) { goto exit; } exit: some operation Resolution: goto statement is replaced with exit_func() and new variable is introduced to store the return value of exit_func(). exit_func() some operation int ret; if (...) { ret = return value of exit func() } return ret; Is it possible to fix MISRA 15.1 like this in open source? Please suggest. 2. misra_c_2012_rule_15_5_violation: This return statement is not the final statement in the compound statement that forms the body of the function. In the file common/bl_common.c, lib/xlat_tables/aarch64/xlat_tables.c and other related files, getting misra_c_2012_rule_15_5_violation: This return statement is not the final statement in the compound statement that forms the body of the function. during the Coverity MISRA-C analysis. if (...) { return <something> } if (...) { return <something> } return; Resolution: Taken new variable and assign the return result to new variable and calling only one return statement in end of the function. int result; if (...) { result = <something> } else { if (...) { result = <something> } } return result; Is it possible to fix MISRA 15.5 like this in open source? Please suggest. Thanks & Regards, Nithin G

11 months, 2 weeks

2
3
0 0

Minor updates to the tf.org project maintenance

by Sandrine Bailleux

Hello TF-A and TF-M communities, I've done 2 minor updates to the generic tf.org project maintenance process, which TF-A and TF-M both use. Please see the pull request here: https://github.com/TrustedFirmware/tf_docs/pull/1 Please provide your feedback on the pull request, if any. Happy end-of-year celebrations to all! Best regards, Sandrine

1 year

1
0
0 0

Stack usage details with armclang TF-A build

by mail2diggi＠gmail.com

Dear all, we want analyze stack usage details when we build TF-A for armclang compiler but we are not able generate stack usage details. sorry for long thread and question please go through and suggest way forward to perform stack analysis with TF-A armclang build. as per https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/initial-… (section 2.3) when CC is set to armclang, GCC linker is used default (since the TF-A build system doesn’t currently support Arm Scatter files) So when we try to generate stack usage details we will not be able to use GCC -fstack-usage and -fdump-ipa-calgraph since CC is set to armclang and these flags will be un-recognized. Since we are building this for armclang we attempted to use following armlinker flags along with -g compiler flag (refer link:https://developer.arm.com/documentation/100748/0607/writing-optimized-…). --info=stack, --calgrapth, --calgraph_output=text But we end up with unrecognized options error for --info=stack, --calgrapth, --calgraph_output=text This error occurs because GCC linker is used default as per above link section 2.3 (since the TF-A build system doesn’t currently support Arm Scatter files) So we end up with not having stack usage details generated. Q1: Any suggestion to generate stack usage when CC=armclang and GCC linker is used by default. Q2: if we attempt to change LD with armlink we will end up with "Fatal error: L6031U: Could not open scatter description file." https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/initial-… section 2.3 suggest that "that the default linker may be manually overridden using the LD variable" can you please let us know how to override LD with armlinker without getting scatter issue. Using: armclang 6.6.2 version. Thank you Shivakumar Diggi

1 year

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-A December 2023