{
  "schemaVersion": 1,
  "id": "atlas-lesson-iommu-buffer-identity",
  "title": "IOMMU permission and tensor identity",
  "category": "learning",
  "format": "Atlas lesson",
  "description": "Distinguish protection validity from the semantic identity of a matrix operand.",
  "canonicalUrl": "https://semiaifoundry.com/learn/atlas/iommu-buffer-identity/",
  "publishedDate": null,
  "revisionDate": "2026-10-07",
  "author": null,
  "topic": "Executable software",
  "series": null,
  "license": null,
  "rightsUrl": "https://semiaifoundry.com/ai-atlas/licenses.html",
  "version": "1.3.0",
  "status": "Published educational lesson",
  "evidenceScope": "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.",
  "contentCoverage": "published-lesson",
  "artifactUrl": "https://semiaifoundry.com/ai-atlas/lesson-data/iommu-buffer-identity-c6226bf1fe320f07.json",
  "interactiveUrl": "https://semiaifoundry.com/ai-atlas/#iommu-buffer-identity",
  "related": [],
  "supersedes": [],
  "supersededBy": [],
  "contentHash": "ace0ad8a66ccd18f95039805f7bd8bdaeaca763da00d7f04c44a2be4f15e7f67",
  "contentLength": 6912,
  "jsonUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-iommu-buffer-identity.json",
  "markdownUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-iommu-buffer-identity.md",
  "sections": [
    {
      "id": "section-1",
      "title": "IOMMU permission and tensor identity",
      "start": 36,
      "end": 459
    },
    {
      "id": "section-2",
      "title": "The mechanism",
      "start": 459,
      "end": 2003
    },
    {
      "id": "section-3",
      "title": "Science and assumptions",
      "start": 2003,
      "end": 2031
    },
    {
      "id": "section-4",
      "title": "A complete access must fit its declared range",
      "start": 2031,
      "end": 2844
    },
    {
      "id": "section-5",
      "title": "A wrong alias changes the computed operation",
      "start": 2844,
      "end": 3498
    },
    {
      "id": "section-6",
      "title": "Engineering example",
      "start": 3498,
      "end": 3917
    },
    {
      "id": "section-7",
      "title": "Distinctions and tradeoffs",
      "start": 3917,
      "end": 4503
    },
    {
      "id": "section-8",
      "title": "Specifications and interfaces",
      "start": 4503,
      "end": 4850
    },
    {
      "id": "section-9",
      "title": "Interfaces",
      "start": 4850,
      "end": 5095
    },
    {
      "id": "section-10",
      "title": "Check your understanding",
      "start": 5095,
      "end": 5124
    },
    {
      "id": "section-11",
      "title": "The B IOVA maps to readable A storage. What does this specimen do?",
      "start": 5124,
      "end": 5556
    },
    {
      "id": "section-12",
      "title": "Evidence and scope",
      "start": 5556,
      "end": 6074
    },
    {
      "id": "section-13",
      "title": "Sources",
      "start": 6074,
      "end": 6390
    },
    {
      "id": "section-14",
      "title": "Continue exploring",
      "start": 6390,
      "end": 6413
    },
    {
      "id": "section-15",
      "title": "Foundations",
      "start": 6413,
      "end": 6548
    },
    {
      "id": "section-16",
      "title": "Related lessons",
      "start": 6548,
      "end": 6912
    }
  ],
  "citations": [
    {
      "title": "Explore in Atlas",
      "url": "https://semiaifoundry.com/ai-atlas/#iommu-buffer-identity"
    },
    {
      "title": "Linux 6.16 — Dynamic DMA mapping Guide",
      "url": "https://docs.kernel.org/6.16/core-api/dma-api-howto.html"
    },
    {
      "title": "Published lesson data",
      "url": "https://semiaifoundry.com/ai-atlas/lesson-data/iommu-buffer-identity-c6226bf1fe320f07.json"
    },
    {
      "title": "Atlas releases and licensing",
      "url": "https://semiaifoundry.com/ai-atlas/licenses.html"
    },
    {
      "title": "Process, physical and device address spaces",
      "url": "https://semiaifoundry.com/learn/atlas/process-dma-address-spaces/"
    },
    {
      "title": "Runtime, driver and device dispatch",
      "url": "https://semiaifoundry.com/learn/atlas/runtime-device-dispatch/"
    },
    {
      "title": "DMA visibility, ordering and buffer lifetime",
      "url": "https://semiaifoundry.com/learn/atlas/dma-visibility-ownership/"
    },
    {
      "title": "Sharded matrix multiplication and result ownership",
      "url": "https://semiaifoundry.com/learn/atlas/sharded-matmul-ownership/"
    }
  ],
  "recordHash": "283dc3a770aa54ca6d7f545d78ca6bf4f60c8b3662ab93e5df5f2c814f911b75",
  "contentFormat": "text/markdown",
  "content": "Executable software · Atlas v1.3.0\n\n# IOMMU permission and tensor identity\n\nDistinguish protection validity from the semantic identity of a matrix operand.\n\n[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\n\nLearning objectivePredict the different numerical and transfer outcomes of a permitted wrong alias and an absent device mapping.\n\n## The mechanism\n\nA 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.\n\n1.  Each device range has a base, byte length, physical target, read/write permission and current epoch.\n2.  A DMA request must fit completely within exactly one permitted range of the current epoch.\n3.  A missing B range rejects its first read after A has already transferred; arithmetic receives no B values.\n4.  The wrong-mapping specimen redirects B to A while preserving readable permissions.\n5.  Device MACs use those delivered words and therefore compute the operation implied by the wrong data.\n6.  Only a separate operand-identity or result check reveals the semantic mismatch; the protection mechanism is not a tensor verifier.\n\n## Science and assumptions\n\n### A complete access must fit its declared range\n\n$$\ng\\leq d\\;\\land\\;d+q\\leq g+L\\;\\land\\;P_{\\mathrm{access}}\\;\\land\\;e_{\\mathrm{map}}=e_{\\mathrm{active}}\n$$\n\nThe request starts at or above the range base, ends within its byte length, has permission, and uses the active mapping epoch.\n\nSymbols and units\n\ng,d\n\nMapped base and requested device byte address\n\nbytes\n\nq,L\n\nRequest length and mapped region length\n\nbytes\n\nPaccess\n\nRequested read or write permission\n\nBoolean\n\nemap,eactive\n\nMapping and current device generations\n\ncount\n\nThe model requires exactly one matching translation. Ending at the upper boundary is valid; crossing it is rejected.\n\nAssumptions Positive integer request length, declared sixteen-byte ranges and a sixteen-bit device address mask. No physical IOMMU page granularity is inferred.\n\n### A wrong alias changes the computed operation\n\n$$\nC_{\\mathrm{observed}}=AA=\\begin{bmatrix}7&10\\\\15&22\\end{bmatrix}\\ne AB=\\begin{bmatrix}19&22\\\\43&50\\end{bmatrix}\n$$\n\nThe default B-to-A alias computes \\[\\[7,10\\],\\[15,22\\]\\] instead of \\[\\[19,22\\],\\[43,50\\]\\].\n\nSymbols and units\n\nA,B\n\nDefault exact 2×2 input matrices\n\ninteger values\n\nCobserved\n\nOutput produced using delivered operands\n\ninteger values\n\nThe outcome follows from actual device input arrays. All reads pass range and permission checks in this scenario.\n\nAssumptions Only the displayed default matrices and B-to-A mapping; some other matrices could coincidentally produce equal results.\n\n## Engineering example\n\nWith 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.\n\n## Distinctions and tradeoffs\n\nA successful translation proves only its stated address/permission contract; it does not prove tensor identity.\n\nPermission 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.\n\nCustom 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.\n\n## Specifications and interfaces\n\nProtection checks\n\nRange, direction, current epoch\n\nA model of declared byte regions, not a real hardware page-table encoding.\n\nWrong alias\n\nLogical B → physical A\n\nReadable but not the intended tensor.\n\nMissing range\n\nB read blocked before arithmetic\n\nThe sixteen A bytes already transferred are still counted.\n\n### Interfaces\n\nDeclared runtime inputs Input\n\nStable matrix job, buffer identities and the stated device/visibility contract\n\nInspectable accepted or rejected result Output\n\nEvent trace, actual buffer values and bounded completion/work ledger\n\n## Check your understanding\n\n### The B IOVA maps to readable A storage. What does this specimen do?\n\n1.  Always faults because the logical names differ\n2.  Computes with A as both operands, then exposes a result mismatch\n3.  Automatically finds B from the mathematical reference\n\nAnswer and reasoning\n\nComputes with A as both operands, then exposes a result mismatch\n\nThe translation unit checks its table. The device consumes the actual transferred A values.\n\n## Evidence and scope\n\nPrimary 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.\n\nThe 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.\n\n## Sources\n\n-   [Linux 6.16 — Dynamic DMA mapping Guide](https://docs.kernel.org/6.16/core-api/dma-api-howto.html)\n\n[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)\n\n## Continue exploring\n\n### Foundations\n\n-   [Process, physical and device address spaces](https://semiaifoundry.com/learn/atlas/process-dma-address-spaces/)\n\n### Related lessons\n\n-   [Runtime, driver and device dispatch](https://semiaifoundry.com/learn/atlas/runtime-device-dispatch/)\n-   [DMA visibility, ordering and buffer lifetime](https://semiaifoundry.com/learn/atlas/dma-visibility-ownership/)\n-   [Sharded matrix multiplication and result ownership](https://semiaifoundry.com/learn/atlas/sharded-matmul-ownership/)"
}
