# Explore secure device attach in Arm CCA Realms

## In this learning path

- [Introduction](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-device-attach/)
- [About CCA Realms](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-device-attach/1-introduction/)
- [VirtIO for device attach](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-device-attach/2-virtio/)
- [Bounce buffers in Realms](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-device-attach/3.bounce_buffers/)
- [Exercise: observe bounce buffers in a Realm](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-device-attach/4.lab-observe-bounce-buffers/)
- [Next Steps](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-device-attach/_next-steps/)

## About this Learning Path

| Skill level:    | Advanced          |
|------------------|------------------|
| Reading time:    | 1 hr 30 min      |
| Last updated:    | 03 Jul 2026      |

| Author:          | Arnaud de Grandmaison, Arm [GitHub](https://github.com/Arnaud-de-Grandmaison-ARM) [LinkedIn](https://linkedin.com/in/arnauddegrandmaison) |
|------------------|------------------|
| Arm IP:          | [Neoverse](https://support.arm.com/?tab=compute-ip&Product%20Type=Infrastructure%20Processors) [Cortex-A](https://support.arm.com/?tab=compute-ip&Product%20Type=Application%20Processors) |
| Tags:            | [Performance and Architecture](https://learn.arm.com/tag/performance-and-architecture) [Linux](https://learn.arm.com/tag/linux) [macOS](https://learn.arm.com/tag/macos) [CCA](https://learn.arm.com/tag/cca) [RME](https://learn.arm.com/tag/rme) [Docker](https://learn.arm.com/tag/docker) |

### Who is this for?
This is an advanced topic for developers who want to understand how Arm CCA Realms interact with I/O devices using VirtIO, bounce buffers, and secure device attach mechanisms.

### What will you learn?
Upon completion of this Learning Path, you will be able to:
- Define device attach and distinguish VirtIO paravirtualized attach from secure physical device attach
- Summarize what a Realm is and how RME isolates Realm memory
- Describe how VirtIO enables paravirtualized I/O without full device emulation
- Explain when and why SWIOTLB bounce buffers are used in Realms
- Describe how PCIe‑TDISP and PCIe‑IDE support secure physical device attach and attestation

### Prerequisites
Before starting, you will need the following:
- An AArch64 or x86_64 computer running Linux or macOS. You can also use a cloud instance from one of these [Arm cloud service providers](https://learn.arm.com/learning-paths/servers-and-cloud-computing/csp/).
- Completion of the [Get Started with CCA Attestation and Veraison](https://learn.arm.com/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)](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-container/) Learning Path
- Completion of the [Run an end-to-end Attestation Flow](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-essentials/) Learning Path

### Summary
You’ll examine how Arm CCA Realms attach to I/O devices through two models: paravirtualized VirtIO and secure physical device attach. First, you’ll learn about Realm isolation with RME, how VirtIO enables mediated device access, and why SWIOTLB bounce buffers are used when devices can’t DMA directly to Realm memory. You’ll also explore how PCIe‑TDISP and PCIe‑IDE provide secure device attach with attestation. Then, you’ll run a pre-built Key Broker demo inside a Realm and use kernel tracing to observe SWIOTLB activity during VirtIO network I/O. By the end, you’ll recognize when data paths rely on bounce buffers and how this relates to the chosen device attach method.

### Frequently asked questions

<details>
<summary>How do I know that bounce buffers are being used in the Realm?</summary>
Use kernel tracing during the exercise to observe activity indicating SWIOTLB usage while the Key Broker demo generates network I/O through VirtIO. Seeing trace output associated with SWIOTLB during traffic confirms that data is bouncing through DMA-capable buffers.
</details>

<details>
<summary>What should I expect after starting the Key Broker container image?</summary>
The container runs a pre-built Key Broker demo used in the exercise. After it starts, list network interfaces to confirm connectivity before proceeding to kernel tracing.
</details>

<details>
<summary>When is VirtIO the right choice versus secure physical device attach?</summary>
VirtIO is the first level of device attach, mediated by the hypervisor with paravirtualized drivers, and is sufficient for many Realm I/O needs. Secure physical device attach using PCIe‑TDISP and PCIe‑IDE applies when hardware-backed isolation and attestation for the device are required.
</details>

<details>
<summary>Why do Realms rely on SWIOTLB bounce buffers for I/O?</summary>
Bounce buffers are used when a device cannot DMA to the original buffer, including when memory is not accessible to the device or does not meet alignment or contiguity constraints. In Realms, SWIOTLB enables data transfer between Realm-protected memory and devices during VirtIO I/O.
</details>

<details>
<summary>Will I learn to perform attestation of a physically attached device?</summary>
You’ll learn how PCIe‑TDISP and PCIe‑IDE support secure physical device attach and attestation. The hands-on exercise focuses on VirtIO and observing SWIOTLB behavior, not on performing a physical device attestation workflow.
</details>
