Inside kSFS: WebAssembly, WASI, and Kernel-Space Containment

The checkpoint's five tests become concrete in kSFS's runtime and driver. This chapter follows one filesystem from compilation to an authorized instance, then follows a faulty operation through memory protection, exception handling, liveness control, and resource checks. The goal is to see exactly which parts of the system contain an untrusted implementation—and which parts remain trusted or outside the claim.

From source code to a mounted instance

A kSFS filesystem begins as ordinary filesystem code that uses a FUSE-compatible interface. The developer compiles that code into a WebAssembly module with kSFS's modified support library. The module is then compiled ahead of time into native code suitable for execution inside the kernel. This workflow is important because it preserves a familiar programming model without giving the resulting code the unrestricted interface of a conventional Linux filesystem module.

The module does not simply appear in the kernel and start running. kSFS adds a system-call path through which an authorized user can load and instantiate a module. Loading produces an identifier for the module; instantiation creates an instance that can later be mounted or stopped. At creation time, the user can provide arguments, environment values, file descriptors, and the directories the instance is allowed to open. The kSFS driver then connects the instantiated filesystem to Linux's VFS-facing path.

The division of responsibility looks like this:

flowchart LR S["FUSE-compatible filesystem source"] --> C["WebAssembly compiler and modified libfuse"] C --> A["AOT-compiled module"] A --> L["Authorized filesystem instance"] L --> R["In-kernel WebAssembly runtime"] R --> D["kSFS driver"] D --> V["Linux VFS"] L -->|capability checked| B["Authorized block device or directories"] R -->|fault or forced stop| X["Terminate instance and return error"]

The diagram contains two paths that should not be confused. The vertical path is the normal service path: the module is admitted, the runtime executes it, the driver connects its FUSE operations to VFS, and the filesystem reaches only the resources authorized at instantiation. The side path is the containment path: a memory fault, stack failure, or forced stop should terminate the instance and return control to trusted code rather than turn into a kernel crash.

The system model is deliberately asymmetric. The filesystem implementation is untrusted and may contain arbitrary memory accesses, stack overflows, or control-flow hijacking attempts. The WebAssembly runtime and kSFS driver are trusted. The ahead-of-time compiler and the generated native code are also trusted under the paper's assumptions. That means kSFS reduces the amount of filesystem-specific code that belongs inside the trusted kernel, but it does not remove the shared trusted machinery that enforces the boundary.

The driver also preserves the shape of FUSE operations while changing how they are delivered. Ordinary FUSE uses a device-file exchange with a user-space daemon. kSFS invokes the corresponding handlers through WebAssembly function calls.