- tf-rmm - lists.trustedfirmware.org

Re: TF-A Tech Forum - Jan 23rd 2025 - RMM design of EL0 applications support

by Olivier Deprez

+TF-RMM ML ________________________________ From: Google Calendar <calendar-notification(a)google.com> on behalf of Olivier Deprez <olivier.deprez(a)arm.com> Sent: 17 January 2025 08:46 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; Olivier Deprez <Olivier.Deprez(a)arm.com> Subject: TF-A Tech Forum - Jan 23rd 2025 - RMM design of EL0 applications support Hi, On Jan 23rd 2025, in the TF-A Tech forum, Mate Toth-Pal and Soby Mathew will present the RMM design of EL0 applications support. The TF-A Tech forum is a regular open forum for anyone from the open source community to participate. Feel free to reach if you have a topic you'd want to present. It can be a design review with slides, walking through RFC patches, or more generic discussion around open source projects. Regards, Olivier. TF-A Tech Forum Thursday Jan 23, 2025 ⋅ 5pm – 6pm (Central European Time - Paris) 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://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvd…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmy%2Ftruste…> 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…> Guests tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> 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.

10 months, 3 weeks

1
0
0 0

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/

1 year

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

1 year

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

1 year

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.

1 year

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 year

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 year, 1 month

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

1 year, 2 months

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

1 year, 4 months

1
0
0 0

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

by wuweinan＠huawei.com

Cloud vendors hope that cloud servers have hot-plug capabilities for CPU, memory, and devices. In confidential virtual machine scenarios, the measurement values will change after hot-plug , and rmi_data_create needs to be called to dynamically update the device tree information. Please consult CCA's plan for the hot-plug capability , and under the security model of confidential virtual machines, should the hot-plug capability of confidential virtual machines be supported?

1 year, 4 months

3
5
0 0

2025

2024

2023

2022

tf-rmm