Skip to content

Commit 972d755

Browse files
Steven Pricectmarinas
authored andcommitted
arm64: Document Arm Confidential Compute
Add some documentation on Arm CCA and the requirements for running Linux as a Realm guest. Also update booting.rst to describe the requirement for RIPAS RAM. Reviewed-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20241017131434.40935-12-steven.price@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
1 parent 7999edc commit 972d755

File tree

3 files changed

+73
-0
lines changed

3 files changed

+73
-0
lines changed

Documentation/arch/arm64/arm-cca.rst

Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
.. SPDX-License-Identifier: GPL-2.0
2+
3+
=====================================
4+
Arm Confidential Compute Architecture
5+
=====================================
6+
7+
Arm systems that support the Realm Management Extension (RME) contain
8+
hardware to allow a VM guest to be run in a way which protects the code
9+
and data of the guest from the hypervisor. It extends the older "two
10+
world" model (Normal and Secure World) into four worlds: Normal, Secure,
11+
Root and Realm. Linux can then also be run as a guest to a monitor
12+
running in the Realm world.
13+
14+
The monitor running in the Realm world is known as the Realm Management
15+
Monitor (RMM) and implements the Realm Management Monitor
16+
specification[1]. The monitor acts a bit like a hypervisor (e.g. it runs
17+
in EL2 and manages the stage 2 page tables etc of the guests running in
18+
Realm world), however much of the control is handled by a hypervisor
19+
running in the Normal World. The Normal World hypervisor uses the Realm
20+
Management Interface (RMI) defined by the RMM specification to request
21+
the RMM to perform operations (e.g. mapping memory or executing a vCPU).
22+
23+
The RMM defines an environment for guests where the address space (IPA)
24+
is split into two. The lower half is protected - any memory that is
25+
mapped in this half cannot be seen by the Normal World and the RMM
26+
restricts what operations the Normal World can perform on this memory
27+
(e.g. the Normal World cannot replace pages in this region without the
28+
guest's cooperation). The upper half is shared, the Normal World is free
29+
to make changes to the pages in this region, and is able to emulate MMIO
30+
devices in this region too.
31+
32+
A guest running in a Realm may also communicate with the RMM using the
33+
Realm Services Interface (RSI) to request changes in its environment or
34+
to perform attestation about its environment. In particular it may
35+
request that areas of the protected address space are transitioned
36+
between 'RAM' and 'EMPTY' (in either direction). This allows a Realm
37+
guest to give up memory to be returned to the Normal World, or to
38+
request new memory from the Normal World. Without an explicit request
39+
from the Realm guest the RMM will otherwise prevent the Normal World
40+
from making these changes.
41+
42+
Linux as a Realm Guest
43+
----------------------
44+
45+
To run Linux as a guest within a Realm, the following must be provided
46+
either by the VMM or by a `boot loader` run in the Realm before Linux:
47+
48+
* All protected RAM described to Linux (by DT or ACPI) must be marked
49+
RIPAS RAM before handing control over to Linux.
50+
51+
* MMIO devices must be either unprotected (e.g. emulated by the Normal
52+
World) or marked RIPAS DEV.
53+
54+
* MMIO devices emulated by the Normal World and used very early in boot
55+
(specifically earlycon) must be specified in the upper half of IPA.
56+
For earlycon this can be done by specifying the address on the
57+
command line, e.g. with an IPA size of 33 bits and the base address
58+
of the emulated UART at 0x1000000: ``earlycon=uart,mmio,0x101000000``
59+
60+
* Linux will use bounce buffers for communicating with unprotected
61+
devices. It will transition some protected memory to RIPAS EMPTY and
62+
expect to be able to access unprotected pages at the same IPA address
63+
but with the highest valid IPA bit set. The expectation is that the
64+
VMM will remove the physical pages from the protected mapping and
65+
provide those pages as unprotected pages.
66+
67+
References
68+
----------
69+
[1] https://developer.arm.com/documentation/den0137/

Documentation/arch/arm64/booting.rst

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -41,6 +41,9 @@ to automatically locate and size all RAM, or it may use knowledge of
4141
the RAM in the machine, or any other method the boot loader designer
4242
sees fit.)
4343

44+
For Arm Confidential Compute Realms this includes ensuring that all
45+
protected RAM has a Realm IPA state (RIPAS) of "RAM".
46+
4447

4548
2. Setup the device tree
4649
-------------------------

Documentation/arch/arm64/index.rst

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,7 @@ ARM64 Architecture
1010
acpi_object_usage
1111
amu
1212
arm-acpi
13+
arm-cca
1314
asymmetric-32bit
1415
booting
1516
cpu-feature-registers

0 commit comments

Comments
 (0)