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.10https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/tf-a-job-configs.git/tag/?h=v2.10https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/hafnium-ci-scripts.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/hafnium-job-configs.git/tag/?h=v2.10https://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#id1https://trustedfirmware-a-tests.readthedocs.io/en/v2.10/change-log.html#ver…https://hafnium.readthedocs.io/en/latest/change-log.html#v2-10https://tf-rmm.readthedocs.io/en/tf-rmm-v0.4.0/about/change-log.html#v0-4-0
Regards,
Olivier.
Hi Everyone,
The initial integration of CBMC (C Bounded Model checking) for TF-RMM has been merged. Please refer to the application note here for more details on how to trigger CBMC analysis/coverage/assert targets on TF-RMM implementation : https://tf-rmm.readthedocs.io/en/latest/resources/application-notes/cbmc.ht…
Best Regards
Soby Mathew
Hi,
I wonder if there is or there is a plan to develop a dedicated tool that allows a realm developer to calculate Realm Initial Measurements (RIMs) for realms(?)
As you know, the remote attestation mechanism requires a verifier to be provisioned with reference values. In this case, a realm verifier should have access to the initial reference measurement (RIM) of a realm that is intended to be run on a remote Arm CCA platform.
The algorithm that measures the initial state of realms (RIM) is higly sensitive to the content of a realm memory and the order of RMI operations. This means that not only the content of populated realm memory matters but also the implementation of the host components (e.g. kvm, kvmtool/qemu). For example, in the reference implementation of https://gitlab.arm.com/linux-arm/kvmtool-cca, the layout of memory and the content of DTB highly depend on the provided options (DTB is generated in run-time). Unfortunatelly, the content of DTB also depends on the linking order of object files (the order of DTB generation is imposed by __attribute__((constructor)) that is used to register devices). This complicates development of a separate tool for caclulating RIM, as the tool would have to emulate all quirks of the kvmtool.
One of the solution of retrieving Realm Initial Measurements seems to be running the whole firmware/software (e.g. kvmtool/Linux host/TF-RMM) stack on the FVP emulator and gathering the RIM directly from the TF-RMM. This would require a realm developer to have access to the whole firmware/software stack and the emulator of the CCA platform. This might not always be an option.
The other solution would require the implementation of a dedicated tool. For instance, a sensible approach could be to extend the functionality of kvmtool, which can be run on an ordinary Linux machine.
Is Arm going to develop a dedicated tool(-s) for calculating RIMs?
What is the recommended way of retrieving/calculating RIMs for realms?
Kind regards,
Piotr
Hello all,
We have added a GitHub workflow to RMM which allows the former to build
and run the unittests along with their corresponding coverage report
and upload such report in .html format to GitHub.
The workflow is automatically triggered when new pushes are done to the
main branch.
In order to access to the coverage report, you can either
* click on the green check symbol next to the latest commit, from
there to "details" on the "Coverage on unittests for RMM" action on
the pop up window and once in the action page, click on "Summary" on
the left side menu. The report will appear in the "Artifacts"
section as a .zip file with the name "coverage-results" or
* On the TF-RMM repo main page, click on "Actions" and then click on
the "Coverage on unittests for RMM" action corresponding to the
latest commit. You can then access to the report as explained on the
previous bullet.
Please keep in mind that reports older than 90 days will be
automatically deleted.
Thanks,
Javier
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi All,
Please review the patch-set that adds the functionality in RMM to manage Scalable Matrix Extension (SME) context. If the CPU supports SME and if Realm accesses FPU/SVE functionality then NS SME state is saved to allow Realm to use FPU/SVE register state.
https://review.trustedfirmware.org/q/topic:%22rmm_sme%22+(status:open%20OR%…
Brief summary of changes made in different components:
RMM:
- Introduces SIMD context and exports APIs to the runtime component of RMM to initialize, save, restore, and switch SIMD context.
- Adds SME support in RMM to manage NS SME context. Supports SVE+SME config and SME only config.
- Handles SVE hint bit passed in RMI SMCs
- Handles SME exceptions from Realms
https://review.trustedfirmware.org/q/topic:%22rmm_sme%22+(status:open%20OR%…
TF-A:
- Enables FEAT_SME for RMM
- Passes SMCCCv1.3 SVE hint bit in SMC function ID to RMM
tf-a-tests:
- There are changes in common lib routines for sve, sme so that testcases running in NS-EL2, S-EL1, R-EL1 can use these helper routines.
- Adds helper routines to read, write, compare FPU and SVE Z, P, FFR registers
- Adds SMCCCv1.3 SVE hint bit support in TFTF framework
- Enables SME/SME2 during arch init
- Adds SME helper routines and extends SVE lib routines to support streaming SVE mode.
https://review.trustedfirmware.org/q/topic:%22rmm_sme%22+(status:open%20OR%…
Thanks,
Arun
Hello all,
We currently have a patch under review [1] which will break the existing dependency between 'run-converage' and 'run-unittests' rules in the RMM build system.
This means that once the patch is merged, 'run-coverage' will not build and run RMM unittests. If ran in isolation, it will generate an empty coverage report by default.
This allows to get coverage analysis for especific tests rather than for all the unittests, which makes the process of writting unittests for new modules easier as we can have a picture of the current coverage for such modules without being tainted by the rest of the unittests.
Please note that in order to run coverage analysis on the whole existing set of unittests (as done previously by 'run-coverage') we need to invoke 'run-unittests' before.
The patch, which is currently open for discussion and review, includes instructions on how to run 'run-coverage' to get different types of analysis.
Thanks,
Javier
[1]: https://review.trustedfirmware.org/c/TF-RMM/tf-rmm/+/23039
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello everyone,
I would like to let you know that there is a first draft of the Threat Model for the TF-RMM ready for review. You can check it out and leave your comments here: https://review.trustedfirmware.org/c/TF-RMM/tf-rmm/+/20477
Best regards,
Javier
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
QEMU 8.1 added support for FEAT_RME. It is experimental, enabled with
'-cpu max,x-rme=on', and requires fixes that will be available in QEMU
8.2. I'm working on adding support to TF-A and TF-RMM.
I just submitted some TF-A patches for review (topic qemu-rme) that enable
the feature for the virt platform, and intend to send the necessary
changes for TF-RMM within a week or so. Without RMM, the Test Realm
Payload is included into the FIP for light testing.
After the TF-A and TF-RMM changes, I'd like to add support for the SBSA
platform as well, which should be a relatively small change once the
common QEMU support is merged.
Thanks,
Jean
---
Building TF-A for QEMU with RME support:
make -j CROSS_COMPILE=aarch64-linux-gnu- PLAT=qemu DEBUG=1
RMM=path/to/rmm/build/Debug/rmm.img ENABLE_RME=1
BL33=path/to/QEMU_EFI.fd QEMU_USE_GIC_DRIVER=QEMU_GICV3
all fip
dd if=tf-a/build/qemu/debug/bl1.bin of=flash.bin bs=4096 conv=notrunc
dd if=tf-a//build/qemu/debug/fip.bin of=flash.bin seek=64 bs=4096 conv=notrunc
Running QEMU, for example:
qemu-system-aarch64 -cpu max,x-rme=on,sme=off -m 3G -smp 8
-M virt,gic-version=3,virtualization=on,secure=on,acpi=off
-bios flash.bin
-kernel linux/arch/arm64/boot/Image
-initrd path/to/initrd
-append console=ttyAMA0
-nographic
...
[ 0.825891] kvm [1]: Using prototype RMM support (version 66.0)
SMC_RMM_FEATURES 0 > RMI_SUCCESS 33403e30