Making the Boundary Fast Enough to Use
kSFS's security boundary would be of limited practical value if every filesystem operation still paid the full cost of a user-space round trip. This chapter focuses on the engineering that makes the boundary usable: how kSFS avoids unnecessary copies, how it lets bulk I/O overlap while metadata remains ordered, and what the NTFS and exFAT ports reveal about compatibility. The important distinction is that in-kernel execution removes only one part of the cost; the data path and the filesystem's concurrency semantics still have to be redesigned carefully.
Why in-kernel calls are only half the speedup
Ordinary FUSE moves a request across a device-file interface to a user-space daemon. The daemon reads the request, performs filesystem work, and writes a response back. For a large read or write, data may also pass through an intermediate buffer that the user-space implementation can access. The boundary is doing useful security work, but every transition and copy consumes time and memory bandwidth.
kSFS changes the execution location by invoking FUSE handlers as WebAssembly functions in the kernel. That removes some mode and context switches, but the WebAssembly sandbox still cannot simply read arbitrary kernel memory. If the driver placed the request arguments in ordinary kernel memory and expected the module to follow pointers into them, it would have restored precisely the kind of shared-state authority the boundary is meant to avoid.
The first performance problem is therefore a security problem in disguise: how can a module process a large buffer without making the buffer an unchecked window into the host? kSFS uses a zero-copy buffer owned and prepared by the driver. The module receives an authorized way to ask the kernel to move data between that buffer and the disk, or to copy only the portion it needs into its own WebAssembly memory for further processing. Arguments are checked against the buffer and resource limits before the transfer occurs.
The distinction is important for both reads and writes. For a read, the driver can identify the pages that will receive data and let the sandboxed implementation request a transfer into that validated region. For a write, the implementation can request that data already in the zero-copy buffer be written to the authorized storage resource. If the format requires encryption, compression, or some other transformation, the module can copy data into its private memory when direct transfer is not appropriate. Zero-copy is therefore an available path under conditions, not permission to bypass the sandbox.
A useful way to see the trade-off is to compare two paths for the same read. The buffered path copies request data into the module's memory, lets the handler interpret it, copies results back to the kernel, and then completes the storage transfer. The optimized path still lets the handler decide what the filesystem operation means, but exposes a validated region for the bulk bytes and lets the driver perform the transfer directly. The second path removes copying of the large payload while preserving checking of the operation, range, and resource. Small control information may still cross the WebAssembly boundary; the optimization targets the data whose size would otherwise dominate the cost.