Abstract

This disclosure describes a method and system for securely reassigning hardware resources between tenants, virtual machines, hosts, or security domains in cloud, data-center, and AI computing infrastructure. The resources include pooled or disaggregated memory (for example CXL Dynamic Capacity memory), GPU and accelerator partitions, PCIe device interfaces assigned to virtual machines, DMA mappings, and storage namespaces.

The problem addressed is a time-of-check to time-of-use (TOCTOU) gap in resource reallocation. Device attestation, link encryption, and access-control checks confirm that a device is authentic and that a request is permitted, but the actual reconfiguration (mapping memory to a new host, attaching a device to a new virtual machine, enabling a DMA mapping) happens later and may be performed by a different component. In between, the resource may be substituted, the destination may change, ownership may change, memory scrubbing may be incomplete, policy may be revoked, or an old authorization may be replayed. The result can be data remanence: a new tenant gaining access to residual data, such as model weights or inference cache, left by the previous tenant.

In the disclosed system, a requested reassignment is held in a pending, inactive state. An authorization is issued as a single-use token cryptographically bound to a hash of the exact request: resource identifier, source owner, destination, operation, an allocation generation counter, required security state, policy version, nonce, and expiry. The reassignment is applied only by a hardware or firmware enforcement point that controls the actual reconfiguration, such as a memory controller, CXL host bridge or switch, IOMMU/SMMU, hypervisor, or device logic. Immediately before applying the change, the enforcement point re-checks that the actual operation matches the hashed request, the token is unexpired and unused, the generation counter is current, the source still owns the resource, the memory has been scrubbed or cryptographically erased, prior mappings and DMA access have been revoked, and policy still permits the change. Only if all checks pass does it consume the token, apply the reconfiguration, and increment the generation counter; otherwise the request is denied by default (fail-closed). Incrementing the generation counter ensures that when two requests compete for the same resource, only one can succeed. All alternate configuration paths, including management interfaces, firmware commands, and debug or recovery tools, must pass through the same enforcement point. A journaled commit procedure prevents a crash between token consumption and reconfiguration from leaving a reusable token or an untracked mapping.

The approach complements, and does not replace, existing mechanisms such as SPDM device attestation, IETF RATS remote attestation, PCIe IDE link encryption, PCIe TDISP trusted device assignment, CXL security requirements, Arm CCA, and GPU confidential computing. The disclosure includes a formal model, state machine, pseudocode, a CXL memory reassignment example, security analysis, and workflow diagrams. No vulnerability is alleged in any named product or specification.

Full record: https://zenodo.org/records/23723758

Keywords: memory reallocation between tenants; secure resource reassignment; data remanence; memory scrubbing before reallocation; cryptographic erase; TOCTOU prevention; single-use authorization token; replay protection; generation counter; epoch counter; hash-bound authorization; hardware enforcement point; memory controller access control; IOMMU; SMMU; DMA protection; CXL Dynamic Capacity; memory pooling; disaggregated memory; PCIe TDISP; PCIe IDE; SPDM; remote attestation; virtual machine device assignment; GPU partitioning; multi-tenant accelerator; confidential computing; fail-closed access control; hypervisor resource management

Related classification areas (CPC): G06F 12/14 (protection against unauthorized use of memory); G06F 12/1081 (address translation for peripheral access to memory, e.g. DMA/IOMMU); G06F 21/57 (certifying or maintaining trusted computer platforms); G06F 21/79 (secure storage of data in semiconductor memory); G06F 21/85 (protecting input/output devices); G06F 9/5016 (allocation of memory resources); G06F 9/45558 (hypervisor-specific management and integration aspects)

Creative Commons License

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial 4.0 License

Share

COinS