Support for Arm CCA guest firmware v5#12224
Draft
samimujawar wants to merge 72 commits intotianocore:masterfrom
Draft
Support for Arm CCA guest firmware v5#12224samimujawar wants to merge 72 commits intotianocore:masterfrom
samimujawar wants to merge 72 commits intotianocore:masterfrom
Conversation
samimujawar
force-pushed
the
3945_arm_cca_v5
branch
from
d364205 to
4d8af71
Compare
| IN BOOLEAN Lpa2Enabled | ||
| ) | ||
| { | ||
| UINT64 CcaNsBit = 0; |
Contributor
There was a problem hiding this comment.
NIT: The CI might complain about declaration + initialization
Contributor
Author
There was a problem hiding this comment.
I have not seen the CI complain about this. But, I have tried to resolve most CI issues in the next series.
Contributor
Author
There was a problem hiding this comment.
You are right. The CI is complaining about this. I will get this fixed.
| // Some guests (e.g. kvmtool) do not provide a SMMU, so the PCI node | ||
| // in the DTB lacks an 'iommu-map'. Therefore, return EFI_NOT_FOUND so | ||
| // that the boot can progress. | ||
| return EFI_NOT_FOUND; |
Contributor
There was a problem hiding this comment.
NIT:
This could be considered as a success.
Maybe we could just print a message and return success instead ?
Contributor
Author
There was a problem hiding this comment.
Thanks, I have fixed this now.
| } | ||
|
|
||
| VirtualMemoryTable[Idx].VirtualBase = BaseAddress; | ||
| // Some devices may only use few registers and would report the length |
Contributor
There was a problem hiding this comment.
I think this comment should be moved up with the ALIGN_VALUE() logic
|
|
||
| // Check if we are in a Realm and configure | ||
| // the System Memory as Protected RAM. | ||
| bl ASM_PFX(ArmCcaConfigureSystemMemory) |
Contributor
There was a problem hiding this comment.
NIT: If the returned value is ignored, ArmCcaConfigureSystemMemory() might just return VOID ?
| DebugLib|MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf | ||
| !endif | ||
|
|
||
| [LibraryClasses.AARCH64.SEC, LibraryClasses.AARCH64.PEI_CORE, LibraryClasses.AARCH64.PEIM] |
Contributor
There was a problem hiding this comment.
Isn't the library only used at SEC currently ? Same question for other platforms
| #include <Library/BaseMemoryLib.h> | ||
| #include <Library/DebugLib.h> | ||
|
|
||
| #include <Uefi/UefiMultiPhase.h> |
Contributor
There was a problem hiding this comment.
NIT:
ArmVirtPkg: Refactor ArmCcaLib for safe early boot
The patch name is a bit misleading as this seems to be more an optimization
Contributor
Author
There was a problem hiding this comment.
Updated commit message accordingly.
| # | ||
| ArmVirtPkg/QemuPlatformDxe/QemuPlatformDxe.inf { | ||
| <LibraryClasses> | ||
| NULL|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf |
Contributor
There was a problem hiding this comment.
It seems this doesn't exist anymore
Contributor
Author
There was a problem hiding this comment.
This was also flagged by the CI. This should be fixed now.
|
|
||
| BaseAddress = (UINT64 *)SmcCmd.Arg1; | ||
| Size = EndAddress - BaseAddress; | ||
| } // while |
Contributor
There was a problem hiding this comment.
Should we undo things if we fail in the middle of an address range ?
Contributor
Author
There was a problem hiding this comment.
We cannot recover from such failures. I am not sure if trying to roll back would help. I think the caller must handle the errors and just panic.
| RETURN_STATUS | ||
| EFIAPI | ||
| RsiSetIpaState ( | ||
| IN UINT64 *Address, |
Contributor
There was a problem hiding this comment.
Generic question: all the Rsi functions should operate on protected IPA, so should there be an assert or or check on the protected big of the input address ?
Contributor
Author
There was a problem hiding this comment.
The Address passed here is the VA. The protection bit is set in the page tables for this address.
samimujawar
force-pushed
the
3945_arm_cca_v5
branch
3 times, most recently
from
9315d20 to
170ba57
Compare
|
⚠ WARNING: Cannot add some reviewers: A user specified as a reviewer for this PR is not a collaborator of the repository. Please add them as a collaborator to the repository so they can be requested in the future. Non-collaborators requested: Attn Admins: Admin Instructions:
|
tianocore-assign-reviewers
Bot
requested review from
ChaselChiu,
andreiw,
ardbiesheuvel,
arunsbaskaran,
benjamindoron,
ecuevasf,
gdong1,
gguo11837463,
jameslu8,
jiaxinwu,
jyao1,
kilaterlee,
kraxel,
leiflindholm and
lgao4
samimujawar
force-pushed
the
3945_arm_cca_v5
branch
from
170ba57 to
d908e6e
Compare
tianocore-assign-reviewers
Bot
requested review from
LiuZhiguang001,
Sean-StarLabs,
lzeng14,
mdkinney,
mikebeaton,
niruiyu and
shuoliu0
In a realm, we'll need to patch the early page tables to access the emulated uart through the unprotected IPA range. Add a third level table for the VA range which contains the UART. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
A Realm needs to access emulated devices via the unprotected IPA range (upper IPA bit set). After probing the RMM using some RSI calls, update the page table entry that maps the UART. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Pull in the Arm CCA libraries needed for discovering the address space width and sharing DMA memory with the VMM. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
The ArmCcaInitialiseHobs() in ArmCcaInitPeiLib creates Guid HOBs to cache the IsRealm and IPA Width value. Therefore, invoke ArmCcaInitialiseHobs() from the PlatformPeim() to create the Arm CCA HOBs. Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
…r CCA A Realm guest needs to access peripherals emulated with the host with the 'unprotected' bit set (most significant bit of the Intermediate Physical Address). Initialize the page tables with all device mappings. When launching QEMU with more than 254M of potential RAM, the high PCIe regions are shifted to make space for RAM. Find their location in the device tree. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
To ensure I/O buffers are shared with the host, add those libs Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
…ibutes An 'unprotected' bit set by ArmCcaConfigureMmio() may get cleared later by ArmSetMemoryAttributes(). For example the PCIe ECAM region on QEMU is mapped late by MapGcdMmioSpace(). Ensure the 'unprotected' bit does not get cleared. Note that we should probably consolidate this: ArmCcaConfigureMmio() initializes those page table entries as valid even though they don't have the correct memory attributes yet. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
When running in a realm, we must explicitly share DMA buffers with the host. Use the IoMmuProtocol when available. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Add support for publishing gIoMmuAbsentProtocolGuid on platforms that do not implement Confidential Computing (CC). A previous change enabling CC support for ArmVirtQemu, see patch "QemuFwCfgLibMmio: Use IOMMU for DMA buffers" updated QemuFwCfgLibMmio to rely on the IOMMU protocol for DMA buffer handling. As a result, dependent drivers now require either gEdkiiIoMmuProtocolGuid or gIoMmuAbsentProtocolGuid to be installed for proper dispatch. RiscVVirtQemu and LoongArchVirtQemu firmware also uses QemuFwCfgLibMmio but does not implement support for CC. Without publishing one of the required protocols, dependent drivers are not dispatched. To address this, introduce a DXE driver IoMmuAbsentDxe that installs gIoMmuAbsentProtocolGuid for architectures without CC support. Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
As the ArmVirtQemu platforms are getting support for confidential computing, they needs to start supporting IOMMU protocols that share and unshare DMA buffers with the host. This means we'll need to ensure that the driver that provides the IOMMU protocol and client drivers that perform DMA are loaded in the right order. For instance QemuFwCfgLibMmio needs new Depex entries so that drivers including this library are loaded after either gEdkiiIoMmuProtocolGuid or gIoMmuAbsentProtocolGuid get produced. Since RiscVVirtQemu and LoongArchVirtQemu uses QemuFwCfgLibMmio, it now needs something that produces gIoMmuAbsentProtocolGuid. Include IoMmuAbsentDxe for this purpose. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> --- Only build-tested
The ArmVirtQemu guest firmware loads the kernel and initrd images from the host through the FwCfg device. When running in a realm, measure those images and add them to the realm measurement, so that the realm owner can later authenticate them. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Use the Arm CCA BlobVerifier to add hashes of FwCfg images to the realm measurement. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Arm Confidential Compute Architecture (CCA) is a reference software architecture and implementation that builds on the Realm Management Extension (RME), enabling the execution of Virtual machines (VMs), while preventing access by more privileged software, such as hypervisor. The software stack for Arm CCA consists of the following modules: 1. Trusted Firmware RMM - TF-RMM 2. Trusted Firmware for A class 3. Linux kernel support for Arm CCA 4. kvmtool support for Arm CCA 5. kvmtool guest firmware for Arm CCA. The 'Realm Guest firmware' is an important part of the Arm CCA reference software stack. Therefore, add documentation on the design approach and instructions to build and test the Realm guest firmware. Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
samimujawar
force-pushed
the
3945_arm_cca_v5
branch
from
0942d7b to
4087359
Compare
This was referenced Apr 1, 2026
This was referenced Apr 27, 2026
|
PR can not be merged due to conflict. Please rebase and resubmit |
This was referenced Apr 30, 2026
5259_arm_cca_measured_boot_v1_s2: Add CCEL and Arm CCA related definitions to MdePkg headers.
#12533
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Tracking
Description
This v5 series enables the Arm Confidential Compute Architecture (CCA) support for the Kvmtool guest firmware and is aligned with the ARM CCA RMM 1.0-rel0 specification.
In addition to the Kvmtool guest firmware, the patches for adding Realm support to the ArmVirtQemu firmware from PR tianocore/edk2-staging#518 have been included
RMM 1.0-rel0 specification updated this series has been rebased with the latest edk2 & edk2-platforms codebase and the intention is to integrate the Arm CCA support in ArmVirtPkg and enable the guest firmware support for Realms.
Note the Arm CCA Guest Firmware v4 series PR tianocore/edk2-staging#514 was merged in the edk2-staging/arm-cca branch. Following this a PR for enabling Realms support for ArmVirtQemu was created at PR tianocore/edk2-staging#518.
This v5 series consolidates both these series in a single pull request to be merged in edk2 mainline.
Summary of updates in this v5 Series:
This section outlines the changes done since the v4 series and were merged in the edk2-staging/arm-cca branch.
In addition to these a changes the 'staging branch description/creation patch' from the edk2-staging/arm-cca branch has been dropped and instead a new patch
4d8af71 ArmVirtPkg: Add Readme for Arm CCA guest firmware
to document the Arm CCA guest firmware design, build and test instructions has been added.
NOTE: A detailed summary of the changes done since the v4 series can be seen at tianocore/edk2-staging#518 (comment)
Summary of updates in the previous v4 Series:
Support for Arm CCA guest firmware v3 (RMM-v1.0-rel0) #6480
parameter registers in SMC" has been dropped as it is no
longer required.
the plan is to discuss and address those as part of this pull request.
Summary of updates in the previous v3 Series:
and populate the memory map accordingly.
and if so, skip configuring the shared attribute for the
MMIO region.
a GIVc3-ITS is present.
Summary of updates in the previous v2 Series:
are already merged, hence dropped from this series.
code. Therefore, introduced SetMemoryProtectionAttribute()
to configure the top bit of the Realm IPA space which is
used as the protection bit
dynamic PCD, and introduced ArmVirtMonitorLib, a new
instance of the ArmMonitorLib that reads the conduit to
be used from the FDT.
Call arguments, and to correct the RSI Version mask
to RMM specification v1.0-EAC5.
Arm Confidential Compute Architecture (CCA)
Arm CCA is a reference software architecture and implementation that
builds on the Realm Management Extension (RME), enabling the execution
of Virtual machines (VMs), while preventing access by more privileged
software, such as hypervisor. Arm CCA allows the hypervisor to control
the VM, but removes the right for access to the code, register state or
data used by VM.
More information on the architecture is available here [1].
Where:
RMM - Realm Management Monitor
RMI - Realm Management Interface
RSI - Realm Service Interface
SMC - Secure Monitor Call
RME introduces two added additional worlds, "Realm world" and "Root
World" in addition to the traditional Secure world and Normal world.
The Arm CCA defines a new component, Realm Management Monitor (RMM)
that runs at R-EL2. This is a standard piece of firmware, verified,
installed and loaded by the EL3 firmware (e.g., TF-A), at system boot.
The RMM provides a standard interface Realm Management Interface (RMI)
to the Normal world hypervisor to manage the VMs running in the Realm
world (also called Realms). These are exposed via SMC and are routed
through the EL3 firmware.
The RMM also provides certain services to the Realms via SMC, called
the Realm Service Interface (RSI). These include:
page
The Arm CCA reference software currently aligns with the RMM v1.0-rel0
specification, and the latest version is available here [2].
The Trusted Firmware foundation has an implementation of the RMM -
TF-RMM - available here [4].
Related Modules
Implementation
This version of the Realm Guest UEFI firmware is intended to be
used with the Linux Kernel stack[7] which is also based on the
RMM specification v1.0-rel0[3].
This release includes the following features:
firmware
using the Virtio-1.0 PCIe transport.
Overview of updates for enabling Arm CCA
The Arm CCA implementation is spread across a number of libraries
that provide required functionality during various phases of the
firmware boot.
The following libraries have been provided:
ArmCcaInitPeiLib - A library that implements the hook functions
in the PEI phase
ArmCcaLib - A library that implements common functions like
checking if RME extension is implemented and to configure the
Protection attribute for the memory regions
ArmCcaRsiLib - A library that implements the Realm Service
Interface functions.
A NULL implementation of the ArmCcaInitPeiLib and ArmCcaLib is also
provided for platforms that do not implement the RME extensions.
Additionally, the following DXE modules have been provided to implement
the required functionality in the DXE phase.
RealmApertureManagementProtocolDxe - A DXE that implements the
Realm Aperture Management Protocol, used to manage the sharing
of buffers in a Realm with the Host
ArmCcaIoMmuDxe - A driver which implements the EDKII_IOMMU_PROTOCOL
that provides the necessary hooks so that DMA operations can be
performed by bouncing buffers using pages shared with the Host.
Arm CCA updates in PEI phase
For supporting Arm CCA An early hook to configure the System Memory
as Protected RAM has been added in the PrePi module.
This hook function is implemented in ArmCcaInitPeiLib. A NULL
version of the library has also been provided for implementations
that do not have the RME extensions.
The ArmVirtGetMemoryMap() implementation for the Guest firmware
has been updated to check if the device MMIO region is protected
MMIO, i.e. if it is a Realm emulated device or a Host emulated
device.
If the device is Host emulated, the Arm CCA Protection attribute bit
is set to shared, i.e. PhysicalBase = BaseAddress | (1 << (IpaWidth - 1))
Building the UEFI firmware
Set up the development environment
Follow the steps as described in
https://github.com/tianocore/edk2-platforms/blob/master/Platform/ARM/Readme.md
The source code for the Host and Realm Guest firmware can
be found at [10].
Building the Host UEFI firmware for FVP Base RevC AEM Model
Follow the instructions in
https://github.com/tianocore/edk2-platforms/blob/master/Platform/ARM/Readme.md
to "Build the firmware for Arm FVP Base AEMv8A-AEMv8A model
platform" based on your development environment configuration.
To build the kvmtool guest firmware, run the following commands:
The Kvmtool guest firmware binaries are at the following location:
Running the stack
To run/test the stack, you would need the following components:
Instructions for building the remaining firmware components and
running the model are available here [9]. Once, the host kernel
has finished booting, a Realm can be launched by invoking the
lkvmcommand as follows:Where:
creating the initial measurements by the RMM for this Realm (defaults to sha256)
supported.
Links
[1] Arm CCA Landing page (See Key Resources section for various documentations)
[2] RMM Specification Latest
[3] RMM v1.0-rel0 specification
[4] Trusted Firmware RMM - TF-RMM
[5] FVP Base RevC AEM Model
(available on x86_64 / Arm64 Linux)
[6] Trusted Firmware for A class
[7] Linux kernel support for Arm CCA
[8] kvmtool support for Arm CCA
[9] Instructions for Building Firmware components and running the model, see section 4.19.2 "Building and running TF-A with RME"
[10] UEFI Firmware support for Arm CCA
NO
NO
See ‘Running the stack’ section above.
How This Was Tested
See ‘Running the stack’ section above.
Integration Instructions
N/A