Memory safety
Memory-safe Rust replacements for widely deployed C libraries, drop-in at the C ABI, and the tooling to verify safety-critical Rust to the coverage standards auditors expect.
What we replace and why
A large share of serious vulnerabilities in C libraries are memory-safety bugs: out-of-bounds reads and writes, use-after-free, null dereferences, integer overflows feeding allocations. Rust removes that class by construction, but rewriting every consumer is not realistic. So we build clean-room Rust implementations that export the original library’s C ABI, and existing binaries link against them without source changes.
Projects
Replaces cJSON · MIT
A clean-room Rust JSON parser with a drop-in libcjson C ABI. Existing C and C++ consumers relink and keep working.
cJSON.h functions implementedforbid(unsafe_code) core; Miri-clean FFI shimReplaces libexpat · MIT
A clean-room XML 1.0 parser built from the W3C specification, aiming for libexpat’s conformance without its memory-safety bugs. libexpat sits under CPython, Apache httpd, D-Bus and fontconfig.
MC/DC coverage for Rust · Apache-2.0
An open-source MC/DC engine for Rust. It recovers decisions from compiler MIR and reports which conditions the test suite independently exercises, under masking MC/DC.
cargo install cargo-floyd, then cargo floyd testOther C libraries by request. If a C dependency sits on your attack surface and you would rather replace it than keep patching it, tell us which one.
Verification
Rewriting in Rust removes a class of bugs. It does not prove the new code behaves. Safety-critical standards ask for evidence that every condition in every decision has been shown to affect the outcome on its own: modified condition/decision coverage.
MC/DC is the structural coverage criterion for ISO 26262 ASIL D in automotive and DO-178C Level A in avionics. Rust has lacked an open tool for it. Floyd is that tool: open source for adoption, with a commercial qualification offering built on top for teams that need tool-qualification evidence.
$ cargo floyd test Tests discovered: 4 Conditions: channel_a_ok, channel_b_ok, master_enable Per-condition MC/DC status: ✓ master_enable: EXERCISED ✓ channel_a_ok: EXERCISED ✓ channel_b_ok: EXERCISED MC/DC coverage: 3 of 3 conditions exercised (100%)
How an engagement works
Map the C dependency, its consumers and its CVE history. Decide whether a drop-in replacement, a safe wrapper or a staged rewrite is the right call. Sometimes the answer is to leave it.
Clean-room Rust implementation behind the existing C ABI, so consumers relink rather than rewrite. Unsafe code confined to a thin, audited FFI layer.
Upstream test suites, specification conformance suites, differential fuzzing against the original, Miri on the FFI boundary, and MC/DC coverage with Floyd where the standard requires it.
Your team owns the code, the tests and the evidence. Documentation written for the engineers who maintain it and the assessors who audit it.
Tell us what it is and where it runs. We will tell you whether replacing it is worth it.
Start a conversation