DEV Community: Rabah Laouadi

Why I Open-Sourced Only Layer Zero

Rabah Laouadi — Mon, 01 Jun 2026 05:02:57 +0000

Why I Open-Sourced Only Layer Zero

For the past months I’ve been building a deterministic infrastructure foundation in Rust.

Today I decided to publicly expose only the lowest layer of that system:

"sovereign-kernel"

This layer is intentionally minimal and highly constrained.

Its purpose is not “features”.
Its purpose is correctness.

The kernel focuses on:

"no_std"
zero allocation
deterministic serialization
ABI-stable primitives
invariant-enforced types
side-effect free behavior
fuzz-tested binary contracts

Why Layer Zero?

In most systems, instability begins at the foundation.

If primitive types become ambiguous:

serialization breaks
protocols drift
invariants leak
behavior diverges across platforms

So instead of starting from services or APIs,
I started from the lowest deterministic layer possible.

The goal was simple:

«Build primitives that remain predictable years later.»

Fuzzing the Kernel

One of the recent fuzzing sessions exposed a failure in chained XOR behavior inside a binary primitive.

The issue appeared during invariant stress validation.

The failing sequence:

let mut acc_even = h;

for _ in 0..8 {
acc_even = acc_even ^ h;
}

assert!(acc_even.ct_eq(&FixedHash::ZERO));

The fuzz target successfully detected an invariant violation during repeated mutation cycles.

After isolating the issue, the primitive behavior was corrected and the invariant contract stabilized.

This is exactly why fuzzing exists:
not just to crash software,
but to pressure-test assumptions.

Design Constraints

The kernel intentionally avoids:

heap allocation
runtime randomness
hidden state
implicit normalization
unsafe code
platform-dependent behavior

Every primitive is designed as a deterministic value object.

Why Publicly Release This?

Only Layer Zero is public for now.

The higher layers remain isolated until they mature further.

I wanted the public part to be the foundation:
the contracts,
the invariants,
the deterministic core.

Because infrastructure quality starts long before APIs.

GitHub:
https://github.com/Rust-Codes-Hub/kernel_layer_zero

14.8 Billion Fuzz

Rabah Laouadi — Mon, 01 Jun 2026 01:18:12 +0000

How 14.8 Billion Fuzz
Executions Exposed an XOR Invariant Trap in a Rust Kernel Primitive

For the past weeks, I’ve been building and stress-testing a minimal kernel layer for a long-term Rust infrastructure project.

The focus is intentionally narrow:

deterministic primitives
zero-allocation types
stable binary representations
no hidden runtime behavior
strict invariant enforcement

Recently, I ran a long adversarial fuzzing campaign against the kernel primitives.

The campaign crossed roughly 14.8 billion executions.

At first, the interesting part seemed to be the crashes themselves.

But the second crash turned out to be far more interesting than a typical memory bug.

The Crash

The fuzzer eventually stopped on this assertion:

assertion failed: acc_even.ct_eq(&FixedHash::ZERO)

At first glance, this looked like a potential issue in the XOR implementation of the hash primitive.

That would have been serious.

Especially in low-level deterministic infrastructure where algebraic guarantees matter.

The Investigation

The fuzz target contained a chained XOR stress test:

let mut acc_even = h;

for _ in 0..8 {
acc_even = acc_even ^ h;
}

The invariant incorrectly assumed:

«even XOR count ⇒ ZERO»

But there was a subtle mistake.

The accumulator was already initialized with "h".

That means the expression actually evaluated to:

h ^ h ^ h ^ h ^ h ^ h ^ h ^ h ^ h

Not 8 occurrences.

9 occurrences.

And XOR parity rules are strict:

even occurrences ⇒ ZERO
odd occurrences ⇒ ORIGINAL

So the primitive was correct.

The verification logic was wrong.

Why This Matters

This is exactly why long-running fuzzing campaigns are valuable even for “simple” primitives.

The goal is not only to find crashes.

The goal is to validate assumptions.

In low-level systems engineering, incorrect assumptions inside verification layers can become just as dangerous as implementation bugs themselves.

Especially when those primitives are intended to become foundational infrastructure components.

The Fix

The invariant was rewritten to start from ZERO instead:

let mut acc_even = FixedHash::ZERO;

for _ in 0..8 {
acc_even = acc_even ^ h;
}

Now the parity logic is mathematically correct.

Final Thoughts

One thing I’ve learned while building infrastructure software:

Most failures do not come from “complex” code.

They come from small assumptions that quietly survive code review, testing, and intuition.

Fuzzing is one of the few tools brutal enough to challenge those assumptions continuously.

And sometimes, the most valuable bug is the one that proves the primitive was right all along.

Even a Rust Progress Bar Can Become a Reliability Problem

Rabah Laouadi — Wed, 13 May 2026 18:34:12 +0000

While building CommitGuard, I realized something interesting:

even a simple CLI progress percentage can become dangerous under very large workloads.

At first I had the classic calculation:

let percentage =
(current_items * 100) / total_items;

Looks harmless.

And for many projects, it probably is.

But CommitGuard is designed for huge repositories, fuzzing workloads, and long-running scans. That forced me to think more carefully about integer arithmetic and long-term reliability.

The Overflow Problem

The dangerous part is this:

current_items * 100

If "current_items" becomes large enough, multiplication overflows before division even happens.

In Rust:

Debug builds panic.
Release builds wrap around.

That means your progress percentage may silently become incorrect while the program keeps running.

The code compiles perfectly.
But correctness is already gone.

Checked Arithmetic

In low-level and defensive systems, I strongly prefer explicit arithmetic checks.

Something like this:

let scaled =
current_items.checked_mul(100);

match scaled {
Some(value) => {
let percentage =
value / total_items;
}
None => {
// overflow detected
}
}

Why?

Because "checked_*" makes overflow visible instead of hiding it.

For long-term systems, silent corruption is usually worse than explicit failure.

Saturating Arithmetic

Another possible approach is saturating arithmetic:

let percentage =
current_items
.saturating_mul(100)
/ total_items;

This avoids crashes and prevents wraparound behavior.

However, saturation may still produce incorrect logical results once values hit the numeric limit.

So while it is safer than wrapping arithmetic, it is not always mathematically accurate.

Widening Arithmetic

For the progress calculation itself, I ended up widening the arithmetic:

let percentage = if total_items == 0 {
100
} else {
(
(current_items as u128 * 100)
/ total_items as u128
) as usize
};

Using "u128" here makes overflow practically impossible for realistic workloads while keeping the implementation allocation-free and extremely lightweight.

This was a good balance between correctness, simplicity, and hot-path performance.

Why I Avoided Heavy Progress Libraries

While profiling CommitGuard, I noticed many progress implementations rely on:

background threads
shared state
"Arc>"
heap allocations
constant terminal writes

For normal CLI tools, this is usually fine.

But for high-frequency scanning loops, tiny overheads accumulate very quickly.

Especially when progress updates happen millions of times.

So I kept the implementation intentionally simple:

no heap allocations
no background workers
no synchronization overhead
no hidden allocations in the hot path

I also throttle terminal updates to around every 250ms instead of constantly redrawing the screen.

That alone significantly reduces terminal I/O overhead.

Small Math Becomes Systems Engineering

One thing Rust keeps teaching me is this:

there is no such thing as “just simple code” in long-term systems.

A tiny arithmetic assumption can eventually become:

a panic
corrupted state
invalid metrics
undefined behavior
performance degradation

Especially under fuzzing or massive workloads.

The code may compile.
The tests may pass.
But systems programming starts where edge cases begin.
And honestly, that is one of the reasons I enjoy Rust so much.

14.8 Billion Fuzz Layer Zero Kernel

Rabah Laouadi — Sat, 09 May 2026 22:17:26 +0000

What 14.8 Billion Fuzz
Executions Revealed About My Rust Kernel Layer
Over the past few days, I ran a long adversarial fuzzing campaign against the minimal kernel layer of my Rust __infrastructure stack.
The target was intentionally small:

deterministic primitives
zero-allocation design
no_std compatibility
stable binary serialization
overflow-safe arithmetic
invariant-preserving types
The fuzzing campaign executed approximately 14.8 billion iterations.
Focus Areas
The testing focused on validating:
ABI stability
serialization roundtrips
algebraic correctness
normalization logic
overflow behavior
ordering consistency
mutation resistance

Results
The campaign successfully exposed:

2 crash cases
several edge-condition inconsistencies
missing algebraic symmetry in temporal primitives
All issues were discovered before public release.
One particularly interesting result was identifying an incomplete temporal algebra implementation:
"Timestamp + Duration"
"Timestamp - Timestamp"
were implemented, but:
"Timestamp - Duration"
was missing entirely.

The fuzzing process exposed this architectural gap immediately.
Why This Matters
Infrastructure primitives are often treated like simple utility code.
I believe this is a mistake.
Low-level primitives become the foundation for:

distributed systems
ledgers
event sourcing
databases
synchronization layers
audit systems

If the primitive layer is weak, every dependent system inherits that weakness.
Final Thoughts
Fuzzing is not just about finding crashes.
It is one of the best tools for validating architectural assumptions under hostile input conditions.
Especially for foundational systems software.