The First Checkpoint: What Must a Secure Boundary Actually Guarantee?

The FUSE contract and the WebAssembly sandbox answer different parts of the same problem. Together with Linux's resource policy and kSFS's recovery machinery, they suggest a compact way to judge whether an in-kernel boundary is real rather than rhetorical. The useful judgment is not whether kSFS has a “sandbox” in the abstract, but whether a proposed boundary can answer five concrete questions: what the implementation can touch, how it can fail, whether it can stall the kernel, how the trusted side recovers, and what the boundary costs.

One boundary, four responsibilities

The minimum model has four participants. Linux's trusted subsystems own the surrounding request path and the state that must remain coherent. A validated interface determines which operations and data can cross into the untrusted side. The file-system implementation supplies format-specific behavior but should not acquire the authority of the host. A capability-authorized storage resource gives the implementation somewhere to work without giving it access to every disk or file in the system.

This is not four boxes that happen to sit next to one another. It is a relationship of ownership. Linux decides when an operation is issued and how its result reaches the caller. The interface defines the request that the implementation is allowed to interpret. The implementation decides how to translate that request into filesystem behavior. The resource policy decides which external state the implementation may reach. If any one participant silently takes over another's responsibility, the boundary becomes much weaker than the diagram suggests.

FUSE supplies the shape of the relationship. The kernel queues a request, the implementation processes it, and the kernel receives a response through a defined channel. The implementation does not receive the ordinary, broad collection of pointers and callbacks that a trusted in-kernel filesystem may use. That is why reusing FUSE matters more than reusing its name: the protocol carries a distrust-oriented assumption into the design.

kSFS then changes the location of the implementation without discarding the relationship. Its file-system code runs inside the kernel, but it is still expected to behave as the handler on the far side of a FUSE-shaped interface. WebAssembly provides a separate execution domain for that handler. A capability-based WASI interface and related checks determine which resources it can access. The kSFS driver remains responsible for connecting the handler to Linux's VFS path.

The result is not a smaller version of the entire Linux kernel. It is a restricted path through the kernel for one class of component. That scope is what makes the claim plausible. The paper presents kSFS as a framework for sandboxed file systems, not as evidence that every Linux subsystem can be treated the same way.

This scope also prevents a common category mistake. The question is not whether Linux has become a microkernel in disguise; it is whether one carefully chosen interface can recover some of the microkernel's distrust model inside a monolithic system.