Updates

Author: madeline-underwood

content/learning-paths/servers-and-cloud-computing/cca-device-attach/1-introduction.md

@@ -20,6 +20,7 @@ A **Realm** is a protected execution environment enabled by RME.  It operates in
 
 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.
 
-To be useful, a Realm has to interact with the rest of the world at some point.
-For example, a network interface is likely to be needed. This Learning Path will
-show you how devices are attached and used by Realms.
+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 Learning Path explains how devices can be securely attached to and used by Realms without compromising their isolation guarantees.
+

content/learning-paths/servers-and-cloud-computing/cca-device-attach/2-virtio.md

@@ -6,35 +6,35 @@ weight: 3
 layout: learningpathall
 ---
 
-This section provides a high level overview of VirtIO and Bounce Buffers, and how they
-relate to CCA Realms.
+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.
 
-A Realm has to use physical devices at some point to interact with the external
-and or physical world. The easiest way to do this is by using VirtIO, which
-provides a fast high level emulation layer. This can be viewed as the first level of
+A Realm must use physical devices at some point to interact with the external
+and or physical world. The easiest way to achieve this is by using VirtIO, which
+provides a fast, high-level emulation layer. This can be viewed as the first level of
 device attach.
 
-More evolved device attach features can be
+More advanced device attach features can be
 performed leveraging hardware security features like PCIe-TDISP (**T**EE
 **D**evice **I**nterface **S**ecurity **P**rotocol) and PCIe-IDE (**I**ntegrity
-and **D**ata **E**ncryption), where the host OS can assign a physical device to
-a realm, which will be able to make security measurements on the physical device
-and include it in its base and measurements.
+and **D**ata **E**ncryption), where the host OS assigns a physical device to
+a Realm. The Realm can then make security measurements on the physical device and include those in its attestation base.
 
 ## VirtIO
 
+Learn how VirtIO provides an efficient, paravirtualized I/O interface between Realms and host devices.
+
 ### What is VirtIO ?
 
 VirtIO 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.
+
 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 hardware devices (like NICs or disks) for VMs is slow and
-inefficient. VirtIO provides a standardized and efficient interface that allows
-VMs to bypass full device emulation and instead use optimized drivers.
+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.
 
-VirtIO is most commonly used with KVM/QEMU virtualization. Example drivers are:
+VirtIO is most commonly used with KVM/QEMU virtualization. Example drivers include:
 - `virtio-net`: Paravirtualized networking
 - `virtio-blk`: Block device (disk) access
 - `virtio-fs`: File sharing (host ↔ guest)
@@ -47,59 +47,57 @@ VirtIO is most commonly used with KVM/QEMU virtualization. Example drivers are:
 
 Here is an overview of how VirtIO works in Virtual Machines:
 
-1. The Host Hypervisor (e.g., QEMU/KVM) exposes VirtIO “backend” devices.
-2. The guest OS loads VirtIO _frontend_ drivers (e.g., `virtio_net`,
+1. The Host Hypervisor (for example, QEMU/KVM) exposes VirtIO backend devices.
+2. The guest OS loads VirtIO _frontend_ drivers (for example, `virtio_net`,
    `virtio_blk`) that communicate using the VirtIO protocol.
 3. Communication happens via shared memory (`virtqueues`) for I/O operations,
    avoiding full device emulation.
 4. Devices are exposed over the PCI or MMIO bus to the guest.
 
-For example, instead of emulating an Intel e1000 NIC, the host exposes a
-`virtio-net` interface to the guest OS and the guest OS uses the `virtio-net`
-driver to send/receive packets via shared buffers.
+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.
 
 ## Bounce buffers
 
 ### What are bounce buffers?
 
-Bounce buffers are temporary memory buffers used in the Linux kernel to handle situations where direct memory access (DMA) can’t be performed directly on the original data buffer. This often happens because:
-1. The original buffer is not physically contiguous.
-2. The buffer is in high memory or not accessible to the device.
-3. The buffer doesn’t meet alignment or boundary requirements of the device.
+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:
 
-### Why bounce buffers?
+1. The original buffer is not physically contiguous
+2. The buffer is in high memory or not accessible to the device
+3. The buffer does not meet alignment or boundary constraints required by the device
+
+## Why use bounce buffers?
 
 Data _bounces_ between:
-- The original buffer (in user/kernel space) and
+- The original buffer (in user or kernel space) and
 - The DMA-capable bounce buffer (used for I/O with the device)
 
-This ensures that data transfers can still happen even when the original memory
-is not suitable or accessible for transfers.
+This ensures that data transfer is possible even when the original memory isn’t suitable for DMA.
 
 ## CCA Realms, VirtIO and bounce buffers
 
 The defining feature of a Realm is that its memory (called *Realm memory*) is
-cryptographically isolated from both the Normal and Secure Worlds. This means
-that:
-- Realm memory is encrypted using keys that are unique to each Realm.
-- Non-Realm entities (like the host OS or hypervisor) cannot directly read or
-  write Realm memory.
+cryptographically isolated from both the Normal and Secure Worlds. 
+
+This means that:
+- Realm memory is encrypted with unique keys
+- Non-Realm entities (host OS, hypervisor) cannot directly read or
+  write to Realm memory
 - Even Direct Memory Access (DMA) from peripherals or untrusted drivers cannot
-  access Realm data.
+  access Realm data
 
 This design ensures confidentiality but introduces a problem: How can Realms
 interact with untrusted components, such as:
 - Network stacks in the host OS,
 - Storage subsystems,
 - I/O devices managed by untrusted drivers?
 
-The solution to safely exchange data between a Realm and the outside World is to
-use bounce buffers as an intermediary.
+To exchange data securely with untrusted components (for example, network stacks, storage subsystems), Realms use bounce buffers as intermediaries.
 
 ### How bounce buffers are used with RME
 
 1. Exporting Data:
-   - A Realm application prepares some data (e.g., results of computation).
+   - A Realm application prepares some data (for example, the results of computation)
    - It copies this data from protected Realm memory into a bounce buffer.
    - The Realm notifies the untrusted host or hypervisor that the data is ready.
    - The host retrieves the data from the bounce buffer.

content/learning-paths/servers-and-cloud-computing/cca-device-attach/_index.md

@@ -13,8 +13,7 @@ learning_objectives:
 prerequisites:
     - An AArch64 or x86_64 computer running Linux or macOS. You can use cloud instances, see this list of [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/).
     - Completion of [Get Started with CCA Attestation and Veraison](/learning-paths/servers-and-cloud-computing/cca-veraison) Learning Path.
-    - Completion of the [Run an application in a Realm using the Arm Confidential Computing Architecture (CCA)](/learning-paths/servers-and-cloud-computing/cca-container/) Learning Path.
-    - Completion of the [Run an end-to-end Attestation Flow](/learning-paths/servers-and-cloud-computing/cca-essentials/) Learning Path.
+    - Completion of the [Run an application in a Realm using the Arm Confidential Computing Architecture (CCA)](/learning-paths/servers-and-cloud-computing/cca-container/) Learning Path.                              - Completion of the [Run an end-to-end Attestation Flow](/learning-paths/servers-and-cloud-computing/cca-essentials/) Learning Path.
 
 author: Arnaud de Grandmaison