Alpha to Beta Roadmap

NØNOS Alpha to Beta Roadmap

The Path to the Most Secure Privacy-First Operating System

Version 0.8.0-alpha to 1.0.0-beta | March–July 2026

Mission Statement

NØNOS exists to deliver an operating system where privacy is not a feature but an architectural guarantee. Every byte of user data remains under user control. No telemetry. No cloud dependencies. No trust assumptions beyond verified cryptographic proofs. The kernel enforces isolation not through policy but through mathematical certainty.

This roadmap defines the 16-week journey from alpha to beta. Upon completion, NØNOS will stand as the most secure general-purpose operating system available to individuals who refuse compromise on privacy.

Current State: Alpha (0.8.0)

The alpha release demonstrates core architecture viability. The kernel boots, schedules processes, manages memory, and provides cryptographic primitives. ZK proof generation and verification function. The capability system enforces basic access control. Storage and network drivers operate in controlled environments.

Alpha limitations:

• Filesystem support limited to RAM-based storage
• No persistent encrypted storage
• Network stack lacks onion routing integration
• Hardware compatibility narrow
• Documentation incomplete
• No formal security audit

Target State: Beta (1.0.0-beta)

The beta release delivers a complete privacy-first operating system suitable for daily use by security-conscious individuals. All data at rest encrypted. All network traffic anonymized by default. All processes capability-restricted. All code paths audited. All cryptographic implementations verified against test vectors and timing attacks.

Beta capabilities:

• ext4 filesystem with full-disk encryption (XChaCha20-Poly1305)
• Onion-routed networking as default transport
• ZK-proven attestation for all loaded code
• Post-quantum cryptography throughout
• Hardware security module integration
• Reproducible builds with deterministic output
• Comprehensive documentation and threat model

Infrastructure Targets

Cryptographic Foundation

NØNOS implements cryptography without external dependencies. No OpenSSL. No system libraries. Every primitive built from specification, verified against test vectors, analyzed for timing leaks.

Storage Stack

Network Stack

Hardware Support

16-Week Development Schedule

Phase 1: Foundation Hardening (Weeks 1–4)

Week 1: 0.8.1 — Memory Subsystem Audit

Release Date: 2026-03-10

The memory subsystem receives comprehensive hardening. Physical frame allocator validates bitmap integrity on every operation. Double-free and use-after-free detection halts execution with diagnostic output. Heap allocator implements red zones with cryptographic canaries. KASLR entropy expands to 24 bits. Guard pages enforce stack boundaries with unmapped regions.

Deliverables:

• Bitmap corruption detection in physical allocator
• Red zone implementation with BLAKE3-derived canaries
• Guard page enforcement on all kernel stacks
• KASLR entropy expansion
• Memory sanitizer for debug builds

Testing:

• 100,000 allocation/free cycles with integrity verification
• Intentional corruption detection validation
• Stack overflow detection confirmation

Week 2: 0.8.2 — Scheduler and Process Isolation

Release Date: 2026-03-17

Process isolation strengthened through address space separation verification. Each process receives independent page tables with kernel mappings read-only. Scheduler implements priority inheritance to prevent inversion. CPU time accounting enables resource limiting. Process capabilities inherited through documented rules only.

Deliverables:

• Address space isolation verification
• Priority inheritance implementation
• CPU time accounting per-process
• Capability inheritance rules enforcement
• Process resource limits (memory, file descriptors, threads)

Testing:

• Inter-process memory isolation verification
• Priority inversion scenarios
• Resource exhaustion handling

Week 3: 0.8.3 — Storage Driver Hardening

Release Date: 2026-03-24

Storage drivers receive production-quality error handling. AHCI driver handles controller reset and recovery. NVMe driver supports multiple namespaces with proper queue management. All drivers implement timeout handling to prevent hang on faulty hardware. DMA operations use bounce buffers when source memory does not meet alignment requirements.

Deliverables:

• AHCI controller reset recovery
• NVMe multi-namespace support
• Timeout handling in all storage paths
• DMA bounce buffer implementation
• Unified storage error reporting

Testing:

• 100 GB data transfer integrity verification
• Controller timeout simulation
• Multi-device configurations

Week 4: 0.8.4 — ext4 Filesystem Implementation

Release Date: 2026-03-31

ext4 filesystem support enables persistent storage. Read support complete for standard ext4 features: extents, directory indexing, large files. Write support follows with journaling for crash consistency. Filesystem driver operates through VFS layer for uniform access semantics.

Deliverables:

• ext4 superblock and group descriptor parsing
• Inode reading and extent tree traversal
• Directory entry enumeration
• File read operations
• Basic write support with journaling

Testing:

• Mount ext4 images created by Linux
• Read file contents and verify integrity
• Directory traversal correctness
• Journal replay after simulated crash

Phase 2: Security Infrastructure (Weeks 5–8)

Week 5: 0.8.5 — Full-Disk Encryption

Release Date: 2026-04-07

All persistent storage encrypted by default. XChaCha20-Poly1305 provides authenticated encryption. Key derivation uses Argon2id with user passphrase. Master key encrypted to multiple slots for recovery. Encryption operates at block layer beneath filesystem.

Deliverables:

• Block-layer encryption driver
• XChaCha20-Poly1305 disk encryption
• Argon2id key derivation (64 MiB memory, 4 iterations)
• Multi-slot key management
• Secure key erasure on shutdown

Testing:

• Encryption/decryption throughput benchmarks
• Key derivation timing verification
• Cold boot attack mitigation verification
• Recovery slot functionality

Week 6: 0.8.6 — Cryptographic Audit

Release Date: 2026-04-14

All cryptographic implementations verified against specifications. Ed25519 matches RFC 8032 test vectors. X25519 matches RFC 7748. ChaCha20-Poly1305 matches RFC 8439. ML-KEM-768 and ML-DSA-65 match NIST submission test vectors. Timing analysis confirms constant-time execution for all secret-dependent operations.

Deliverables:

• RFC 8032 Ed25519 test vector suite
• RFC 7748 X25519 test vector suite
• RFC 8439 ChaCha20-Poly1305 test vector suite
• NIST PQC test vector validation
• Timing analysis tooling and results

Testing:

• Complete test vector execution
• Statistical timing analysis
• Side-channel resistance verification

Week 7: 0.8.7 — Network Stack Hardening

Release Date: 2026-04-21

TCP/IP stack hardened against network attacks. Fragment reassembly bounded to prevent memory exhaustion. TCP state machine validated against RFC 9293. SYN flood mitigation through SYN cookies. IP spoofing prevented through reverse path filtering. All network buffers bounded per-connection.

Deliverables:

• Fragment reassembly memory limits
• TCP RFC 9293 compliance
• SYN cookie implementation
• Reverse path filtering
• Per-connection buffer limits

Testing:

• TCP conformance test suite
• Fragment bomb resistance
• SYN flood handling
• Spoofed packet rejection

Week 8: 0.8.8 — Onion Routing Integration

Release Date: 2026-04-28

Network traffic routes through onion network by default. Tor-compatible circuit construction. Three-hop circuits with cryptographic layering. DNS resolution through onion network. Fallback to clearnet only with explicit user override. Circuit rotation on configurable interval.

Deliverables:

• Onion routing circuit construction
• Cell encryption and relay
• Directory authority communication
• Onion DNS resolution
• Circuit management and rotation

Testing:

• Circuit establishment verification
• Traffic analysis resistance measurement
• DNS leak testing
• Fallback behavior verification

Phase 3: Advanced Security (Weeks 9–12)

Week 9: 0.8.9 — ZK Attestation Enforcement

Release Date: 2026-05-05

All loaded code requires ZK attestation proof. Module loader verifies Groth16 proofs before execution. Proof verification under 10ms on reference hardware. Attestation covers code hash, signing authority, and capability grants. Invalid proofs prevent module load with audit log entry.

Deliverables:

• Mandatory ZK verification in module loader
• Proof verification optimization
• Attestation format specification
• Verification failure handling
• Audit logging for attestation events

Testing:

• Valid proof acceptance
• Invalid proof rejection
• Verification timing benchmarks
• Tampered module detection

Week 10: 0.8.10 — Capability System Completion

Release Date: 2026-05-12

Capability enforcement covers all system interfaces. No syscall bypasses capability checks. Token expiration enforced with millisecond precision. Capability delegation follows principle of least privilege. Audit log captures all capability operations.

Deliverables:

• Comprehensive syscall capability checks
• Token expiration enforcement
• Capability delegation constraints
• Revocation propagation
• Complete audit trail

Testing:

• Capability bypass attempts
• Expiration timing accuracy
• Delegation chain verification
• Audit log completeness

Week 11: 0.8.11 — TPM Integration

Release Date: 2026-05-19

TPM 2.0 provides hardware-backed security. Measured boot extends PCRs with boot component hashes. Disk encryption keys sealed to PCR state. Remote attestation proves system integrity. TPM random number generator supplements software entropy.

Deliverables:

• TPM 2.0 driver implementation
• PCR extension during boot
• Key sealing to PCR values
• Remote attestation protocol
• TPM RNG integration

Testing:

• PCR measurement verification
• Sealed key access control
• Attestation quote generation
• Entropy quality assessment

Week 12: 0.8.12 — SMP Correctness Verification

Release Date: 2026-05-26

Multiprocessor operation verified correct under all conditions. IPI delivery reliable under load. TLB shootdown protocol prevents stale mappings. Per-CPU data properly isolated. Lock ordering prevents deadlock. Memory ordering correct on all architectures.

Deliverables:

• IPI delivery verification
• TLB shootdown correctness
• Per-CPU isolation validation
• Lock order enforcement
• Memory barrier audit

Testing:

• 32-core stress testing
• Concurrent mapping changes
• Cross-CPU data isolation
• Deadlock detection

Phase 4: Polish and Release (Weeks 13–16)

Week 13: 0.9.0 — USB and Hardware Expansion

Release Date: 2026-06-02

USB stack reaches production quality. xHCI driver handles all transfer types. Mass storage class enables USB boot media. HID class supports keyboards and mice. Hub support enables multi-device configurations. Hot-plug reliable.

Deliverables:

• xHCI transfer completion
• USB mass storage class
• USB HID class
• Hub support
• Hot-plug handling

Testing:

• USB device enumeration
• Storage read/write
• Input device functionality
• Hot-plug stress testing

Week 14: 0.9.1 — WiFi Support

Release Date: 2026-06-09

Wireless networking for select chipsets. Realtek RTL8821CE and Intel AX200 prioritized. WPA3-SAE authentication. Traffic routes through onion network same as wired. Power management for mobile use.

Deliverables:

• WiFi driver framework
• RTL8821CE driver
• WPA3-SAE implementation
• Power management
• Roaming support

Testing:

• Association and authentication
• Data transfer reliability
• Onion routing over WiFi
• Power consumption measurement

Week 15: 0.9.2 — Documentation and Reproducibility

Release Date: 2026-06-16

Documentation complete for all public interfaces. Build process fully reproducible. Bit-identical output from independent builds. Source tarball self-contained. Threat model documented.

Deliverables:

• Architecture specification
• ABI reference
• Build manual
• Installation guide
• Threat model document
• Reproducible build verification

Testing:

• Independent build reproduction
• Documentation accuracy verification
• Installation procedure validation

Week 16: 1.0.0-beta — Beta Release

Release Date: 2026-06-23

All prior deliverables integrated. Full regression suite passes. 72-hour stability test completes. Known issues documented. Release artifacts signed and published.

Deliverables:

• Integrated beta release
• Complete test suite passage
• Stability verification
• Release notes
• Signed ISO images

Testing:

• Full regression suite
• Extended stability test
• Hardware compatibility matrix
• Security verification

Privacy Architecture

Data At Rest

All persistent storage encrypted. No unencrypted writes to disk under any circumstance. Temporary files use encrypted RAM filesystem. Swap disabled by default; if enabled, encrypted with ephemeral key. Secure deletion overwrites freed blocks.

Data In Transit

All network traffic routes through onion network by default. DNS queries resolve through encrypted channels. No cleartext connections without explicit user override. TLS for any direct connections uses post-quantum key exchange.

Data In Memory

Process memory isolated through hardware page tables. Kernel memory randomized through KASLR. Sensitive data cleared after use. DMA restricted to designated regions.

Metadata Protection

Filesystem timestamps optionally disabled. File sizes padded to reduce fingerprinting. Network packet sizes normalized. Access patterns obscured through dummy operations.

User Identity

No hardware identifiers exposed to applications. MAC addresses randomized per connection. No telemetry or analytics. No account requirements.

Security Guarantees

Cryptographic

• All primitives constant-time implementation
• No weak random number generation
• Post-quantum algorithms for long-term secrets
• Forward secrecy on all key exchanges
• Authenticated encryption for all data protection

Isolation

• Process address spaces hardware-enforced
• Capabilities required for all privileged operations
• Module sandboxing prevents escape
• Kernel/user boundary enforced by CPU

Integrity

• Measured boot with TPM attestation
• ZK proofs verify code authenticity
• Filesystem integrity verification
• Signed updates only

Availability

• Resource limits prevent exhaustion
• Watchdog timers detect hangs
• Graceful degradation under load
• Recovery mechanisms for corruption

Comparison: NØNOS vs Existing Solutions

NØNOS provides security guarantees no existing system matches. The custom kernel eliminates legacy attack surface. Mandatory encryption prevents data exposure. ZK attestation proves code integrity mathematically. Post-quantum cryptography protects against future threats.

Infrastructure Requirements

Development

• 3 full-time kernel engineers
• 1 cryptography specialist
• 1 network security engineer
• 1 documentation writer
• 1 QA engineer

Build Infrastructure

• Reproducible build environment (containerized)
• CI/CD pipeline with automated testing
• Binary cache for build acceleration
• Signing infrastructure (air-gapped)

Test Infrastructure

• Hardware test lab (Tier 1 platforms)
• Virtualization cluster for parallel testing
• Network simulation environment
• Fuzzing infrastructure

Distribution

• Primary download server
• Mirror network (3+ geographic regions)
• Tor hidden service mirror
• IPFS distribution

Success Criteria

Functional

• Boots and operates on all Tier 1 hardware
• ext4 filesystem fully functional
• Network connectivity through onion routing
• USB devices operational
• WiFi functional on supported chipsets

Security

• All cryptographic test vectors pass
• No privilege escalation paths identified
• Capability system enforced completely
• FDE operational with Argon2id KDF
• TPM attestation functional

Performance

• Boot to login under 10 seconds
• ZK verification under 10ms
• Disk throughput within 90% of unencrypted
• Network latency acceptable for onion routing

Quality

• 72-hour stability without kernel panic
• All documentation complete and accurate
• Reproducible builds verified
• Known issues documented

Post-Beta Roadmap

Future Directions (Post-1.0)

• ARM64 architecture support
• Secure enclave integration (SGX, TrustZone)
• Hardware wallet integration
• Mobile device support
• Mesh networking
• Distributed storage backend

Governance

Decision Making

Technical decisions by consensus among core developers. Security-critical changes require cryptography specialist approval. Architecture changes require documentation update before merge.

Contribution

All contributions require signed commits. Code review mandatory for all changes. Security-sensitive code requires two reviewers. Test coverage required for new features.

Disclosure

Security vulnerabilities reported privately. 90-day disclosure timeline. Coordinated release with fix availability. Credit to reporters.

Conclusion

NØNOS represents a fundamental reimagining of operating system security. Rather than layering protections atop legacy architectures, NØNOS builds security from first principles. Every component designed for privacy. Every interface capability-controlled. Every cryptographic operation verified.

The 16-week roadmap transforms the alpha proof-of-concept into a beta system suitable for real-world privacy-critical use. Upon completion, NØNOS will offer security guarantees no existing operating system provides.

Privacy is not negotiable. NØNOS makes it non-negotiable in code.

Sovereignty From Ø

AGPL-3.0 | Copyright 2026 NØNOS Contributors