SECURITY / BUFFER WORKBOOK

Follow 16 bytes through a bounce buffer

An ordinary NIC may not write a confidential VM's private pages (secure DMA), so Linux gives it a bounce buffer in shared memory and copies. The Linux DMA lab shows those copies; this workbook asks the security questions about the same bytes: when does each buffer change, what can the host read, and when may the application trust what arrived? The copies below follow Linux 7.3's code, as dmakit models it.

What claims does this page make? 2 points

Platform assumption: the copy points of map, sync and unmap follow Linux 7.3 swiotlb and DMA code as dmakit models it, and may differ in other kernels.
Teaching model: the descriptors, the application's checks and the host-read panel are this page's own small model, with synthetic addresses.

Address or copy? Four routes to the same buffer

A 32-bit device receives 16 bytes into O, which sits above 4 GiB. A translation (IOMMU) changes the address the device uses; only a CPU copy (SWIOTLB) moves bytes. Pick a route, map the buffer, and submit only if the map succeeded.

The route comparison needs JavaScript. Worked example without it: a 32-bit device cannot address O (above 4 GiB). With an IOMMU the device uses a translated address below 4 GiB and no byte is copied (one translation arrow). With only SWIOTLB the CPU copies the 16 bytes between O and the bounce buffer B (a copy arrow, 16 bytes per copy). Direct, with neither, fails: the map returns no handle.

Route

Sharing a message shares its page

Worked example from the fixture, not run in this browser (S03, from the confidential-VM lesson cvm-08). Copying the 16-byte message into a shared page leaves SPA 0x2000000 holding 16 bytes: the host read sees only the 16-byte message. Sharing the whole page instead exposes SPA 0x80000000, which holds 32 bytes: the host's second read saw the message and 16 bytes of the unrelated marker. Sharing granularity is the page (4096 bytes).

Experiments

Words used in the experiments

O, B, App: The driver's buffer at 0x100002040, private (the Linux DMA lab's Original A; 64 bytes into secure DMA's private page O; the model uses one address as both GPA and SPA), the bounce slot the kernel copies through (0x2000040, in a shared pool), and the application's buffer.
Map, sync, unmap: dma_map_single() gives the device an address; dma_sync_single_for_cpu() or _for_device() hands the buffer over; dma_unmap_single() ends it. With a bounce buffer, each can copy.
Receive, send: DMA_FROM_DEVICE (the device writes) and DMA_TO_DEVICE (the device reads).
RX16: The packet: de ad be ef, four times.

Choose an experiment (core: start here; deeper: more cases; reference: catalogue)

Experiment

Timeline: which buffer holds the bytes, and what the CPU copied

Worked example from the fixture, not run in this browser (S02, experiment wb-01, a receive of 16 bytes). Map: the kernel copies O to B (16 bytes copied, 0 written by the device). The NIC writes de ad be ef four times into B (16 bytes written, still 16 copied). The sync copies B to O (32 copied). The unmap copies B to O again: 48 bytes copied for 16 received. Unmapping straight after the device finishes, without the sync, copies 32. Copy events 1 to 3 each move 16 bytes: map O to B, sync B to O, unmap B to O. Synthetic addresses; no real device.

Worked example from the fixture, not run in this browser (S04, experiment wb-07). The NIC writes P (11 repeated 16 times) into B, the sync copies it to O, and P is checked and approved. The host then writes Q (22 repeated 16 times) into B and the unmap copies B back: O now holds Q. The approval of P does not cover O, because O now holds different bytes; a snapshot of P copied to App before the unmap would still hold P.Worked example from the fixture, not run in this browser (S10, experiment wb-09). One descriptor becomes two 4-byte writes. Write 1, aa bb cc dd to page X (writable), is allowed: 4 bytes committed, X changes from 00 00 00 00. Write 2, 10 20 30 40 to page Y (read-only), is denied by the IOMMU: 0 bytes committed, Y unchanged, and a fault is recorded in the trace and retained by the 4-slot teaching event ring (3 usable). The whole descriptor requested 8 bytes and committed 4: incomplete, and the first write is not undone. Two more denied writes fill the ring and a third finds no room: that fault occurred but its record is dropped, EventOverflow is set and Y is still unchanged. Consuming the records, clearing the overflow and restarting logging are three separate steps, and none of them changes the read-only mapping or retries the DMA.

Intel and Arm:

The bytes after that step

Buffers

Copy ledger · every CPU copy so far, never erased by a later failure

Counters

What the host read

Driver and application

A copy of 16 bytes counts 16, not 32. Counts are bytes, not time. Descriptors and the application's checks are this page's own small model; the copies and the IOMMU are dmakit's.

Three kinds of "ownership", all true at once

Question	Answered by	After a receive's sync
May the CPU use O now?	The DMA API (map, sync, unmap)	Yes
Whose page is O?	The RMP (SNP)	Still the VM's private page
Can the application trust the bytes?	The application's own checks	Not until it checks them

Pressing "sync" does not change who owns the page, and a private page can hold untrusted input.

Rules that fall out

Anything in a buffer you map may be copied into shared memory, even for a receive, and even if the map then fails.
Check lengths and descriptors from the device or shared memory against what you mapped, in a private copy, and use that copy.
Validate after the last copy into O, or take your own snapshot first.
Clean up with the size you mapped, never a size the device reported.
A failed operation can leave earlier writes behind; retrying may repeat them.
To carry secrets through B at all, encrypt them in the application (the AES-GCM experiment).

Sources

Linux 7.3 kernel/dma/swiotlb.c, kernel/dma/direct.c, drivers/iommu/dma-iommu.c, as dmakit 3.0.0 modelled them when reviewed (the site now ships 4.3.0) (model limits); Linux DMA API HOWTO.
The author's own study notes on confidential computing, written from AMD's public documents (not published), workbook lessons W03 to W06, W16, W17, W25, W26 and W28, and examples E15 to E18.