# IOMMU permission and tensor identity Canonical: https://semiaifoundry.com/learn/atlas/iommu-buffer-identity/ Revision: 2026-10-07 Rights: https://semiaifoundry.com/ai-atlas/licenses.html Executable software · Atlas v1.3.0 # IOMMU permission and tensor identity Distinguish protection validity from the semantic identity of a matrix operand. [Explore in Atlas](https://semiaifoundry.com/ai-atlas/#iommu-buffer-identity)One process and device job; logical states and byte addresses, no timing or physical geometry Learning objectivePredict the different numerical and transfer outcomes of a permitted wrong alias and an absent device mapping. ## The mechanism A translation unit can reject an absent or disallowed device address, but that check alone cannot establish that a driver supplied the intended tensor. The runtime must also preserve the association between a logical operand and its physical storage. This distinction is visible when the B descriptor points through a permitted mapping to A. Every transferred word is readable, arithmetic proceeds, and the device reports completion. Yet it has computed A squared rather than A times B. Removing B’s mapping instead yields a protection failure and supplies no B operand. Comparing the two cases prevents a common diagnostic shortcut: the absence of an address fault does not prove a computation used the right data. The teaching checker applies exact range, access-direction and epoch conditions; its semantic oracle separately compares the produced matrix with the declared operation. 1. Each device range has a base, byte length, physical target, read/write permission and current epoch. 2. A DMA request must fit completely within exactly one permitted range of the current epoch. 3. A missing B range rejects its first read after A has already transferred; arithmetic receives no B values. 4. The wrong-mapping specimen redirects B to A while preserving readable permissions. 5. Device MACs use those delivered words and therefore compute the operation implied by the wrong data. 6. Only a separate operand-identity or result check reveals the semantic mismatch; the protection mechanism is not a tensor verifier. ## Science and assumptions ### A complete access must fit its declared range $$ g\leq d\;\land\;d+q\leq g+L\;\land\;P_{\mathrm{access}}\;\land\;e_{\mathrm{map}}=e_{\mathrm{active}} $$ The request starts at or above the range base, ends within its byte length, has permission, and uses the active mapping epoch. Symbols and units g,d Mapped base and requested device byte address bytes q,L Request length and mapped region length bytes Paccess Requested read or write permission Boolean emap,eactive Mapping and current device generations count The model requires exactly one matching translation. Ending at the upper boundary is valid; crossing it is rejected. Assumptions Positive integer request length, declared sixteen-byte ranges and a sixteen-bit device address mask. No physical IOMMU page granularity is inferred. ### A wrong alias changes the computed operation $$ C_{\mathrm{observed}}=AA=\begin{bmatrix}7&10\\15&22\end{bmatrix}\ne AB=\begin{bmatrix}19&22\\43&50\end{bmatrix} $$ The default B-to-A alias computes \[\[7,10\],\[15,22\]\] instead of \[\[19,22\],\[43,50\]\]. Symbols and units A,B Default exact 2×2 input matrices integer values Cobserved Output produced using delivered operands integer values The outcome follows from actual device input arrays. All reads pass range and permission checks in this scenario. Assumptions Only the displayed default matrices and B-to-A mapping; some other matrices could coincidentally produce equal results. ## Engineering example With default A and B, correct mappings yield \[\[19,22\],\[43,50\]\]. The B→A alias transfers 32 input bytes and completes eight MACs, yielding \[\[7,10\],\[15,22\]\] without any protection rejection. The absent-B case instead transfers A’s 16 bytes, rejects B’s first word, executes zero MACs and publishes nothing. An ownership or mapping diagnostic should report these as distinct failures. ## Distinctions and tradeoffs A successful translation proves only its stated address/permission contract; it does not prove tensor identity. Permission checks constrain access while identity checks protect meaning. Stronger software tracking is useful, but this experiment does not establish malicious-device isolation, replay protection or an operating-system security boundary. Custom accelerator drivers and graph runtimes manage many buffers and aliases. Correct tensor shapes and valid addresses must remain associated with the right storage throughout lowering and dispatch. ## Specifications and interfaces Protection checks Range, direction, current epoch A model of declared byte regions, not a real hardware page-table encoding. Wrong alias Logical B → physical A Readable but not the intended tensor. Missing range B read blocked before arithmetic The sixteen A bytes already transferred are still counted. ### Interfaces Declared runtime inputs Input Stable matrix job, buffer identities and the stated device/visibility contract Inspectable accepted or rejected result Output Event trace, actual buffer values and bounded completion/work ledger ## Check your understanding ### The B IOVA maps to readable A storage. What does this specimen do? 1. Always faults because the logical names differ 2. Computes with A as both operands, then exposes a result mismatch 3. Automatically finds B from the mathematical reference Answer and reasoning Computes with A as both operands, then exposes a result mismatch The translation unit checks its table. The device consumes the actual transferred A values. ## Evidence and scope Primary sources establish the cited runtime mechanisms. Numerical values, address ranges, ABI strings, event schedule and reset/retry epochs are authored teaching contracts. No real device, firmware image, operating-system driver, page table, cache protocol or security verification is executed. The commissioning-execution-1 studio executes this bounded 2×2 matrix, buffer and completion contract. The surrounding atlas scene is conceptual; it is not a firmware emulator or system simulator. ## Sources - [Linux 6.16 — Dynamic DMA mapping Guide](https://docs.kernel.org/6.16/core-api/dma-api-howto.html) [Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/iommu-buffer-identity-c6226bf1fe320f07.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html) ## Continue exploring ### Foundations - [Process, physical and device address spaces](https://semiaifoundry.com/learn/atlas/process-dma-address-spaces/) ### Related lessons - [Runtime, driver and device dispatch](https://semiaifoundry.com/learn/atlas/runtime-device-dispatch/) - [DMA visibility, ordering and buffer lifetime](https://semiaifoundry.com/learn/atlas/dma-visibility-ownership/) - [Sharded matrix multiplication and result ownership](https://semiaifoundry.com/learn/atlas/sharded-matmul-ownership/)