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-device-attach/1-introduction.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,7 @@ Together, CCA and RME deliver the infrastructure needed to build Confidential Co
18
18
19
19
A Realm is a protected execution environment enabled by RME. It operates independently from both the Normal World where operating systems and user applications run, and the Secure World, which hosts trusted firmware and trusted execution environments (TEEs).
20
20
21
-
Realms allow lower-privileged software, such as an application or a virtual machine, to protect its content and execution from attacks by higher-privileged software, such as an OS or a hypervisor. Realms provide an environment for confidential computing, without requiring the Realm owner to trust the software components that manage the resources that the Realm uses.
21
+
Realms allow lower-privileged software, such as an application or a virtual machine, to protect its content and execution from attacks by higher-privileged software, such as an OS or a hypervisor. Essentially, realms provide an environment for confidential computing without requiring the Realm owner to trust the software components that manage the resources that the Realm uses.
22
22
23
23
While Realms are isolated by design, they still need to interact with external components to be practical - for example, accessing a network interface or communicating with a peripheral device.
This section introduces VirtIO and Bounce Buffers in the context of CCA Realms, and explains how they enable secure data exchange between a Realm and the untrusted external world.
11
+
This section introduces VirtIO in the context of CCA Realms, and explains how it enables secure data exchange between a Realm and the untrusted external world.
12
12
13
13
A Realm must eventually use physical devices to interact with the external world. The easiest way to achieve this is by using VirtIO, which provides a fast, high-level emulation layer. This is considered the first level of device attach, where access is mediated by the hypervisor using paravirtualized interfaces.
14
14
@@ -17,296 +17,36 @@ and **D**ata **E**ncryption), where the host OS assigns a physical device to a R
17
17
18
18
### What is VirtIO?
19
19
20
-
VirtIO provides an efficient, paravirtualized I/O interface between Realms and host devices. It is an abstraction layer for virtual devices in virtualized environments. It provides standardized and efficient interfaces between guest virtual machines (VMs) and host devices, making it easier to develop paravirtualized drivers.
20
+
VirtIO provides an efficient, paravirtualized I/O interface between Realms and host devices. It is an abstraction layer for virtual devices in virtualized environments. VirtIO is a standardized, efficient interface for virtual devices in virtualized environments. It lets guest operating systems use paravirtualized drivers to communicate with host-provided devices, avoiding the overhead of fully emulating physical hardware.
21
21
22
22
Paravirtualized means that the guest OS is aware it’s running in a virtualized environment and can use optimized drivers (VirtIO) to communicate with virtual hardware. Emulating physical hardware devices (like NICs or disks) for VMs is slow and inefficient. VirtIO allows VMs to bypass full device emulation and use streamlined drivers.
23
23
24
-
VirtIO is most commonly used with KVM/QEMU virtualization.
24
+
VirtIO is most commonly used with KVM/QEMU virtualization. Example drivers include:
25
25
26
-
Example drivers include:
27
-
28
-
-`virtio-net`: Paravirtualized networking
29
-
-`virtio-blk`: Block device (disk) access
30
-
-`virtio-fs`: File sharing (host ↔ guest)
31
-
-`virtio-balloon`: Dynamic memory management
32
-
-`virtio-rng`: Random number source
33
-
-`virtio-console`: Simple console interface
26
+
-`virtio-net`: paravirtualized networking
27
+
-`virtio-blk`: block storage
28
+
-`virtio-fs`: file sharing between host and guest
29
+
-`virtio-balloon`: dynamic memory management
30
+
-`virtio-rng`: random number source
31
+
-`virtio-console`: simple console interface
34
32
35
33
### How does VirtIO work in VMs?
36
34
37
-
Here is an overview of how VirtIO works in Virtual Machines:
38
-
39
-
1. The Host Hypervisor (for example, QEMU/KVM) exposes VirtIO backend devices.
40
-
2. The guest OS loads VirtIO _frontend_ drivers (for example, `virtio_net`,
41
-
`virtio_blk`) that communicate using the VirtIO protocol.
42
-
3. Communication happens via shared memory (`virtqueues`) for I/O operations,
43
-
avoiding full device emulation.
44
-
4. Devices are exposed over the PCI or MMIO bus to the guest.
45
-
46
-
For example, instead of emulating an Intel e1000 NIC, the host exposes a `virtio-net` interface, and the guest OS uses the `virtio-net` driver to send and receive packets via shared buffers.
47
-
48
-
## Bounce buffers
49
-
50
-
### What are bounce buffers?
51
-
52
-
Bounce buffers are temporary memory buffers used when Direct Memory Access (DMA) cannot be performed directly on the original data buffer. This might be because:
53
-
54
-
1. The original buffer is not physically contiguous
55
-
2. The buffer is in high memory or not accessible to the device
56
-
3. The buffer does not meet alignment or boundary constraints required by the device
57
-
58
-
## Why use bounce buffers?
59
-
60
-
Data _bounces_ between:
61
-
- The original buffer (in user or kernel space) and
62
-
- The DMA-capable bounce buffer (used for I/O with the device)
63
-
64
-
This ensures that data transfer is possible even when the original memory isn’t suitable for DMA.
65
-
66
-
## CCA Realms, VirtIO and bounce buffers
67
-
68
-
The defining feature of a Realm is that its memory (called *Realm memory*) is cryptographically isolated from both the Normal and Secure Worlds.
69
-
70
-
This means that:
71
-
- Realm memory is encrypted with unique keys
72
-
- Non-Realm entities (host OS, hypervisor) cannot directly read or
73
-
write to Realm memory
74
-
- Even Direct Memory Access (DMA) from peripherals or untrusted drivers cannot
75
-
access Realm data
76
-
77
-
This design ensures confidentiality but presents a challenge: how can a Realm securely interact with untrusted components, such as network stacks in the host OS, storage subsystems, or I/O devices managed by untrusted drivers? To exchange data securely with untrusted components (for example, network stacks, storage subsystems), Realms use *bounce buffers* as intermediaries.
78
-
79
-
### How bounce buffers are used with RME
80
-
81
-
1. Exporting Data:
82
-
- A Realm application prepares some data (for example, the results of computation)
83
-
- It copies this data from protected Realm memory into a bounce buffer.
84
-
- The Realm notifies the untrusted host or hypervisor that the data is ready.
85
-
- The host retrieves the data from the bounce buffer.
86
-
87
-
2. Importing Data:
88
-
- The host places data (for example, input from a file or device) into a bounce buffer.
89
-
- The Realm is notified and validates the source.
90
-
- The Realm copies the data from the bounce buffer into its protected memory.
91
-
92
-
This pattern preserves confidentiality and integrity of Realm data, since:
93
-
- The Realm never allows direct access to its memory.
94
-
- It can validate and sanitize any data received via bounce buffers.
95
-
- No sensitive data is exposed without explicit copying.
96
-
97
-
### Is confidentiality preserved with bounce buffers?
98
-
99
-
In the previous section, it was mentioned that bounce buffers preserve confidentiality. Lets dive a little deeper into that. Bounce buffers are nothing more than an explicitly shared temporary area between the Realm world and the outside world. This does indeed preserve the confidentiality of the rest of the Realm data. On the other hand, for the data being transferred, it is leaving the Realm world and will only remain confidential if it is encrypted in some way, for example, for network traffic, TLS should be used.
100
-
101
-
## Seeing a Realm's bounce buffers at work
102
-
103
-
Let's put this to work and check for ourselves that bounce buffers are used. The steps in this section will build on the Key Broker demo that was used in the [CCA
1. The host hypervisor (for example, QEMU/KVM) exposes VirtIO backend devices
38
+
2. The guest OS loads VirtIO frontend drivers such as `virtio_net`or `virtio_blk` that communicate using the VirtIO protocol
39
+
3. I/O uses shared memory `virtqueues`, which avoids full device emulation
40
+
4. Devices are exposed over the PCI or MMIO bus to the guest
295
41
296
-
In the `keybroker-app`command above, `skywalker` is the key name that is
297
-
requested from the KBS.
42
+
For example, instead of emulating an Intel e1000 NIC, the host exposes a `virtio-net` interface. The guest OS uses the `virtio-net` driver to exchange packets through shared buffers.
298
43
299
-
The output should look like:
44
+
### Key takeaways
300
45
301
-
```output
302
-
INFO Requesting key named 'skywalker' from the keybroker server with URL http://172.17.0.2:8088/keys/v1/key/skywalker
0 commit comments