Lightweight Fault Isolation (LFI)

• Lightweight Fault Isolation is a low-overhead mechanism that confines untrusted native code within a designated sandbox, ensuring controlled memory access through software fault isolation.
• The methodology leverages reserved-base addressing, instruction whitelisting, and redzones to enforce isolation, achieving significant performance benefits over traditional process or container boundaries.
• Practical implementations in ARM64 systems, Faasm, and Femto-Containers demonstrate optimized transition costs, verified safety properties, and resource-efficient execution in diverse computing environments.

Searching arXiv for papers on Lightweight Fault Isolation and closely related SFI work. Searching arXiv for Faasm and Femto-Containers as LFI-style systems. Lightweight Fault Isolation (LFI) denotes a class of low-overhead isolation mechanisms that confine untrusted computation without incurring the full cost of process, container, or virtual-machine boundaries. In its most specific recent usage, LFI is a software fault isolation (SFI) system for ARM64 that runs untrusted native machine code in the same address space as trusted host code while constraining it to a designated sandbox region (Sotoudeh et al., 21 Aug 2025). In a broader systems sense, the term also describes designs that preserve controlled memory access, trusted host mediation, and low startup and footprint costs inside a shared runtime or process, as exemplified by WebAssembly-based serverless execution and microcontroller-scale bytecode runtimes (Shillaker et al., 2020, Zandberg et al., 2022).

1. Historical placement and conceptual scope

LFI belongs to the broader tradition of software fault isolation. In that tradition, untrusted code is restricted to a subset of machine operations or an explicitly sandboxed execution model so that it cannot successfully access memory outside an assigned region. The ARM64 LFI system studied in recent formal-verification work is described as a recent SFI system whose guest code is compiled to ARM64, checked by a verifier before execution, and, if accepted, guaranteed to stay within a dedicated 4 GiB sandbox region for memory accesses (Sotoudeh et al., 21 Aug 2025).

This design point differs from traditional process and container isolation. The stated motivation is low-overhead native-code sandboxing: compared with separate processes, it avoids expensive context switches; compared with memory-safe bytecode or language runtimes, it avoids dependence on a large interpreter, JIT, or runtime as part of the trusted base and can run at near-native speed (Sotoudeh et al., 21 Aug 2025). The same general rationale appears in later systems work that treats lightweight isolation as a way to co-locate untrusted components efficiently, whether those components are serverless functions, browser libraries, or embedded software functions (Kolosick et al., 2021, Zandberg et al., 2022).

A recurring theme across the literature is that memory isolation alone is not the whole problem. Several systems explicitly combine cheap fault containment for memory with additional discipline for control flow, stack use, CPU and network isolation, or host-call mediation. This suggests that LFI is best understood not as a single mechanism, but as a design family centered on software-enforced boundaries, narrow trusted interfaces, and reduced transition and startup costs.

2. Native-code LFI on ARM64

The ARM64 LFI mechanism is built around a reserved-base addressing discipline. Each guest program is assigned a 4 GiB sandbox region. Register x21 holds the sandbox base address and is assumed to be 4 GiB aligned, so its lower 32 bits are zero. Register x18 is the addressing register used for ordinary loads and stores. The key whitelisted address-forming instruction is:

$$\mathtt{PC} \in [\mathtt{x21},\ \mathtt{x21}+4\mathtt{GiB}).$$7

This combines the upper 32 bits of x21 with the lower 32 bits of xN, so x18 becomes the sandbox base plus a 32-bit offset. Unsafe memory references such as

$$\mathtt{PC} \in [\mathtt{x21},\ \mathtt{x21}+4\mathtt{GiB}).$$8

are rewritten to

$$\mathtt{PC} \in [\mathtt{x21},\ \mathtt{x21}+4\mathtt{GiB}).$$9

so that dereferences remain within the sandbox region (Sotoudeh et al., 21 Aug 2025).

The verifier enforces three central restrictions. First, x21 is never written. Second, x18 can only be written by approved address-forming instructions. Third, memory loads and stores use x18 as the address register, except for special handling of stack-pointer-relative accesses. Stack handling requires additional runtime support because ARM64 writeback loads and stores can move sp outside the sandbox. LFI therefore relies on redzones: in sparse LFI, the 4 GiB region before and after the sandbox is unmapped, so accesses that move just outside the sandbox trap instead of reaching host memory (Sotoudeh et al., 21 Aug 2025).

The verified invariant for sparse LFI is stated over x21, x18, sp, PC, and R_{30}. In particular,

$$\mathtt{x18}, \mathtt{sp} \in [\mathtt{x21}-128\mathtt{MiB},\ \mathtt{x21}+4\mathtt{GiB}+128\mathtt{MiB})$$

and

$$\mathtt{PC} \in [\mathtt{x21},\ \mathtt{x21}+4\mathtt{GiB}).$$

R_{30} must either point into the sandbox or equal one of three special runtime call addresses. Dense mode replaces the $\pm 128$ MiB bounds for x18 and sp with $\pm 8$ KiB (Sotoudeh et al., 21 Aug 2025).

A notable architectural distinction is that this LFI verifier is effectively stateless: the verifier is “nothing more than an instruction whitelist,” and the guest may contain any whitelisted instruction in any order. This contrasts with earlier SFI designs that verified specific instruction sequences, alignment constraints, or multi-instruction control-flow patterns. The statelessness is central to exhaustive automation, because the proof obligation reduces to showing that each whitelisted instruction preserves the sandboxing invariant or terminates (Sotoudeh et al., 21 Aug 2025).

3. Transition costs and zero-cost crossings

A separate but closely related line of work argues that lightweight isolation is incomplete if it optimizes memory checks but leaves inter-domain transitions heavyweight. “Isolation Without Taxation: Near Zero Cost Transitions for SFI” studies when secure domain transitions can be implemented as simple function calls and returns rather than springboards and trampolines that save, scrub, and restore machine state (Kolosick et al., 2021).

The paper identifies five zero-cost conditions: callee-save register restoration, well-bracketed control flow, type-directed forward-edge CFI, local state encapsulation, and confidentiality via initialization-before-use. These are enforced in a refined semantics, oSFIasm, whose monitor tracks function structure and logical call-stack metadata. The resulting theorems establish callee-save register integrity, return-address integrity, and a confidentiality property framed as disjoint noninterference (Kolosick et al., 2021).

The main implication is that ordinary calls and returns can serve as secure domain crossings only when the sandboxed code itself satisfies a sufficiently strong structural discipline. In the Wasm/Lucet instantiation, the argument is that WebAssembly’s static type system, structured control flow, typed calls, initialized locals, and frame-local stack access already enforce more discipline than the zero-cost conditions require. To reduce trust in the compiler, the paper introduces VeriZero, a static binary verifier that checks whether Lucet-produced binaries satisfy those conditions (Kolosick et al., 2021).

The reported measurements make the transition-tax argument concrete. For the Wasm-based system, the paper gives direct-call costs of 120 ns for WasmHeavy and 7 ns for WasmZero, with indirect and callback costs close to the native indirect-call baseline. It reports that zero-cost transitions speed up image and font rendering in Firefox by up to 29.7% and 10% respectively (Kolosick et al., 2021). A plausible implication is that, in many LFI designs, the dominant residual overhead may come from boundary crossings rather than from the core memory-isolation mechanism.

4. Shared-process and embedded realizations

LFI-style design appears in systems that do not use the exact term but implement its central ideas. Faasm introduces Faaslets, a lightweight isolation abstraction for stateful serverless computing. Faaslets isolate memory using software-fault isolation via WebAssembly while allowing explicitly shared memory regions between functions in the same address space. Other resources are isolated using Linux cgroups, network namespaces, virtual interfaces, iptables, and traffic shaping, while host interactions are exposed through a narrow, trusted POSIX-like interface (Shillaker et al., 2020).

Faasm’s execution model is explicitly same-address-space: multiple Faaslets run as threads in one shared runtime process, and each function’s memory is mapped as a disjoint WebAssembly linear memory region except for intentionally shared pages. Shared regions are implemented with mmap and MAP_SHARED, private memory with MAP_ANONYMOUS, and remapping with mremap. Cold-start reduction is further improved by Proto-Faaslets, snapshots of already initialized execution state restored with copy-on-write memory mapping (Shillaker et al., 2020).

The paper reports large gains against a Knative container baseline. For machine learning training, Faasm achieves a 2x speed-up with 10x less memory in the abstract; the detailed evaluation reports runtime improvement of up to 60% at 15 parallel functions, billable-memory reductions of about 90%, and scaling to 38 parallel functions while Knative exhausts memory beyond about 30. For ML inference, Faasm doubles throughput, reduces tail latency by 90%, and adds less than 1 ms latency on cold starts. For no-op isolation overheads, Docker init is 2.8 s, Faaslet init 5.2 ms, and Proto-Faaslet restore 0.5 ms (Shillaker et al., 2020).

At the opposite end of the resource spectrum, Femto-Containers provide lightweight virtualization and fault isolation for small software functions on low-power IoT microcontrollers. The system is integrated into RIOT OS, executes eBPF-compatible bytecode in a computed-jumptable interpreter, and targets devices without MMU, MPU, or hardware security extensions. By default, each instance has access only to VM-specific registers and a fixed 512 byte stack; additional memory is granted only through explicit allow lists, and every computed memory access is checked at runtime against those lists. Illegal access aborts execution (Zandberg et al., 2022).

Femto-Containers combine pre-flight validation, runtime memory checks, restricted native-call access to RIOT services, and bounded execution by limiting the total number of instructions $N_i$ and the number of branches $N_b$, yielding a total bound of $N_i \times N_b$. The paper reports very small footprints: 2992 B ROM and 624 B RAM for Femto-Containers, 1378 B ROM and 672 B RAM for the verified core CertFC, and approximately 624 bytes of RAM per additional instance. The hook overhead is reported as about 100 clock ticks, and the authors estimate a density of about 100 instances on an Arm Cortex-M4 microcontroller with 256 KiB RAM for larger applications of about 2000 byte (Zandberg et al., 2022).

5. Formal verification and trusted computing bases

Verifier correctness is the security boundary in native-code LFI. “Automated Formal Verification of a Software Fault Isolation System” formally verifies that, under LFI’s runtime memory-mapping assumptions, any ARM64 program accepted by the LFI verifier cannot successfully read from or write to memory outside its designated sandbox region (Sotoudeh et al., 21 Aug 2025). The proof is instruction-local and automated: it enumerates all $2^{32}$ ARM64 encodings, filters those accepted by the whitelist, partially evaluates each instruction with the ARM ASL semantics and ASLP, symbolically executes the result, and discharges proof obligations with SMT-LIB2 and Yices2. Verification of sparse and dense LFI each took about 20 hours on a 160-core Ampere Altra ARM64 machine (Sotoudeh et al., 21 Aug 2025).

The central one-step property can be rendered as

$$I(s) \land \text{WL}(i) \;\Longrightarrow\; \text{NoBadSideEffect}(s,i) \land \bigl(\text{Terminates}(s,i) \lor I(\text{step}(s,i))\bigr),$$

where NoBadSideEffect means that no successful out-of-sandbox read, write, or execute occurs. The proof is careful to reason about successful accesses rather than all attempted accesses: attempted accesses into unmapped guard regions are permitted if they trap (Sotoudeh et al., 21 Aug 2025).

Femto-Containers present a different verification style. The paper states that the critical components are the rBPF interpreter and the pre-flight instruction checker, and that the resulting verified runtime, CertFC, guarantees fault isolation shielding RIOT from logic loaded and executed in a Femto-Container. The proof workflow uses Coq, the CompCert C memory model, CompCert Clight, VST-clightgen, and the $\partial x$ extraction tool. The paper highlights the theorem

$\pm 128$0

and explains it as a software fault isolation property for the CertFC state, with fuel enforcing finite execution (Zandberg et al., 2022).

Across these systems, the trusted computing base remains a recurring limitation. The ARM64 proof assumes correct runtime memory mappings, correct runtime call handling, and a correct compiler rewriter. Faasm explicitly trusts the WebAssembly validator and runtime, the JIT and linking machinery, and the host-side implementation. Femto-Containers verify the interpreter and checker core, but not the full RIOT host, hook infrastructure, or deployment stack (Sotoudeh et al., 21 Aug 2025, Shillaker et al., 2020, Zandberg et al., 2022).

6. Broader uses of the term and neighboring literatures

Although “Lightweight Fault Isolation” is most precise in the ARM64 SFI setting, later work uses the phrase “LFI-style” more broadly for software-only, low-overhead diagnosis and containment. BitFlipScope is described as a practical LFI-style framework for bit-flip-corrupted LLMs. In the differential setting, it localizes faults hierarchically from transformer block to sublayer to tensor and bit using hidden-state divergence, activation fingerprinting, and hash-guided comparison; in the self-referential setting, it uses residual-path perturbation and loss-sensitivity profiling with

$$\mathtt{PC} \in [\mathtt{x21},\ \mathtt{x21}+4\mathtt{GiB}).$$0

and

$$\mathtt{PC} \in [\mathtt{x21},\ \mathtt{x21}+4\mathtt{GiB}).$$1

The paper presents this as lightweight because it avoids retraining, avoids exhaustive parameter scans, and supports targeted recovery either by tensor replacement or by attenuation of a localized faulty block (Karamat et al., 18 Dec 2025).

The acronym LFI also has an unrelated, established meaning in hardware security: laser fault injection. “TRANSPOSE: Transitional Approaches for Spatially-Aware LFI Resilient FSM Encoding” uses LFI in that sense and develops a CAD framework for finite-state machines under precise laser-induced bit-flip, bit-set, and bit-reset models. Its target condition is

$$\mathtt{PC} \in [\mathtt{x21},\ \mathtt{x21}+4\mathtt{GiB}).$$2

equivalently zero spatial transitional vulnerability, and its evaluation reports that all TRANSPOSE variants achieve either $$\mathtt{PC} \in [\mathtt{x21},\ \mathtt{x21}+4\mathtt{GiB}).$$3 or $$\mathtt{PC} \in [\mathtt{x21},\ \mathtt{x21}+4\mathtt{GiB}).$$4 across five benchmarks and several attacker capabilities (Choudhury et al., 2024). This literature is about hardware fault attacks rather than software sandboxing, but the acronym collision is substantial.

A further neighboring literature concerns fault detection and isolation in control systems rather than software sandboxing. “Guaranteed Fault Detection and Isolation for Switched Affine Models” develops a set-membership, optimization-based framework for switched affine systems, with model invalidation, $$\mathtt{PC} \in [\mathtt{x21},\ \mathtt{x21}+4\mathtt{GiB}).$$5-distinguishability, and $$\mathtt{PC} \in [\mathtt{x21},\ \mathtt{x21}+4\mathtt{GiB}).$$6-isolability. The paper’s online architecture uses bounded receding horizons and offline precomputation, but its central primitive is still a mixed-integer feasibility problem rather than a sandboxing mechanism (Harirchi et al., 2017).

These neighboring uses show that the phrase “fault isolation” spans multiple technical communities. In computer systems, LFI usually denotes low-overhead software confinement of untrusted computation. In hardware security, the same acronym frequently denotes laser fault injection. In control theory, fault isolation usually denotes diagnosis and identification of faults in dynamical models. Careful contextualization is therefore necessary when interpreting the term in recent literature.