Ring Memory Architecture

No Beginning, No End, No Boundaries

How ferros eliminates fragmentation, exploits, and the entire concept of "first" and "last"

The Problem with Blocks, and ends really

Since the 1960s, every operating system has thought about memory and storage the same way: rectangular blocks with fixed addresses. Your RAM starts at address 0x00000000 and ENDS at some power-of-2 boundary. See, now we already have two gaps, the beginning and the end. Your files live in 4KB blocks arranged in exact parking spots from the "beginning" of the disk.

This seems logical until you realize: circles don't have corners. And corners are where most exploits hide.

Traditional Block Model

  • Fixed 4KB pages (or 8KB, 16KB...)
  • Memory from 0x0 to MAX_ADDR
  • Files have "first block" and "last block"
  • Fragmentation inevitable
  • Predictable addresses = exploitable
  • Page tables, TLBs, multi-level walks

ferros Ring Model

  • Arbitrary sizes (17 bytes? 923KB? Sure!)
  • Two's complement wraparound - no boundaries
  • Files exist in the ring, no "beginning"
  • Fragmentation eliminated by rotation
  • Stochastic placement = unpredictable
  • Subtract-compare: 2 CPU instructions total

How Ring Memory Works

Memory
Ring
App A
File 1
GPU
App B
Cache
File 2

Memory allocations float in the continuously rotating ring. No fixed positions, no predictable patterns.

The Core Principle

Instead of dividing memory into fixed-size blocks starting at address zero, ferros treats all memory - both RAM and storage - as a continuous ring. There is no "first byte" or "last byte". The address space wraps around using two's complement arithmetic.

Key Insight: In two's complement math, there are no boundaries. Add 1 to the maximum value and you're back at the minimum. This isn't a bug - it's a feature we exploit for security and simplicity.

Two's Complement Wraparound

Traditional systems panic at address boundaries. ferros embraces them:

-∞
-128
0
+127
+∞

Add 1 to +127 (max) → wraps to -128 (min) → seamless, no boundaries, no special cases

// Traditional: panic at boundary if (address + size > MAX_ADDRESS) { handle_overflow(); // Complex error path } // ferros: boundaries don't exist // Just wrap naturally via two's complement let new_addr = address.wrapping_add(size); // Always valid

The 2-Instruction Access Check

Here's where it gets beautiful. Every memory access in traditional systems requires dozens of instructions: page table walks, TLB lookups, permission checks, segmentation logic. ferros does it in two CPU instructions.

// Load current process's offset and limit from access table // (These are pre-loaded by kernel during context switch) // Instruction 1: Subtract (adjust pointer by process offset) let adjusted = requested_address.wrapping_add(kernel_offset); // Instruction 2: Compare (unsigned) let access_granted = (adjusted as usize) < allocated_limit;

That's it. No branching, no page table walks, no TLB misses. The hardware does a subtract and a compare. If the compare succeeds, access granted. If not, denied.

Traditional x86 Page Table Walk

  • 1. Check TLB (translation cache)
  • 2. If miss: Load PML4 table address
  • 3. Index into PML4, get PDPT address
  • 4. Index into PDPT, get PD address
  • 5. Index into PD, get PT address
  • 6. Index into PT, get physical page
  • 7. Check permission bits (R/W/X)
  • 8. Add page offset to physical address
~5-10 memory accesses on TLB miss

ferros Subtract-Compare

  • 1. Subtract: addr + offset
  • 2. Compare: result < limit
2 CPU cycles every case

Why This Wasn't Possible Before

Early systems (1960s-1980s) used segmentation with base+limit registers - similar to our approach. But they had problems:

Then paging arrived and everyone forgot segmentation was 90% of the way there. We just needed to add continuous rotation and stochastic offsets.

Continuous Ring Rotation

The secret sauce: rings are always rotating. Not when attacked. Not on a schedule. Always.

Every process has two offsets assigned by the kernel:

The kernel rotates these offsets continuously. Rotation speed is adaptive:

Security Implication: By the time an attacker discovers a process's memory location and crafts an exploit, that process has already moved. The attack lands in empty ring space. No crash, no corruption - just a silent failed memory access.

Hierarchical Ownership

Rings nest inside rings. Each level of the process tree gets its own offset within its parent's allocation:

User (offset: -0x8a7f239d, limit: 4GB) ├─ Browser (offset: +0x1a92bc3f, limit: 2GB) │ ├─ Tab 1 (offset: +0x7f3e84a1, limit: 512MB) │ └─ Tab 2 (offset: -0x4d1f9c82, limit: 512MB) └─ Terminal (offset: +0x3c8f1a5e, limit: 256MB) └─ Shell (offset: -0x6b2d7f91, limit: 128MB)

Notice: offsets are signed and random. No patterns, no predictability. Each allocation gets an arbitrary size - no rounding to 2^n pages.

Ring Filesystem

The same principles apply to persistent storage. Files don't live in blocks numbered 0 to N. They live in the ring.

No Beginning, No End

Traditional filesystems have a superblock at a known location (usually block 0). ferros? The superblock is at a random location, stored in UEFI and backed up across multiple SSDs:

An attacker who physically steals your SSD can't even find the filesystem metadata, let alone decrypt it.

Header Ring Buffer

Instead of a single filesystem header that gets updated in-place (risky!), ferros maintains a ring of headers with generation numbers:

Header Ring (1000 slots, rotating): Slot 847: Gen 29384 [CURRENT] Slot 848: Gen 29383 [PREVIOUS] Slot 849: Gen 29382 [BACKUP] ... Slot 846: Gen 29001 [ANCIENT]

Power loss mid-write? No problem. The kernel boots, scans the header ring, finds the highest valid generation number, and continues. No fsck, no journal replay, no "filesystem needs repair" messages.

Stochastic Block Placement

When allocating storage for a file, ferros doesn't use the "first available block." It picks a random location in the ring where space is available. This has multiple benefits:

Wear Leveling

SSDs have limited write cycles. Random placement naturally distributes writes across all cells, maximizing drive lifespan.

Exploit Prevention

Attacks like buffer overflows rely on predictable memory layouts. Random placement means even identical allocations land in different locations each time.

No Fragmentation

Traditional filesystems fragment because they allocate linearly. Rings rotate and churn - holes get filled naturally as the ring spins.

Vendor Diversity

With dual SSDs from different manufacturers at different offsets, firmware bugs or hardware failures in one drive don't bring down the system.

Organic Memory Flow

The ring architecture isn't just a technical detail - it's a philosophical shift. Memory doesn't live in rigid blocks. It flows organically through the ring like water through a circular channel.

Blocks become ovals. Allocations aren't rectangular anymore - they're fluid regions in the ring with fuzzy, rotating boundaries.

Squares become rings. The entire coordinate system wraps. There is no "edge" to fall off.

Data flows around. Security and memory management happen naturally as the ring rotates, not through complex enforcement mechanisms.

Why Nobody Did This Before

Everyone got stuck in the block mindset. Even modern "innovations" like ASLR (Address Space Layout Randomization) just shuffle blocks around at boot time. The blocks themselves remain static.

ferros takes it further: the blocks never stop moving. It's not randomization - it's continuous, organic flow. By the time you've observed where something is, it's already somewhere else.

// Traditional ASLR: randomize once at boot let base_address = random() & 0xFFFF_F000; // Still aligned to 4KB load_process(base_address); // Fixed for life of process // ferros: continuously flowing loop { let new_offset = cryptographic_random(); // Completely arbitrary atomic_rotate(current_offset, new_offset); sleep(rotation_interval); // Adaptive timing }

Integration with Kill-Switch Architecture

Ring memory is perfect for kill-switch ready systems. Because there are no boundaries, there's no "partial state" to clean up:

Traditional systems need complex shutdown procedures because they maintain invariants: "the page table must be consistent," "the superblock must be updated," etc. ferros has one invariant: the ring is always valid. And because it's a ring, any point on it is as good as any other.

0ms shutdown isn't a feature - it's a consequence. When your entire memory model is based on continuous flow with no fixed positions, there's nothing to "save" when power disappears. Just start flowing again later.

Real-World Benefits

Performance

2 instructions vs 5-10 memory accesses = 5-10x faster memory protection. No TLB shootdown on context switch = 50% faster process switching on mobile.

Security

Rotating offsets make return-oriented programming (ROP) attacks impossible - gadgets move before the exploit completes. Buffer overflows land in empty ring space instead of adjacent data.

Simplicity

No page tables to maintain, no TLB to manage, no segmentation faults to debug. Memory access either works or doesn't - no complex error paths.

Battery Life

Fewer memory accesses = less power. No TLB means no cache pollution. Stochastic allocation spreads wear across SSD = longer device lifespan.

Try ferros

Ring memory architecture is part of ferros from day one. It's not a feature you can disable - it's the foundation everything else builds on.

← Back to ferros