You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/cca-container/_index.md
+12-5Lines changed: 12 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,19 +10,22 @@ learning_objectives:
10
10
- Create a virtual machine in a Realm running guest Linux using a pre-built docker container.
11
11
- Run a simple application in a Realm running guest Linux.
12
12
- Obtain a CCA attestation token from the virtual guest in a Realm.
13
+
- Run the CCA software stack using MEC (Memory Encryption Contexts)
13
14
14
15
prerequisites:
15
-
- An AArch64 or x86_64 computer running Linux. You can use cloud instances, refer to the list of [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/).
16
+
- An AArch64 or x86_64 computer running Linux or MacOS. You can use cloud instances, refer to the list of [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/).
16
17
17
-
author: Pareena Verma
18
+
author:
19
+
- Pareena Verma
20
+
- Arnaud de Grandmaison
18
21
19
22
### Tags
20
23
skilllevels: Introductory
21
24
subjects: Performance and Architecture
22
25
armips:
23
-
- Neoverse
26
+
- Neoverse
24
27
operatingsystems:
25
-
- Linux
28
+
- Linux
26
29
tools_software_languages:
27
30
- GCC
28
31
- FVP
@@ -31,8 +34,12 @@ tools_software_languages:
31
34
- Docker
32
35
- Runbook
33
36
34
-
37
+
35
38
further_reading:
39
+
- resource:
40
+
title: Learn the architecture - Introducing Arm Confidential Compute Architecture
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/cca-container/cca-container.md
+94-76Lines changed: 94 additions & 76 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,16 +9,16 @@ layout: "learningpathall"
9
9
---
10
10
## Download the docker image
11
11
12
-
Start by downloading the docker container image.
12
+
Start by downloading the docker container image.
13
13
14
-
This docker image contains the pre-built binaries for the Arm CCA reference software stack and the Armv-A Base Architecture Envelope Model (AEM) FVP with support for RME extensions.
14
+
This docker image contains the pre-built binaries for the Arm CCA reference software stack and the Armv-A Base Architecture Envelope Model (AEM) FVP with support for RME extensions.
15
15
16
16
Install [docker engine](/install-guides/docker/docker-engine) on your machine.
docker run -it armswdev/aemfvp-cca-v2-image /bin/bash
41
+
docker run --rm -it armswdev/cca-learning-path:cca-simulation-v3
39
42
```
40
-
You are now inside the `/tmp/cca-stack` directory of the running `armswdev/aemfvp-cca-v2-image` container.
43
+
You are now inside the home directory (`/home/cca`) of user `cca` in the running `armswdev/cca-learning-path:cca-simulation-v3` container.
41
44
42
45
```output
43
-
ubuntu@84eb170a69b9:/tmp/cca-stack$
46
+
cca@a9866f863546:~$
44
47
```
45
48
46
49
## Run the software stack
47
50
48
-
The pre-built binaries for the Arm CCA reference software stack are present in the `output/aemfvp-a-rme` directory.
51
+
The pre-built binaries for the Arm CCA reference software stack are present in the `cca-3world/` directory.
49
52
50
53
```console
51
-
ls output/aemfvp-a-rme/
54
+
ls cca-3world/
52
55
```
53
-
This includes the Trusted Firmware binaries, the host root filesystem and the host Linux kernel image:
56
+
This includes the Realm Management Monitor (`rmm.img`), the host root filesystem (`host-rootfs.ext2`) and the host Linux kernel image (`Image`) and the trusted firmware binaries:
These binaries can run on an Armv-A Base Architecture Envelope Model (AEM) FVP with support for RME extensions. AEM FVPs are fixed configuration virtual platforms of Armv8-A and Armv9-A architectures with comprehensive system IP. The FVP is also contained within this docker container.
@@ -68,71 +71,75 @@ Launch the `run-cca-fvp.sh` script to run the Arm CCA pre-built binaries on the
68
71
A number of `Info` and `Warning` messages will be emitted by the FVP. These can safely be ignored.
69
72
{{% /notice %}}
70
73
71
-
The `run-cca-fvp.sh` script uses the `screen` command to connect to the different UARTs in the FVP.
74
+
The `run-cca-fvp.sh` script uses the `screen` command to connect to the different UARTs in the FVP.
72
75
73
76
You should see the host Linux kernel boot on your terminal:
74
77
75
78
```output
76
-
udhcpc: started, v1.31.1
77
-
udhcpc: sending discover
78
-
udhcpc: sending select for 172.20.51.1
79
-
udhcpc: lease of 172.20.51.1 obtained, lease time 86400
79
+
udhcpc: started, v1.36.1
80
+
udhcpc: broadcasting discover
81
+
udhcpc: broadcasting select for 172.20.51.1, server 172.20.51.254
82
+
udhcpc: lease of 172.20.51.1 obtained from 172.20.51.254, lease time 86400
You will be prompted to log in to buildroot. Enter `root` as both the username and password.
95
+
You will be prompted to log in to the CCA host. Enter `root` as the username (no password is required).
90
96
91
-
You have successfully booted four worlds (Root, Secure, Non-secure and Realm) on the FVP at this point:
97
+
You have successfully booted 3 worlds (Root, Non-secure and Realm) on the FVP at this point:
92
98
93
99
* Trusted Firmware-A is running in Root.
94
100
* Realm Management Monitor (RMM) in Realm.
95
101
* Host Linux in Non-secure.
96
-
* Hafnium in Secure.
97
102
98
103
## Create a virtual guest in a Realm
99
104
100
-
Guest VMs can be launched in a Realm using `kvmtool` from your host Linux prompt. The kernel `Image` and filesystem `realm-fs.ext4` for the Realm are packaged into the buildroot host file system.
105
+
Guest VMs can be launched in a Realm using `kvmtool` from your host Linux prompt. The realm disk image `guest-disk.img` is included into the host file system.
You should see the guest Linux kernel starting to boot in a Realm. This step can take several minutes.
108
115
109
-
After boot up, you will be prompted to log in at the guest Linux buildroot prompt. Use `root`again as both the username and password.
116
+
After boot up, you will be prompted to log in at the guest Linux prompt, use the `root` username (no password required):
110
117
111
118
```output
112
-
Starting network: udhcpc: started, v1.31.1
113
-
udhcpc: sending discover
114
-
udhcpc: sending select for 192.168.33.15
115
-
udhcpc: lease of 192.168.33.15 obtained, lease time 14400
119
+
udhcpc: started, v1.36.1
120
+
udhcpc: broadcasting discover
121
+
udhcpc: broadcasting select for 192.168.33.15, server 192.168.33.1
122
+
udhcpc: lease of 192.168.33.15 obtained from 192.168.33.1, lease time 14400
116
123
deleting routers
117
124
adding dns 172.20.51.254
118
-
OK
119
-
Starting dropbear sshd: OK
125
+
FAIL
126
+
Starting chrony: OK
127
+
Starting crond: OK
128
+
Setting up macvtap... OK
120
129
121
-
Welcome to Buildroot
122
-
buildroot login:
130
+
Welcome to the CCA realm
131
+
realm login:
123
132
```
133
+
124
134
You have successfully created a virtual guest in a Realm using the Arm CCA reference software stack.
125
135
126
136
## Obtain a CCA attestation token from the virtual guest in a Realm
127
137
128
-
Attestation tokens are small reports that are produced by a device upon request. Those tokens are composed of key/value pairs called claims. A CCA attestation token is a collection of claims about the state of a Realm and the CCA platform on which the Realm is running.
138
+
Attestation tokens are small reports that are produced by a device upon request. Those tokens are composed of key/value pairs called claims. A CCA attestation token is a collection of claims about the state of a Realm and the CCA platform on which the Realm is running.
129
139
130
140
Refer to [section A7.2 of the Realm Management Monitor Specification](https://developer.arm.com/documentation/den0137/latest/) to learn about the details of the CCA attestation token.
131
141
132
-
To retrieve a CCA attestation token from the running guest, mount the `configfs` filesystem:
133
-
```console
134
-
mount -t configfs none /sys/kernel/config
135
-
```
142
+
The retrieval of a CCA attestation token from a running guest is done by reading from `/sys/kernel/config/tsm/report/`. This is available when linux's `configfs` has been mounted, which has been done automatically as part of the guest boot process --- if you are curious, this is the `configfs /sys/kernel/config configfs defaults 0 0` line in `/etc/fstab`.
136
143
137
144
You can now generate an attestation token by running the following commands:
138
145
@@ -145,62 +152,73 @@ hexdump -C $report/outblob
145
152
146
153
The output should look like:
147
154
```output
148
-
00000340 00 00 00 00 19 ac cd 58 61 04 76 f9 88 09 1b e5 |.......Xa.v.....|
149
-
00000350 85 ed 41 80 1a ec fa b8 58 54 8c 63 05 7e 16 b0 |..A.....XT.c.~..|
The output is a CCA attestation token from the guest in the Realm. The CCA attestation token is a Concise Binary Object Representation (CBOR) map, in which the map values are the Realm token and the CCA platform token.
177
190
178
-
You have successfully generated a CCA attestation token from the guest. In later learning paths, you will learn how to use these tokens as part of the Arm CCA attestation flow.
191
+
You have successfully generated a CCA attestation token from the guest. In later learning paths, you will learn how to use these tokens as part of the Arm CCA attestation flow.
179
192
180
193
You can now shutdown the guest. Use the `poweroff` command.
181
194
182
195
You should see the following output from the guest:
183
196
184
197
```output
185
-
Stopping dropbear sshd: OK
186
-
Stopping network: OK
187
-
Saving random seed: OK
198
+
(realm) # Destroying macvtap... OK
199
+
Stopping crond: stopped /usr/sbin/crond (pid 120) OK
200
+
Stopping chrony: OK
201
+
Stopping network: ifdown: interface lo not configured OK
188
202
Stopping klogd: OK
189
-
Stopping syslogd: OK
203
+
Stopping syslogd: stopped /sbin/syslogd (pid 66) OK
The guest has shut down and you are back at the host Linux kernel prompt.
201
215
202
-
To exit the simulation, use `Ctrl-a + d`. You will be placed back into the running docker container.
216
+
To exit the host session and the simulation, use `poweroff`. You will be placed back into the running docker container.
203
217
204
218
To exit the docker container, run `exit`.
205
219
206
220
In the next section, you will learn how to run a simple application inside the Realm.
221
+
222
+
{{% notice Note %}}
223
+
The docker session has been started with the `--rm` option, which means the container will be destroyed when it is exited, allowing you to experiment with the images without fear: at the next session, you will get working pristine images ! If you intend your changes to persist across docker sessions, omit the `--rm` option to docker.
0 commit comments