ASAravind Sivakumaran
Theme

Theme and appearance

Appearance
Palette

Pick any colour. The displayed accent adjusts for readable contrast in light or dark mode.

← IOMMU star map

SECURITY / TRUSTED I/O

When may a device use a confidential VM's private memory?

In the secure DMA chapter every device was kept to shared pages, so data went through a bounce buffer the host can read. SEV-TIO lets a VM trust one device interface (a TDI) and give it its private pages. Trust is built in separate steps, and each one can fail on its own: the device proves who it is, the host binds it to the VM, the VM checks it, the interface starts, and only then does the VM grant it memory.

What claims does this page make? 3 points
The guest, the AMD Secure Processor and the hypervisor above; the TDI, the IOMMU with its secure device table entry, the RMP check and RAM below, the TDI joined to the IOMMU by an encrypted PCIe link. Guest A accepts, grants AMD-SP (TSM) binds, owns secure DTE Hypervisor asks, injects IRQs TDI (NIC) TDISP state IOMMU DTE + secure DTE RMP check owner, VMPL RAM O is A's IDE

Experiments

Words used in the experiments
TDI
TEE Device Interface: the part of a device (a function or a virtual function) that can be given to one confidential VM.
SPDM
The protocol a device uses to prove its identity and report measurements of its firmware.
TDISP
The PCIe protocol for a TDI's life: CONFIG_UNLOCKED, CONFIG_LOCKED, RUN, ERROR.
IDE
Integrity and Data Encryption: protection of the PCIe link itself.
TSM, AMD-SP
The TEE Security Manager, here AMD's Secure Processor; it binds TDIs and writes their secure device table entries.
Secure DTE (SDTE)
The part of a TDI's device table entry the host cannot edit, including the VMPL the device's accesses use.
Grant
The guest's own request (TIO_MSG_SDTE_WRITE_REQ) that lets the TDI use its private memory.
TEE
Trusted Execution Environment: here, the confidential VM and the hardware and firmware it trusts.
PRI, PPR
A device asking for a page to be made present (PCIe PRI); AMD logs it as a Peripheral Page Request.
XT, T
PCIe bits that mark a request as trusted traffic from a TDI; which combinations are valid comes from TDISP (48882 §2.14.5).
MSI
An interrupt a device raises by writing to a special address.
ASID fence
A block on a guest's trusted I/O after a fault. 48882 §2.5.9.1 logs requests from a fenced guest and refers to SEV-TIO 58271 for the details; the recovery shown here follows the author's study notes.

Experiment

The gates, the interfaces and the fences

    Intel and Arm:

    What each side holds after that step

    Device interfaces

      RAM · who owns each page

        ASID fences

          Guest's secure PPR buffer

            What happened

              A teaching model: its steps and names follow the specifications, but it carries no messages, keys or wire formats, and it does not run SPDM, TDISP or IDE. It is not dmakit: the emulated IOMMU has no SEV-TIO.

              Who does what

              PartIts job here
              SPDMThe device proves its identity and reports its firmware measurements.
              IDEEncrypts and protects the PCIe traffic between the device and the root port.
              TDISPLocks the interface's configuration and moves it to RUN or ERROR.
              AMD-SP (as TSM)Binds the TDI to a guest, writes the secure DTE, keeps the fence (48882 §2.5.9.1; details in SEV-TIO 58271).
              The guestDecides whether to trust the evidence, grants private DMA, validates MMIO.
              IOMMU and RMPCheck every request against both DTEs, the page's owner and the TDI's VMPL.

              The VM's memory key never goes to the device: its accesses are checked by the IOMMU and the RMP like everyone else's, and the link has its own keys (E33).

              An interface's life

              CONFIG_UNLOCKED, bound and locked to CONFIG_LOCKED, started to RUN, a fault to ERROR, stopped back to CONFIG_UNLOCKED. CONFIG_UNLOCKED CONFIG_LOCKED RUN bind (lock) start stop and unbind; any state can fall to ERROR
              1. Authenticate (SPDM) and protect the link (IDE).
              2. Bind: the host asks the AMD-SP (TIO_TDI_BIND); the interface locks its configuration.
              3. Accept: the guest reads the interface's report and measurements and compares them with its own policy.
              4. Start: the interface enters RUN.
              5. Grant: the guest asks the AMD-SP to write the secure DTE (TIO_MSG_SDTE_WRITE_REQ), with the VMPL the device's accesses use. Private MMIO is validated separately (TIO_MSG_MMIO_VALIDATE_REQ).
              6. Leave: stop, revoke, unbind; a new owner starts again from step 2.

              Evidence beneath accept

              "Accept" is a decision made on four artifacts. Each is checked against something A already holds, and each can be present and right, present and wrong, or missing. Only all four right accept; wrong is refused, and missing stays unknown, which is not a yes. The experiment "Look at the evidence before accepting" replays this.

              Synthetic example: values are invented labels, and no signature is computed.
              ArtifactA compares it withPresent but wrongMissing
              Certificate chain (SPDM GET_CERTIFICATE)A's own trust anchorrefused: an unknown issuerunknown
              Challenge answer (CHALLENGE_AUTH)the chain just shown, with a signature that covers the nonce A sent in CHALLENGErefused, even if the signature is valid for its own older challengeunknown
              Measurements (MEASUREMENTS)the same nonce, and A's list of firmware versionsrefused: stale, unsigned or unlisted firmwareunknown
              Interface report (TDISP)the TDI A was told it is getting, and its locked staterefused: another interface, or still unlockedunknown

              Counterexample. A challenge answer with a valid signature over an old nonce is still refused: it proves the device once signed something, not that it is the one answering now. The host having already run SPDM and bound the interface does not change A's own check.

              Question. A has chain, measurements and report, but no challenge answer. Which of accept, start and grant can happen, and which artifact would you ask for first?

              The profile is SPDM 1.2.1 message shapes. AMD's SEV-TIO 0.92 is described as referencing SPDM 1.2.1, so a newer SPDM publication alone does not change this model. The AMD document could not be fetched while this was written, so that reference is not checked against it here.

              What changes in the IOMMU (§2.14)

              The support bits are 0030h[VMGuardIOSup] and 01A0h[SevSnpIoSup]; 01A0h[XteeSup] says which request types can carry the TEE bit, and 01A0h[SmeTioSupDis]=1 means SME cannot be used with SEV-TIO (the bit's sense is negative).

              Trusted DMA saves a copy, not all the work

              16-byte receiveThe device writesCPU copies
              Ordinary device, shared bounce bufferB48 bytes (map, sync, unmap)
              Granted TDI, directO0 bounce bytes; the guest still checks the message
              Granted TDI that still needs a bounce poolan encrypted bounce buffersome copies remain

              The counts come from the Linux DMA lab; they are not a speed measurement. A trusted device is trusted with plaintext, not with the correctness of what it sends (W22).

              Sources