Scoped Indirect Execution (SIE)

• Scoped Indirect Execution (SIE) is a dynamic binary-patching technique that enables live, safe tuning of performance-critical Linux kernel constants without system reboots.
• It employs optimized Kprobes, symbolic execution, and deferred activation to precisely update constant-derived code regions with minimal performance overhead.
• SIE, underpinning the KernelX framework, has demonstrated significant performance benefits in disk I/O, softIRQ handling, and memory management across diverse workloads.

Scoped Indirect Execution (SIE) is a dynamic binary-patching technique that enables live, safe, and efficient tunability of constant values—termed performance-critical constants or "perf-consts"—in the deployed Linux kernel. By introducing virtualized tunable knobs at runtime without kernel rebuilds or reboots, SIE allows for millisecond-scale, side-effect-safe adaptation of low-level system assumptions to evolving hardware and workload conditions. SIE underpins KernelX, a programmable framework that exposes perf-const tunability to policies based on application and system metrics, all while providing stringent side-effect safety not available in previous kernel update mechanisms (Chen et al., 14 Dec 2025).

1. Definition and Objectives

SIE is defined as a system that, without modifying the kernel binary, intercepts execution at precisely specified instruction boundaries to apply synthesized state updates corresponding to a new value of a target perf-const. Its primary objectives are:

• Transparency: Kernel operation and user workloads remain unaffected by patching—no reboot or binary replacement is required.
• Safety: Patch activation is strictly delayed until no thread can observe partially-updated state, preventing in-flight effects of old constants from persisting.
• Efficiency: The computational cost per patched event is bounded to a few hundred cycles, suitable for workloads with frequent triggering.
• Programmability: Tunability is exposed via eBPF, enabling runtime policy composition based on arbitrary metrics or hints.

2. Core Mechanisms: Symbolic-State Recovery, Spanning, and Indirection

SIE centers on the identification and manipulation of critical spans (CS) and safe spans (SS) in the kernel binary:

• Symbolic-state recovery: Offline, SIE leverages symbolic execution to recover the mapping from perf-consts in source to immediate values (IV) in binary, and the update expression

$R/M \leftarrow f(R/M, IV)$

where $R/M$ denotes affected registers or memory slots. This symbolic treatment supports general transformations rather than naive pattern-matching of immediate constants.

• Critical spans (CS): Each perf-const uniquely determines one or more single-entry, single-exit instruction fragments where its value is loaded and first impacts architectural state.
• Safe spans (SS): Safe spans encapsulate all instructions—across possible call boundaries—transitively affected by the perf-const's value, forming the scope over which in-flight effects can propagate.
• Indirect patching: SIE relies on optimized Kprobes (preferably jump-based) to inject tiny, just-in-time-generated stubs at CS boundaries. These stubs emulate an execution as though the kernel had been originally built with the new constant, adjusting only the specific $R/M$ locations.
• Deferred activation: Activation of new stubs is strictly deferred until all threads have exited every SS associated with the old value. Stack inspection and reference counting are used to track thread positions, converting temporal ordering constraints to spatial checks.

3. Lifecycle: From Source Constant to Runtime Indirection

The SIE workflow is divided into offline and runtime phases:

Offline phase (per build and constant):

• Selection: Perf-const $V$ is specified by location metadata.
• Dual builds: The kernel is compiled twice, with $V'$ and $V''$ as distinct values, to reveal code locations influenced by $V$.
• Binary diffing: These builds are diffed to extract "seed" instructions whose immediates change.
• Symbolic execution: Forward and backward symbolic execution recovers expressions

$R/M = g(R/M, IV),\quad IV = a \cdot V + b$

• CS/SS construction: Each CS is marked as a precise address range for the update; SSes are formed through interprocedural forward data-flow slicing.
• Stub synthesis: Update stubs are generated for each CS according to $g$ and the transform on $R/M$.

Runtime phase (per value change):

• An eBPF "X-tune" policy invokes x_set(new_value) and monitors transition completion.
• For each update, Kprobes are enabled at CS (indirection trigger) and SS (safety tracking) boundaries.
• As threads exit SSes, a global reference count is decremented. When zero, new indirections are atomically enabled and legacy indirections are disabled, ensuring the side-effect safety invariant.

4. Formal Safety Semantics: Beyond Version Atomicity

SIE extends beyond traditional version atomicity—which merely precludes a thread from interleaving "old" and "new" code fragments—by enforcing side-effect safety. The critical safety invariant is:

• A transition from $V$ to $V'$ is only permitted when

$\forall t,\; \mathtt{PC}(t) \notin \bigcup SS$

that is, no thread's program counter is located in any of the SSes for the old value.

This guarantees that no in-flight data derived from the old constant remains, allowing the effect of enabling new indirections to be semantically equivalent to having compiled $V'$ originally:

$$\forall \sigma_{in},\;\; \mathsf{Exec}(\sigma_{in},\,CS_V \circ I)\;\equiv\; \mathsf{Exec}(\sigma_{in},\,CS_{V'})$$

This property provides compositional and system-wide safety that prevents stale side-effects from leaking across function boundaries.

5. Implementation Details and Algorithmic Structure

The implemented algorithm proceeds as follows:

• Offline:
  • Compile kernel with two variant constants.
  • Diff binaries for seed instructions.
  • Symbolically recover update expressions and spans.
  • Generate and store indirection stubs.
• Runtime:
  • Load policy code, linking to scope table entries for each perf-const.
  • On value update:
  • Install Kprobes at all relevant CS/SS addresses.
  • Wait for all threads to exit SSes via per-thread or global reference counting.
  • Enable new indirections and remove SS probes.
  • Each CS Kprobe handler invokes the appropriate stub, adjusting $R/M$ as if the kernel had been compiled with the requested value.

A high-level summary is provided in the table below.

Phase	Step	Purpose
Offline	Dual compile/diff	Localize constant impact to instructions
	Symbolic execution	Derive $g,\,a,b$ transforming source value to binary
	CS/SS construction	Define affected code/data-flow regions
	Stub synthesis	Generate safe state-update logic for runtime
Runtime	Policy load	Expose tunable interface via eBPF
	Probe installation	Trigger indirections and safety accounting
	Reference counting	Detect global SS quiescence for safe transition

6. Performance Properties

SIE is engineered for both low steady-state and transition overhead:

• Steady-state probe cost: Jump-optimized Kprobes induce ≈ 243 cycles per trigger; INT3-based probes cost ≈ 1,858 cycles. Stub execution requires approximately 20 cycles for arithmetic.
• Scalability: In a null-device io_uring benchmark with up to 10 Mops/s, SIE incurs 15% latency overhead for minimal per-op work, reducing to 2% when each operation includes 10 μs of compute. Overhead increases linearly with probe trigger rate.
• Policy-update latency: Installing/removing all probes for one perf-const requires 1–500 ms, dependent on protection breadth (number of SS entries).
• Transition completion: Side-effect-safe transitions (global, all threads) complete in under 150 ms for systems with up to 16 threads and deep call stacks. Per-thread CS transitions occur in less than 50 ms median, versus 2.8 s for function-scope live patching (e.g., Kernel Livepatch/KLP).
• Offline analyis cost: ≈ 7 min for binary compile, ≈ 11 ± 20 min for thin slicing (SS construction) per constant.

7. Applications and Empirical Results

SIE has enabled previously unattainable, safe, in-place tunability across a range of kernel subsystems. Representative case studies include:

• Block plug size ($BLK\_MAX\_REQUEST\_COUNT$): Raising from 32 to 128 for HDDs yielded a 54× increase in write throughput; reducing to 1 on NVMe with direct I/O offered 1.2× improvement in RocksDB throughput and latency reduction.
• SoftIRQ restart count: Lowering from 10 to 1 in mixed-latency workloads facilitated a controlled trade-off between 52% CPU utilization and 560 μs max tail latency, enabling dynamic SLO selection.
• Shrinker batch size: Reducing from 128 to 16 in zswap shrinkers for working-set patterns achieved a 4× reduction in latency by minimizing unnecessary work.
• NUMA page-migration batch: Changing from 512 to 64 halved tail latency in computation–migration mixed scenarios, with a modest TLB shootdown penalty.
• TCP Cubic HyStart constants: Adapting delay-thresholds dynamically per-flow based on RTT reduced P99.99 NGINX flow completion time by 81% for high-RTT flows, preserving performance for short-RTT traffic.

In all instances, SIE enabled exploration of optimal performance regimes for constants that were previously fixed in shipped kernels, providing system operators with new dimensions for adaptive resource management and workload tuning (Chen et al., 14 Dec 2025).