DEV Community: Rabah Laouadi

A Primitive Should Never Have an Opinion

Rabah Laouadi — Thu, 02 Jul 2026 23:33:53 +0000

I wasn't looking for a bug,I was auditing one of the foundational primitives in my infrastructure. The implementation was compact, the test coverage was solid, and nothing immediately stood out.
Then one small constraint caught my attention. It had nothing to do with Rust's type system or memory safety, The primitive was rejecting a mathematically valid value without violating a single structural invariant,The rejection existed for one reason only:
I had decided the value wasn't meaningful.

The Assumption

For a long time, I believed that low-level infrastructure should protect developers from making questionable modeling decisions. It felt like responsible engineering. If a value looked practically useless, why should a primitive allow it to exist? That assumption naturally led me to introduce another rule not because mathematics required it, not because memory safety depended on it, and not because Rust expected it, but simply because I believed it would prevent misuse. The idea seemed harmless. It survived code reviews, redesigns, and every test I threw at it. At the time, I was convinced I was making the primitive more disciplined. I wasn't.

The Question That Changed Everything

The more I examined the constraint, the less sense it made. It wasn't protecting memory safety, it wasn't preserving mathematical correctness, and it wasn't enforcing any structural invariant. Its only purpose was to police intent. That realization forced me to stop reading the implementation and start examining responsibilities instead. Somewhere along the way, I had quietly crossed an architectural boundary. One question immediately exposed it: Who gave this primitive the authority to decide what is meaningful? The answer was obvious. No one had. I had simply allowed a low-level primitive to take ownership of a decision that belonged entirely to the domain above it.

The Boundary

At first, the distinction felt philosophical. It wasn't. The more I traced responsibilities through the system, the more obvious it became that I had mixed two fundamentally different concerns. Structure is objective; meaning is contextual. One belongs to mathematics, the other belongs to people. A primitive exists to answer one question: Is this value structurally valid? Nothing more. The moment I asked it to answer a second question is this range meaningful? it quietly crossed an architectural boundary. It stopped enforcing structure and started enforcing policy.

The Redesign

One specific range exposed the flaw in my thinking. When I looked at

BoundedU64<0, u64::MAX>

I realized there was nothing structurally or mathematically invalid about it. The restriction existed for one reason only: I had unconsciously attached domain semantics to pure mathematics. The redesign itself was surprisingly small removing the restriction required only a few lines of code—but the architectural shift behind it was far more significant. The primitive didn't become weaker by accepting every structurally valid range; it became more honest about its own responsibility. Instead of trying to predict intent or enforce what I considered good modeling decisions, it returned to doing the one thing it was originally meant to do: guarantee structural integrity and leave every question of meaning to the layers built above it.

What Survived

Looking back, there was never a bug hiding inside the primitive. It behaved exactly as I had designed it to behave. The mistake was mine. I had asked infrastructure to answer a question that belonged entirely to the domain. That audit didn't change the implementation nearly as much as it changed my understanding of architectural responsibility. Since then, one principle has stayed with me whenever I design low-level systems: infrastructure owns structure, while meaning belongs to the domain. The boundary between the two is easy to blur, but once you recognize it, it becomes remarkably difficult to design foundational software any other way.

When a Constructor Became a Security Boundary

Rabah Laouadi — Mon, 22 Jun 2026 22:51:57 +0000

When a Constructor Became a Security Boundary

I was auditing the initialization layer of one of my Rust systems when I noticed something that looked completely harmless.

A constructor accepted an object that wasn't fully valid yet and relied on a later validation step to reject it if something was wrong.

At first, I didn't think much about it. The object would eventually be validated anyway.

Then it hit me.

For a brief moment, an impossible state existed inside the system.

It didn't matter that the state lived for only a few instructions. It didn't matter that validation would eventually reject it.

The invalid state had already been created.

That was the vulnerability.

The audit completely changed how I think about constructors. I no longer see them as functions that merely initialize data.

I now think of them as security boundaries.

A Pattern That Looked Correct

The constructor looked innocent enough.

pub fn try_new(header_length: u32, ...) -> Option {
if header_length < Header::SIZE as u32 {
return None;
}

Some(Self {
    header_length,
    // ...
})

}

At first glance, this seems perfectly reasonable.

Reject obviously malformed inputs and let a later validation step enforce the remaining invariants.

For years, this was implicitly my mental model:

Construct
↓
Validate
↓
Use

Nothing looked broken.

The problem is that this design allows an impossible object to exist, even if only temporarily.

And once an invalid state exists, all bets are off.

The Real Vulnerability

At this point, I stopped looking at the constructor and started looking at the object's lifetime.

The model was effectively this:

Construct
↓
Impossible state exists
↓
Validate later
↓
Use

The object may only live in an invalid state for a few instructions or a few microseconds.

That sounds harmless.

It isn't.

The problem with transient invalid states is not their duration.

The problem is their existence.

The moment an impossible state exists, every assumption built on top of your invariants becomes questionable.

An invalid object can:

leak into another subsystem,
trigger assumptions that later become bugs,
cause panic propagation,
violate invariants,
or create Time-of-Check to Time-of-Use (TOCTOU) style hazards.

None of these failures are guaranteed to happen.

That's what makes them dangerous.

They become architectural landmines waiting for future code to step on them.

I realized I had been treating validation as a repair mechanism.

It shouldn't be.

Validation should be the gate that prevents impossible states from ever entering the system.

A Different Mental Model

I no longer think in terms of:

Construct
↓
Validate
↓
Use

I think in terms of:

Validate
↓
Construct
↓
Use

Or even more simply:

Valid object
or
No object.

There should never be an intermediate state.

The Doctrine

This audit reinforced a principle that now governs my Rust designs:

Invalid states should not be repaired.

Invalid states should not be rejected later.

Invalid states should never exist.

Final Thoughts

I no longer design constructors to initialize data.

I design them to defend invariants.

Because the most dangerous bugs are often not memory corruptions.

They are the impossible states we accidentally allow to exist.

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.