How can the restructuring of specific Linux kernel components from C to Rust effectively mitigate memory security vulnerabilities?
2025-2A-T20-G95
Guilherme Novaes Lima, Tomaz Mikio Sasaki
The research investigates restructuring specific Linux kernel components from C to Rust to mitigate memory security vulnerabilities. The project selected the r8169 network driver (Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller) as the target component for this proof-of-concept (POC) implementation.
Duration: August 4-15, 2025
The initial sprint established the foundational framework for the research. Key deliverables included preparing the Technical Approach and Project Implementation (TAPI) form and defining the project's macro scope. The scope formalized the research question: "How can the restructuring of specific Linux kernel components from C to Rust effectively mitigate memory security vulnerabilities?"
The project scope was defined to focus on a single, limited Linux kernel component with criteria including functional relevance, known memory security vulnerabilities in the C implementation, and manageable complexity for migration within available resources.
Duration: August 18-29, 2025
This sprint focused on comprehensive research and component selection. The team produced three critical research reports: definition and description of the analyzed component, research on Linux driver development, and research on software engineering using Rust.
The r8169 driver was selected based on its widespread use in consumer hardware, well-documented codebase, and known memory management patterns typical of network drivers that could benefit from Rust's safety guarantees. Network drivers represent a particularly vulnerable attack surface due to their exposure to untrusted network inputs.
Duration: September 1-12, 2025
The third sprint delivered substantial theoretical groundwork. Major deliverables included a complete literature review on memory security in C and Rust within the kernel context, detailed analysis of the involved hardware and firmware developed in C, and definition of the restructuring methodology.
The methodology documentation detailed strategies for gradual and secure migration, including tools and techniques such as static analysis with Clippy for Rust, dynamic analysis capabilities, and interoperability approaches between C and Rust modules within the kernel environment.
Duration: September 15-26, 2025
Implementation began with architectural planning and environment setup. The sprint produced Rust design proposal documentation detailing the component's architecture and design, including interfaces for interoperability with C.
The development environment construction involved physical components and virtualization infrastructure, establishing the necessary toolchain including the Rust compiler (rustc), Cargo package manager, and kernel compilation tools such as GCC, Clang, and Make. This setup enabled compilation of Rust modules within the Linux kernel build system, a critical technical milestone.
Duration: September 29 - October 10, 2025
The fifth sprint transitioned from planning to active code development. Key deliverables included construction of basic component modules in Rust and elaboration of initial tests.
The r8169_rs repository contains the initial Rust implementation of core driver functionality. The linuxdrivers repository provides the development environment framework supporting the implementation process. Initial modules implemented fundamental driver operations while maintaining compatibility with the existing kernel infrastructure through carefully designed Foreign Function Interface (FFI) bindings.
Duration: October 13-24, 2025
Efforts focused on extracting and reimplementing security-critical subsystems in Rust. Particular attention was given to the firmware handling logic in the original C driver—a complex and historically vulnerable section involving binary blob parsing, checksum validation, and register programming.
A major refactoring resulted in a modular Rust firmware subsystem featuring safe parsing through bounds-checked operations, explicit error handling, and macro-generated enums for opcodes and chip versions. New source files (firmware.rs, macros.rs) were introduced, eliminating scattered hardcoded data from the prior monolithic structure.
Patterns derived from the public rustsp_oct25_demos repository were adopted to ensure idiomatic and safe Rust kernel code, including minimized unsafe blocks and robust casting helpers. The sprint concluded with successful compilation of a hybrid module integrating the new Rust firmware components with the unmodified C driver core.
Duration: October 27 - November 7, 2025
The firmware handling logic was fully decoupled into an independent, reusable Rust crate named r8169_firmware. All related functionality was migrated to a dedicated directory structure.
The module was redesigned to expose a stable C-callable ABI through a custom procedural macro (define_rtl_c_fn!) that generated #[no_mangle] extern "C" wrappers. Closure-based designs were replaced with function-pointer callbacks for complete FFI compatibility, while explicit resource management using Option<T> and dedicated release functions ensured correctness in no-alloc kernel contexts.
Build verification demonstrated seamless integration: the modified original r8169.c successfully linked against the Rust firmware module, yielding a functional hybrid r8169.ko with all required rtl_fw_* symbols correctly exported on x86_64 and aarch64 architectures.
Duration: November 10-21, 2025
Further refinement of the Rust firmware subsystem emphasized enhanced safety and maintainability. Improvements included stricter bounds checking based on parsed action sizes, consistent error propagation using POSIX codes, and device-aware logging via kernel macros.
The primary driver codebase was streamlined by removing redundant firmware logic from the C portion, resulting in a more focused core responsible solely for PCI probing, interrupt management, and MAC/PHY operations. Independent compilation of the firmware crate was validated, facilitating parallel development.
Duration: November 24 - December 5, 2025
Functional validation of the refactored hybrid driver was prioritized. Extensive QEMU-based testing in a minimal Debian environment successfully exercised the complete firmware request → parse → write sequence within the Rust subsystem.
Detailed dmesg traces verified proper header validation, checksum computation, and action iteration through FFI callbacks.
Initial bare-metal deployment attempts revealed environment-specific challenges but provided indirect confirmation of build integrity. The Rust firmware module introduced no additional instability while delivering measurable improvements in memory safety compared to the original C implementation.
Duration: December 8-19, 2025
Enhanced tracing mechanisms have been implemented to capture Rust firmware execution paths upon successful probing. Planning advances for porting the r8169_firmware module to the related r8169 driver, demonstrating cross-family reusability.
Duration: February 9-20, 2026
r8169 hybrid bare-metal probe-time panics persisted despite workarounds (r8169.aspm=0, pcie_aspm=off). Activated Plan B per contingency milestone: pivoted to upstream nullblk.c vs rnull.rs comparison, eliminating hardware variables.
Archived r8169 firmware crate as integration case study. Built parallel Linux 6.18.y kernels (Kernel A: CONFIG_NULL_BLK=y; Kernel B: CONFIG_RUST=y, CONFIG_RNULL=m) with KASAN.
Duration: February 23 - March 6, 2026
Verified both kernels boot cleanly on QEMU/bare-metal. modprobe nullblk/rnull created /dev/nullb* devices correctly. Static analysis: nullblk.c (1,450 LoC, 41% safety fixes historically); rnull.rs (1,100-1,300 LoC, 0 unsafe in core).
Initial fio smoke tests (4k bs, QD=8) comparable IOPS. Generated CSV metrics (LoC, unsafe density).
Duration: March 9-20, 2026
Executed fio matrix (216 configs, 50 runs/driver): rnull 25-30% IOPS deficit vs nullblk (peaks 4k randrw, shrinks 1M seq). Queue-depth invariant (falsifies H3). Tail latencies nullblk p95/99 lower by 3-15μs.
KASAN stress (200 device cycles + fio) clean. Automated QEMU tooling with idempotent testing.
Duration: March 6-19, 2026
Hardened test env for syzkaller: SSH-dropbear (replaces telnet), guest networking (10.0.2.15/24), BusyBox PKGBUILD, syzkaller Docker build. Hypothesis status: H2/H3 falsified (25-30% overhead constant); H1 pending.
Sprint slippage: infrastructure focus deferred fuzzing/static analysis.
Duration: March 20 - April 10, 2026
Executed syzkaller campaigns: no block-driver bugs (crashes scheduler/RPC noise only)—H1 inconclusive. Synthesized: Rust imposes 25% perf cost, no observed dynamic safety gain in mature drivers.
Next: extend fuzzing (48-72h), static/commit mining.
Duration: April 13-24, 2026
Completed the deferred static and commit-history analysis. The null_blk.c commit log (2020–2025) was mined and CWE-classified: 69 of 106 commits carry a safety signal (65%), mapped against the ACSAC R4L taxonomy (auto-eliminated / needs-discipline / language-unaffected). rnull.rs confirmed zero unsafe blocks in core driver logic, with all unsafe confined to C API wrappers.
The evidence-gated pipeline was designed: a three-gate framework (safety, fuzzing, performance) plus a Phase 1 candidate screening step that scores drivers across four lenses (historical risk, static unsafe surface, dynamic robustness, tractability). Pipeline scripts were written and integrated with the nullb automation toolchain, decoupling performance preparation from benchmark execution.
Duration: April 27 - May 8, 2026
Executed ten 24-hour syzkaller campaigns per driver with crash attribution filtering to isolate target-attributable failures from SSH/RPC harness noise. Result: Mann-Whitney U p=0.37, Vargha-Delaney A₁₂=0.45—no block-driver regression attributable to rnull (fuzzing gate passes under do-no-harm framing). Monte Carlo power simulation added to verify that the campaign length was adequate for detecting large effects.
Final performance results locked: all 18 matched fio cells regress for rnull (median −14.4%, worst −25.5%), with every cell surviving Holm correction. The paper plan was drafted, establishing the research contribution as the pipeline structure rather than a simple pass/fail verdict on rnull.
Duration: May 11-22, 2026
Synthesized the full evidence profile for the null_blk/rnull pair: safety gate did not pass (elimination rate 18.18% < 34.2% threshold, driven by CWE-362-family races and logic errors outside Rust's scope); fuzzing gate passed; performance gate did not pass. The three-gate disagreement was framed as the primary scientific contribution—the signal an R4L upstreaming discussion should want.
Drafted the research paper targeting an academic venue. Figures generated reproducibly from canonical result artifacts; numeric claims verified by automated script.
Duration: May 25 - June 5, 2026
Iterated through final paper revisions: double-blind anonymization, rewording toward storage-systems framing, RFC-status clarification for rnull, and PDF metadata stripping. All five pages of the camera-ready submission verified against the formatting checklist.
Research paper finalized. The pipeline, result artifacts (safety.json, fuzz_stats.json, perf_stats.json, verdict.json, perf.csv, fuzz.csv), and reproducible build environment (Nix flake + LaTeX Makefile) constitute the final research deliverable.
Duration: June 8-19, 2026
Final academic deliverables and project retrospective.