- tf-rmm - lists.trustedfirmware.org

Firmware-A v2.12 release follow up - shrinkwrap

by Olivier Deprez

Hi, As a follow up to the Firmware-A v2.12 release [1], we are pleased to share the shrinkwrap tool [2] configurations have been updated to consume latest firmware/upstream ingredients using following tags: TF-A: v2.12.0 TF-a-tests: v2.12.0 Hafnium: v2.12.0 TF-RMM: tf-rmm-v0.6.0 CCA EDK2: 3223_arm_cca_rmm_v1.0_rel0_v3 linux: cca-full/v5+v7 kvmtool: cca/v3 An additional merge request is in queue for kvm-unit-tests update to cca/rmm-v1.0-rel0 tag. Shrinkwrap is a convenient tool for building a fully integrated Arm CCA SW stack running on the Base AEM FVP platform. In particular this is the tool of choice for RMM development to reproduce a 3 or 4 worlds RME based environment. Regards, Olivier. [1] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… [2] https://shrinkwrap.docs.arm.com/en/latest/

2 weeks, 3 days

1
0
0 0

Addition of mbedTLS as a submodule dependency to TF-A-Tests

by Soby Mathew

Hi Everyone, In order to facilitate development for Device Assignment tests for RME-DA, we have added MbedTLS repo as a submodule dependency to tf-a-tests. The merge commit can be found here : https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/3e72cd… The patch is done in such a way that existing build of TF-A-Tests or Test run is not affected due to the additional dependency. Only tests which depend on MbedTLS will be affected in that they will either be skipped or fail at runtime due to the missing dependency. Also, the change allows to use the config `MBEDTLS_DIR` to point to a MbedTLS directory outside the tf-a-tests source tree. This aligns with the TF-A mechanism for MbedTLS dependancy in case the submodule mechanism is not preferred. We expect existing CI and testing infrastructure to be unaffected by this change. Please let us know if you have any comments. Best Regards Soby Mathew

3 weeks, 1 day

1
0
0 0

Submodule update during build phase of the project

by Soby Mathew

Hi Everyone We are planning to change how TF-RMM clones and updates the submodule dependencies. The usual practice is to specify the `recursive` option to git clone of the project. This works well when the submodules themselves do not have dependencies. For some dependent repositories like libspdm, there are further dependencies like openssl, cmocka which are not used in the RMM context. Hence specifying the specifying the `recursive` option is not the ideal solution especially when RMM is deployed in Continuous integration solutions. The above issue was worked around in RMM by fetching libspdm within the build context but this was also not ideal as it kept the libspdm outside the git submodules framework and the git fetch was done every time the project was rebuilt. To solve this, we are proposing to move the management of the submodules into the build system and away from the user. Specifically, during configuration phase of the project, cmake will issue `git submodule update --init --depth 1`. This means that the user will not be responsible for syncing the submodules anymore and the build system will take of this. This also ties in with the patching method of the build system as a particular SHA can be ensured before the patch is applied. The patch can be found here : https://review.trustedfirmware.org/c/TF-RMM/tf-rmm/+/33512 Any rebase of the project which updates the submodules will now be transparently applied without the user having to update the submodules manually. We think that we will have more dependent submodules for TF-RMM in the future and it is better to script this within the build system. This change should not break any of the existing CI systems as it is backward compatible, but it may become a little inefficient if the `recursive` option is specified as there will be unnecessary git repositories fetched. Please let us know if any comments. Best Regards Soby Mathew

3 weeks, 1 day

1
1
0 0

problem about tf-rmm latest version

by 王海旺

hello tf-rmm group, Recently I'm learning ARM CCA.But I have trouble running the latest version TF-RMM.It failed at runtime/ core/ init.c/ in func rmm_arch_init.When try to do write_hcrx_el2 action it paniced.So it looks like the FVP doesn't have the hcrx_el2 register.I'm using the FVP_Base_RevC-2xAEMvA_11.27_19. It's the latest version in the arm's offical website.The tf-rmm-v0.5.0 works fine.So I'm wondering how do you test latest version TF-RMM.It would be appreciated if you could reply. Best, Wang.

3 weeks, 5 days

2
1
0 0

Trusted Firmware v2.12 release announcement

by Olivier Deprez

Hi All, We are pleased to announce the formal release of Trusted Firmware-A version 2.12 bundle of project deliverables. This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, RMM, Trusted Services, and TF-A OpenCI scripts/jobs components. These went live on Nov, 21st 2024. Please find references to tags and change logs at the end of this email. Many thanks to the trustedfirmware.org community for the active engagement in delivering this release! Notable features of the release version 2.12 are as follows: TF-A/EL3 * New CPUs support: Cortex-A320 (Arcadia), Cortex-A720AE. * Arch extensions: : FEAT_THE, FEAT_LS64_ACCDATA, FEAT_Debugv8p9, FEAT_SCTLR2, FEAT_FGT2 ; Arm 9.4 : FEAT_D128 support. * Context management: Asymmetric CPU features, EL3 execution context, SVE S/R support. * RME: GPT contiguous descriptor (or GPT large mappings support). * Arm CCA: added attestation generic library, el3 attestation token signing support. Boot flow * Tools: * Introduced the Transfer List Compiler (TLC) Host Tool supporting the FW hand-off specification. * Introduced CoT Device Tree to C File (DT2C) tool. * mbedTLS Improvements: * Resolved random authentication failures with ECDSA. * Enhanced mbedTLS configuration selection. * Maximize usage of mbedTLS library APIs in TF-A. * Upgraded to mbedTLS v3.6.1. * Feature addition/support: * Support for the ECDSA P-384 curve with the PSA Crypto implementation. * Documentation: * Added the DPE Design and Threat Model document to TF-A readthedocs. Errata (CPU/GIC) * Cortex-A720, Cortex-A520, Cortex-X4 errata. TF-A platforms support * New platforms added: TC4, RD-1 AE, RK3566/RK3568. * Platform fixes: FPGA, FVP, Neoverse-RD, TC, Corstone-1000, Allwinner, AST2700, Poplar, Agilex, A3K, MT8188, iMX8M, S32G274A, qemu, Rpi3, Rockchip, STM32MP1, STM32MP2, Versal, ZynqMP. Hafnium/SPM (S-EL2) * FF-A features additions * FF-A v1.2 FFA_MSG_WAIT RX buffer ownership flag. * FF-A v1.2 FFA_VERSION endpoint restriction. * FF-A v1.1 VM availability messages. * Architectural support * vCPU IPI signaling. * Arch timer virtualization. * RME: GPF support and memcpy hardening. * Secure Interrupt Handling for UP S-EL1 partitions. TF-RMM (R-EL2) * REL0 RMM 1.0 support. * Support for alternative attestation token signing via EL3. * Various improvements and bugfixes as listed in the change log. TF-A Tests * Arm arch. extensions: AMU, FEAT_FGT2, LS64_ACCDATA, FEAT_Debugv8p9, LS64 64-byte load/store. * Asymmetric feature testing (FEAT_SPE, FEAT_TRBE, FEAT_TCR2). * EL1 and EL2 context switch tests. * FF-A: v1.2 support, S-EL2 arch timer virtualization, S-EL2+RME hardening, EL3 SPMC TFTF test suite, EL3 SVE test coverage. * RME: RMM v1.0 testing support, PCIe DOE support, RMI support for FEAT_LPA2, SIMD, PAuth. * Platforms: AMD Versal Gen 2 added, Neoverse-RD refactoring, FVP PCIe support. Release tags across repositories: https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/r… https://git.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/refs/tags… https://git.trustedfirmware.org/plugins/gitiles/ci/tf-a-ci-scripts/+/refs/t… https://git.trustedfirmware.org/plugins/gitiles/ci/tf-a-job-configs/+/refs/… https://git.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/refs/tags… https://git.trustedfirmware.org/plugins/gitiles/ci/hafnium-ci-scripts/+/ref… https://git.trustedfirmware.org/plugins/gitiles/ci/hafnium-job-configs/+/re… https://git.trustedfirmware.org/plugins/gitiles/TF-RMM/tf-rmm/+/refs/tags/t… https://git.trustedfirmware.org/plugins/gitiles/TS/trusted-services/+/refs/… Change logs: https://trustedfirmware-a.readthedocs.io/en/v2.12.0/change-log.html#id1 https://trustedfirmware-a-tests.readthedocs.io/en/latest/change-log.html#ve… https://hafnium.readthedocs.io/en/v2.12.0/change-log.html#v2-12 https://tf-rmm.readthedocs.io/en/latest/about/change-log.html#v0-6-0 Regards, Olivier.

1 month

1
0
0 0

Firmware-A v2.12 release rc0 tag

by Govindraj Raja

Hi All, In preparation to the Firmware-A v2.12 bundle release the following TF-A/TF-A-tests/Hafnium/RMM/CI project tags were applied: https://git.trustedfirmware.org/TF-A/trusted-firmware-a/+/refs/tags/v2.12-r… https://git.trustedfirmware.org/tf-a-tests/+/refs/tags/v2.12-rc0 https://git.trustedfirmware.org/ci/tf-a-ci-scripts/+/refs/tags/v2.12-rc0 https://git.trustedfirmware.org/ci/tf-a-job-configs/+/refs/tags/v2.12-rc0 https://git.trustedfirmware.org/hafnium/hafnium.git/+/refs/tags/v2.12-rc0 https://git.trustedfirmware.org/ci/hafnium-ci-scripts.git/+/refs/tags/v2.12… https://git.trustedfirmware.org/ci/hafnium-job-configs.git/+/refs/tags/v2.1… https://git.trustedfirmware.org/TF-RMM/tf-rmm/+/refs/tags/tf-rmm-v0.6.0-rc0 Trees are frozen still accepting security or bug fixes until the release close down happening end next week (hopefully!). For partners, it will help if tests are run against those trees on downstream platforms and spot any issue hit before the final tagging. -- Thanks, Govindraj R ________________________________ From: Govindraj Raja via TF-A-Tests <tf-a-tests(a)lists.trustedfirmware.org> Sent: Monday, October 14, 2024 20:18 To: Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org>; tf-a-tests(a)lists.trustedfirmware.org <tf-a-tests(a)lists.trustedfirmware.org> Cc: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; tf-rmm(a)lists.trustedfirmware.org <tf-rmm(a)lists.trustedfirmware.org>; trusted-services(a)lists.trustedfirmware.org <trusted-services(a)lists.trustedfirmware.org> Subject: [Tf-a-tests] Firmware-A v2.12 release code freeze notification Hi All, The next release of the Firmware-A bundle of projects tagged v2.12 has an expected code freeze date of Nov, 8th 2024. Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…). Closing out the release takes around 6-10 working days after the code freeze. v2.12 release preparation tasks start from now. 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 labels 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, Govindraj R -- TF-A-Tests mailing list -- tf-a-tests(a)lists.trustedfirmware.org To unsubscribe send an email to tf-a-tests-leave(a)lists.trustedfirmware.org

1 month, 1 week

1
0
0 0

Re: TF-A Tech Forum regular call

by Olivier Deprez

+ other MLs ________________________________ From: Olivier Deprez Sent: 30 October 2024 11:41 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: TF-A Tech Forum regular call Dear TF-A ML members, As mentioned in https://www.trustedfirmware.org/meetings/tf-a-technical-forum/, trustedfirmware.org hosts regular technical calls on Thursdays. It mentions TF-A although in practise a number of Cortex-A projects beyond TF-A were discussed (refer to prior recordings on this page). Unfortunately this slot hasn't been very active recently. By this email I'm kindly emphasizing this forum is open to the community (and beyond trustedfirmware.org members) and you are welcome to propose topics. Presentations/slides are not strictly necessary, and we can also host informal discussions or session of questions. If you think of a topic, please reach to me and I'll be happy to accommodate. Thanks for your contributions in advance! Regards, Olivier.

1 month, 3 weeks

1
0
0 0

Firmware-A v2.12 release code freeze notification

by Govindraj Raja

Hi All, The next release of the Firmware-A bundle of projects tagged v2.12 has an expected code freeze date of Nov, 8th 2024. Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…). Closing out the release takes around 6-10 working days after the code freeze. v2.12 release preparation tasks start from now. 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 labels 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, Govindraj R

2 months, 1 week

1
0
0 0

RMM 1.0 REL alignment

by Soby Mathew

Hi Everyone, RMM specification 1.0-rel0 has been released and the PDF spec and an HTML diff relative to 1.0-eac5 are available on Arm Developer: https://developer.arm.com/documentation/den0137/1-0rel0/ As a heads up, TF-RMM is aiming to align to this version of the specification in the next weeks. There are incompatibilities in some ABIs for REL0 compared to EAC5 specification. The work in progress RMM patches can be found here : https://review.trustedfirmware.org/q/project:TF-RMM/tf-rmm+branch:topics/rm… and corresponding TFTF patches are here : https://review.trustedfirmware.org/q/project:TF-A/tf-a-tests+branch:topics/… . Suitable kernel branches will be published on this mailing list as they become available. Best Regards Soby Mathew

2 months, 2 weeks

1
2
0 0

Re: Does the confidential virtual machine support hot-plug for CPU, memory, and devices？

by Jean-Philippe Brucker

Hi, Please have a look at virtio-mem which provides memory hotplug for VMs. It is available in Linux, QEMU, cloud-hypervisor and libvirt: https://libvirt.org/kbase/memorydevices.html#virtio-mem-model Another reason to use virtio-mem rather than ACPI memory hotplug is to keep complexity out of ACPI tables, in order to simplify remote attestation which requires measuring or verifying the firmware tables. For example running QEMU with the following allows to hotplug 4G of memory to the VM: -m 512M,maxmem=1T -object memory-backend-ram,id=mem0,size=4G -device virtio-mem-pci,id=vm0,memdev=mem0,node=0 Then at runtime QEMU monitor can plug and unplug memory: (qemu) qom-get vm0 size (qemu) qom-set vm0 requested-size 1G (qemu) qom-set vm0 requested-size 0 This works for a Realm VM, with a small change to the Linux guest: https://jpbrucker.net/git/linux/commit/?h=cca/v4-hotplug&id=6b8768385fa464a… (I'm not sure it's correct yet but may be worth adding to the initial guest support.) The host adds memory to the guest with RMI_GRANULE_DELEGATE+RMI_DATA_CREATE_UNKNOWN, and removes it with RMI_DATA_DESTROY+RMI_GRANULE_UNDELEGATE which ensures that the pages are wiped before being returned to the host. Virtual device hotplug works out of the box for a Realm VM. The VM needs to have root ports allowing hotplug (see https://www.libvirt.org/pci-hotplug.html#aarch64-architecture ), and the guest kernel must have PCIe hotplug enabled. For example this adds a root port in QEMU: -device pcie-root-port,chassis=1,id=pcie.1,bus=pcie.0 Then in the monitor add a virtio-net device: (qemu) netdev_add user,id=net1 (qemu) device_add virtio-net-pci,netdev=net1,bus=pcie.1,id=hp0 [ 300.003234] pcieport 0000:00:03.0: pciehp: Slot(0): Button press: will power on in 5 sec ... [ 300.798772] virtio-pci 0000:01:00.0: enabling device (0000 -> 0002) # lspci 01:00.0 Ethernet controller: Red Hat, Inc. Virtio 1.0 network device (rev 01) And remove it: (qemu) device_del hp0 The security model of hotplug is equivalent to regular PCI support in a Realm: the guest should only interact with devices whose driver has been hardened against untrusted hosts, and with devices authenticated via CMA-SPDM. Thanks, Jean

4 months, 4 weeks

1
0
0 0

2024

2023

2022

tf-rmm