xref: /linux/Documentation/arch/arm64/arm-cca.rst (revision 364eeb79a213fcf9164208b53764223ad522d6b3)
1.. SPDX-License-Identifier: GPL-2.0
2
3=====================================
4Arm Confidential Compute Architecture
5=====================================
6
7Arm systems that support the Realm Management Extension (RME) contain
8hardware to allow a VM guest to be run in a way which protects the code
9and data of the guest from the hypervisor. It extends the older "two
10world" model (Normal and Secure World) into four worlds: Normal, Secure,
11Root and Realm. Linux can then also be run as a guest to a monitor
12running in the Realm world.
13
14The monitor running in the Realm world is known as the Realm Management
15Monitor (RMM) and implements the Realm Management Monitor
16specification[1]. The monitor acts a bit like a hypervisor (e.g. it runs
17in EL2 and manages the stage 2 page tables etc of the guests running in
18Realm world), however much of the control is handled by a hypervisor
19running in the Normal World. The Normal World hypervisor uses the Realm
20Management Interface (RMI) defined by the RMM specification to request
21the RMM to perform operations (e.g. mapping memory or executing a vCPU).
22
23The RMM defines an environment for guests where the address space (IPA)
24is split into two. The lower half is protected - any memory that is
25mapped in this half cannot be seen by the Normal World and the RMM
26restricts what operations the Normal World can perform on this memory
27(e.g. the Normal World cannot replace pages in this region without the
28guest's cooperation). The upper half is shared, the Normal World is free
29to make changes to the pages in this region, and is able to emulate MMIO
30devices in this region too.
31
32A guest running in a Realm may also communicate with the RMM using the
33Realm Services Interface (RSI) to request changes in its environment or
34to perform attestation about its environment. In particular it may
35request that areas of the protected address space are transitioned
36between 'RAM' and 'EMPTY' (in either direction). This allows a Realm
37guest to give up memory to be returned to the Normal World, or to
38request new memory from the Normal World.  Without an explicit request
39from the Realm guest the RMM will otherwise prevent the Normal World
40from making these changes.
41
42Linux as a Realm Guest
43----------------------
44
45To run Linux as a guest within a Realm, the following must be provided
46either 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
67References
68----------
69[1] https://developer.arm.com/documentation/den0137/
70