When the Container Limit Is Not the Resource Boundary
MicroVM-based containers are the subject here: systems such as Kata Containers and Firecracker that put a container workload inside a lightweight virtual machine while still presenting it through familiar cloud and Kubernetes interfaces. The specific question is whether the boundary that isolates a workload is also the boundary that accounts for its memory, storage, eviction risk, and bill. By the end of this series, the useful judgment will not be simply whether microVMs are “secure,” but whether a particular deployment can show who physically consumes a resource, who is charged for it, and which control responds when the two diverge.
That distinction matters because microVMs solve a real problem. Traditional containers share a host kernel, so a kernel vulnerability or an unsafe interaction can threaten the isolation of multiple workloads. A microVM gives the workload a guest kernel and places a virtual machine monitor between that guest and the host. Kata Containers uses this model to run container workloads in hardware-isolated VMs; Firecracker pursues a similarly lightweight VM boundary for serverless and multi-tenant environments. The additional layer can reduce the attack surface without abandoning container packaging and orchestration.
But isolation is not the same as accounting. A workload can be isolated from the host kernel while some of the host work performed on its behalf is carried out by a VMM or a virtio service. The host may then attribute a physical page to that service, or a storage scanner may see only the paths it knows to inspect. The workload remains inside the VM, but the resource it caused may be outside the observer’s chosen boundary. This is the central tension in the USENIX Security 2026 study that anchors this series.
The boundary that microVMs do not automatically close
A useful starting point is to separate three statements that are often compressed into one:
- The workload is isolated from other workloads.
- The workload is charged for the resources it causes the host to consume.
- The tenant is billed and governed according to that charge.
A microVM can make the first statement substantially stronger without guaranteeing the other two. The second depends on the host kernel’s accounting rules and on which host process first creates or retains a physical resource. The third depends on how an orchestrator turns those observations into quotas, eviction decisions, and prices.
Kata’s own host-cgroup design makes the extra accounting surface visible. A workload runs in a guest VM, but the host also runs a VMM, a Kata shim, and I/O-related threads. These processes consume host CPU and memory even though they are not application processes inside the guest. Kata therefore has to decide whether sandbox processes belong under the pod’s resource boundary or under a separate overhead boundary. That is an ordinary systems-design question before it becomes a security question: the runtime must know what the orchestrator’s limit was meant to include.
The same pattern appears in the study’s treatment of Firecracker and other microVM arrangements. The guest initiates an operation, but a host-side component may perform the operation that makes memory resident or moves data to storage. “The container used it” and “the container’s cgroup was charged” are no longer interchangeable descriptions. The relationship between those statements must be designed and tested.
The consequence reaches beyond a misleading dashboard. If memory used on behalf of one tenant is charged to a backend process outside that tenant’s limit, the tenant can put pressure on host memory while appearing compliant. If storage accounting scans only selected paths, data retained through a different path may not count toward the pod’s ephemeral-storage limit. A scheduler or eviction manager then acts on an incomplete picture. A cloud billing system may charge for the resource request and execution time rather than for every physical page or disk block that the host actually supplied. An innocent neighboring workload can absorb the resulting latency or eviction even though its own usage was visible and correctly charged.
The study reports these consequences as a connected class of resource-accounting vulnerabilities, not as a claim that every microVM deployment behaves identically. In one local experiment, a Kata container configured with a 64 MiB memory limit accessed roughly 32 GiB of mapped pages while the guest’s accounting remained near its limit. That result illustrates the scale of a mismatch under the tested configuration; it is not a universal amplification factor for all VMMs, backends, or releases. The authors separately performed limited feasibility checks on public cloud environments and confined large resource-overuse and interference experiments to their local testbed.
One action, several accounting systems
The easiest way to keep the subject straight is to follow one action rather than begin with a list of components. Imagine a program in a guest reading a file-backed dataset. The guest application issues a read. The guest kernel and a virtual I/O frontend participate, but a host-side backend may load the corresponding data and make pages resident. The host kernel applies its memory-accounting rules to the process that first touches those physical pages. Kubernetes and the cloud platform may use yet another signal: a pod cgroup metric, a filesystem scan, a declared resource request, or a combination of request and duration.
Those observers answer different questions. A guest metric can report how much memory the guest currently accounts for. A host cgroup can report what the host charged to a particular process hierarchy. A Kubernetes storage measurement can report what a scanner found under selected paths. A bill can reflect what the tenant reserved, not what the host physically supplied beyond that reservation. None of these measurements is automatically false. The danger is treating one as a complete substitute for the others.
The diagram’s dotted distinction is the point to retain. Physical use is a fact about the host: pages are resident, blocks are allocated, or I/O bandwidth is being consumed. Reported charge is a fact about an accounting policy: a process, cgroup, path, or request has been selected as the owner. A trustworthy limit requires those two facts to remain sufficiently aligned for the decision being made.
This is also why the subject is not merely “a bug in cgroups.” Cgroups provide the host’s accounting and enforcement machinery, but the microVM changes who performs the work and where the relevant object appears. Kubernetes adds a path-based storage policy and eviction logic. Cloud billing adds an economic interpretation. Kata’s documentation describes resource controls at multiple levels—inside the VM, inside the container, and outside the VM—because a VM-based system has more than one place where a constraint can be applied. The accounting question crosses all of them.
The paper examines two broad resource dimensions. For memory, it studies file-backed pages whose loading can be delegated to a host process. For storage, it studies paths and file lifecycles that a Kubernetes scan may not include. The reported attack called FREE combines memory and storage behaviors, but the underlying lesson does not depend on the attack name: a workload can exploit a gap whenever physical ownership, observer visibility, and enforcement are defined on different layers.
What the evidence does—and does not—say
The evidence is unusually concrete for an architectural problem. The paper proposes a differential analysis that compares memory actually used by a guest with pages charged to its host cgroup, and compares storage actually occupied with the usage reported by Kubernetes. It then tests Kata and Firecracker arrangements, measures application and co-tenant effects, and describes mitigations such as monitoring host-backend growth or accounting for hidden file objects. The Kata documentation supplies an important companion view: even without the paper’s attack patterns, the runtime must choose how sandbox overhead is placed and who is responsible for sizing it.
Together, these sources support a strong but bounded conclusion. MicroVM-based containers can combine useful isolation with a resource-accounting boundary that is incomplete under particular I/O, cgroup, mount, and storage configurations. The study reports billing reductions to about 42% of the original modeled payment for selected Kata and Firecracker workloads, as well as substantial local co-tenant degradation. Those figures show why the mismatch matters economically and operationally. They do not establish a universal discount, a measured large-scale theft event in a public cloud, or a claim that every current deployment remains vulnerable after disclosure and remediation.
The practical question for a platform operator is therefore precise: when a guest causes work on the host, what mechanism makes that work visible to the correct limit? If the answer is “the pod cgroup,” is the VMM or backend actually in it? If the answer is “the storage scanner,” can it see an object that has been unlinked, passed through, or retained by a host-side process? If the answer is “the bill,” does the pricing model use the same resource boundary as enforcement, or only the declared request and runtime?
Those questions also define the relationship among the systems in this series. Kata and Firecracker remain the subjects, not interchangeable examples of generic virtualization. Linux cgroups provide the accounting and enforcement rules. Virtio and the VMM determine where guest operations are handled. Kubernetes converts selected observations into limits and eviction. Cloud billing turns declared resource use and time into a financial obligation. Co-located tenants experience the performance and availability consequences when the chain is incomplete.
The first answer is now visible: a container limit is a promise about a resource boundary, and a microVM supplies only part of that boundary. The next step is to examine how Kata places sandbox processes in host cgroups, because that design choice reveals the difference between an overhead that is deliberately separated and a resource that is charged somewhere else by accident or by omission.