DEV Community: Eric-Octavian

Running Android on my own hypervisor — what I learned in one month. 11 partitions, 1.7GB sparse images.

Eric-Octavian — Sat, 25 Jul 2026 08:51:09 +0000

I've been building IONA OS — a sovereign operating system written entirely in Rust — for the past 13 years.

This month, I decided to run Android on it.

Not as a virtual machine, not as an emulator, but as a real guest running on my own hypervisor, written from scratch, in Rust, in Ring -1 (EL2).

Here's how I did it.

Why run Android on a custom hypervisor?

IONA OS is a sovereign operating system. It has its own kernel, its own GUI, its own blockchain protocol, its own programming language (Flux), and its own AI running in Ring 0.

But a phone needs apps. And the biggest app ecosystem is Android.

Instead of building a compatibility layer from scratch, I built a hypervisor that can run a real Android system (AOSP) as a guest, completely isolated from IONA OS.

The goal:

IONA OS runs in EL1/EL0 (native, unchanged)
Android runs in a separate EL1/EL0 guest
EL2 (the hypervisor) manages the isolation
The user sees a unified UI, but the two systems are completely separate

This gives me:

Suveranitate totală — IONA OS remains untouched
Compatibilitate completă — all Android apps work
Securitate maximă — a compromised Android guest cannot affect IONA

Week 1: The real AOSP diagnostic

Most people would search Stack Overflow. I downloaded the actual AOSP source code from android.googlesource.com and read it.

The error message wasn't about a missing file. It was about a parsing failure.

Problem 1: androidboot.slot_suffix missing

The kernel command line was missing androidboot.slot_suffix. The fstab entries had slotselect, which requires this property.

Fix: Add androidboot.slot_suffix=_a to the kernel command line.

Problem 2: GPT composite disk

super.img was attached as a raw disk without a partition table. Android expects named partitions: boot_a, metadata, super, vbmeta_a, etc.

Fix: Built a real GPT disk with sgdisk:

sgdisk -o /dev/sdb
sgdisk -n 1:2048:+64M -t 1:EF00 /dev/sdb # boot_a
sgdisk -n 2:... -t 2:8300 /dev/sdb # metadata

Then wrote each image with dd at the correct sector offset.

Problem 3: /dev/block/by-name/* symlinks missing

realpath /dev/block/by-name/super failed.

Fix: Read devices.cpp in AOSP. The symlink is only created if androidboot.boot_devices is set correctly. For ARM64 under QEMU, the correct value is 4010000000.pcie, not the PCI address.

Problem 4: Sparse images

super.img and userdata.img were in Android sparse format (magic: 3aff26ed). liblp reported "invalid geometry magic signature".

Fix: Converted with simg2img:

simg2img super.img super.raw
simg2img userdata.img userdata.raw

1.7GB sparse → 8GiB raw each.

Problem 5: AVB (Android Verified Boot)

libfs_avb: vbmeta digest error isn't allowed — AVB was blocking boot.

Fix: Read fs_mgr/libfs_avb/fs_avb.cpp and util.cpp. The standard development property is:

androidboot.verifiedbootstate=orange

This is used by every -userdebug build, not a hack.

Problem 6: APEX module ambiguities

apexd-bootstrap aborted repeatedly, once for each module with two variants installed (gatekeeper, graphics.composer, keymint, camera.provider.hal).

Fix: Read apexd error messages. Each pointed to the exact property:

ro.boot.vendor.apex.gatekeeper
ro.boot.vendor.apex.graphics.composer

Set them correctly.

Problem 7: /data mounted read-only

The fstab required ext4 for /data, but userdata.img was actually formatted as F2FS (verified with file).

Fix: Changed androidboot.hardware=cf.f2fs.hctr2 — the correct fstab variant for F2FS.

Result: __mount(..., type=f2fs)=0: Success.

Week 2: The vsock investigation

SurfaceFlinger and several vendor HALs (light, uwb, ril-daemon, bt_hci) were stuck in a restart loop.

The real cause: reading the Rust source of the lights HAL (lights.rs).

An .unwrap() on creating an AF_VSOCK socket was failing. Without virtio-vsock transport, it fails guaranteed. Real Cuttlefish runs companion processes on the host (casimir, netsimd, wmediumd) for these HALs.

We don't have that. The fix would have been:

We skipped it. The HALs are not critical for a booting Android system.

Week 3: The real gap in the hypervisor

You asked: "repară breșa din kernel".

The dispatch loop in hypervisor_launch_linux_image() didn't know what to do with a real hvc from a guest. Any trap other than a stage-2 fault would "stop and report".

The fix: A new psci module in hypervisor.rs.

Real PSCI emulation:

PSCI_VERSION — returns 0x10000 (version 1.0)
SYSTEM_OFF — powers off the guest
SYSTEM_RESET / RESET2 — resets the guest
Everything else — honest NOT_SUPPORTED

All constants verified from real Linux kernel headers (include/uapi/linux/psci.h), not from memory.

Verified organically: The real Android kernel queried PSCI_VERSION through IONA's own EL2 (not QEMU firmware) and received the correct response.

Verified synthetically: New dedicated test: guest_psci_reset_test.

Regression caught before it happened: Our own test hvc calls (hvc #22, #98, etc.) used imm≠0, but real PSCI uses imm=0. Without this distinction, the synthetic boot test would have silently broken.

Verified on both paths (normal EL1 + virtualized EL2): ECDSA/ECDSA-KAT all PASS, no regression.

The final test

I deliberately provoked a known error (removed slot_suffix again) to trigger a real, controlled reboot:

Android crashes: InitFatalReboot: signal 6 → reboot: Restarting system with command 'bootloader'.
IONA genuinely intercepts that SYSTEM_RESET through its own EL2: PSCI call fid=0x84000009 -> guest power request.
hypervisor_launch_linux_image() returns (for the first time ever with a real guest attached) — the loop no longer blocks indefinitely.
Guest #1 (IONA itself) boots — for the first time in any test run with a real external guest attached: launching real guest: IONA kernel boot continuation at el1_native.

What this means

IONA OS can run Android as a guest, isolated in its own EL1/EL0 space.
The hypervisor can intercept, emulate, and handle real requests from a real Linux kernel (PSCI, stage-2 faults, etc.).
When Android crashes and reboots, IONA survives — it intercepts the reboot, tears down the guest, and resumes its own boot.
The isolation works. Android cannot affect IONA OS. The kernel is completely unchanged.

What's next

This is not a finished product yet. But the foundation is solid:

IONA OS runs the hypervisor (EL2) — unchanged
IONA OS runs the native kernel (EL1) — unchanged
Android runs as a guest (EL1) — isolated
The hypervisor manages the transition

Next steps:

GPU acceleration for the Android guest
Audio and input routing
Integration into the IONA OS UI (Android apps appearing in the launcher)

The code

You can find the full source code (including the hypervisor, the PSCI emulation, and the AOSP integration) in the IONA OS repository:

github.com/Ionablokchain/Iona-OS

The project is not yet production‑ready — but the foundation is solid.

Final thoughts

Running Android on my own hypervisor was one of the hardest things I've done.

But it's also proof that one person can build sovereign infrastructure — a hypervisor, a kernel, a blockchain, a language, an AI — all from scratch, all working together.

Website: iona.zone

GitHub: github.com/Ionablokchain

13 years of research. Every line written from scratch. And it works.

I wrote a Post-Quantum SSH server in Rust — from scratch, in the kernel

Eric-Octavian — Thu, 16 Jul 2026 06:40:54 +0000

No OpenSSH. No OpenSSL. Just Rust and a kernel.

I've been building IONA OS — a sovereign operating system written entirely in Rust — for the past 13 years.

Last week, I finished one of the most complex components I've ever written: a full SSH server and VPN stack, both with post-quantum cryptography, running inside the kernel itself.

No external libraries. No OpenSSH. No OpenSSL. Just Rust, bare metal, and a lot of math.

Here's how I did it.

Why post‑quantum?

Quantum computers are coming. When they arrive, they will break RSA and ECC — the cryptographic foundations of almost everything on the internet.

The US government has set a deadline: by 2035, all federal systems must be post‑quantum ready.

I didn't want to wait. I wanted IONA OS to be post‑quantum from day one.

So I implemented Dilithium (ML-DSA) — a lattice‑based signature scheme standardised by NIST — from scratch, in Rust, in the kernel.

What "from scratch in the kernel" actually means

Most people use libraries:

OpenSSH for SSH
OpenVPN for VPN
OpenSSL for crypto
pqcrypto-dilithium for post‑quantum

I used none of them.

Everything was written from zero, in Rust, with no std, no heap allocator (in the critical paths), and no external dependencies.

This means:

No libc
No rand crate
No sha2 crate
No x25519-dalek
No curve25519-dalek
No pqcrypto-dilithium

Every bit of crypto — every NTT transform, every modular reduction, every Keccak round — was written by me.

What I built

1. Post‑Quantum SSH Server

A full SSH server running inside the kernel, listening on port 2222.

Implemented correctly:

mpint encoding — big integer serialisation
ChaCha20‑Poly1305 AEAD — with round‑trip encryption and tamper rejection
KEX (Key Exchange) — using Curve25519 + Dilithium
Host‑key signature — signed with Dilithium
KDF — key derivation for session keys

2. Post‑Quantum VPN

A VPN protocol running alongside SSH, with:

Control framing
Mutual signatures — both sides authenticate with Dilithium
Data‑channel AEAD — ChaCha20‑Poly1305 for packet encryption
Tamper rejection — modified packets are dropped

3. Post‑Quantum Crypto

Dilithium (ML-DSA) — for signatures
Kyber (ML-KEM) — for key encapsulation (planned/partial)
ChaCha20‑Poly1305 — for symmetric encryption
Curve25519 — for elliptic curve Diffie‑Hellman
SHA‑256 / SHA‑384 — for hashing

All written from zero.

The boot log that proves it works

Here's what happens when IONA OS boots:

[SSH] self-test passed: mpint encoding, cipher round-trip + tamper rejection, KEX agreement, host-key signature, KDF
[VPN] self-test passed: control framing, KEX agreement, mutual signatures, key derivation, data-channel AEAD + tamper rejection
[SEC] PQ crypto: ... SSH=OK OpenVPN=OK RSA=OK
[SCHED] spawn 'ssh-accept-loop' tid=16 ...
[BOOT-SEQ] ssh-server OK 2272ms

What this means:

self-test passed — every cryptographic component was verified at boot
tamper rejection — modified packets are detected and dropped
KEX agreement — the key exchange works correctly
mutual signatures — both sides authenticate using Dilithium
PQ crypto: SSH=OK OpenVPN=OK — post‑quantum crypto is active
2272ms — the entire stack initialises in just 2.27 seconds

The hardest part: Dilithium from scratch

Dilithium is a lattice‑based signature scheme.

It's not just "hard" — it's one of the most complex cryptographic algorithms ever standardised.

What makes it hard:

NTT (Number Theoretic Transforms) — you need fast polynomial multiplication
Fiat‑Shamir with Aborts — the signing algorithm can fail and retry
Modular arithmetic — strict, no overflow, no timing leaks
Side‑channel resistance — the code must run in constant time
Memory constraints — no heap, no Vec, no Box

Writing it in Rust, in no_std, in the kernel, without any external help, took months.

But it works.

Why this matters

Most operating systems depend on:

OpenSSH for remote access
OpenVPN / WireGuard for VPN
OpenSSL / LibreSSL for crypto

IONA OS has none of these dependencies.

It is completely sovereign.

If you want to connect to an IONA OS machine, you use its native SSH server — with post‑quantum security, running directly in the kernel.

No Linux. No userspace. No OpenSSL.

What's next

This is not the end. It's the foundation.

Mesh networking — combine VPN with peer discovery to build a fully encrypted mesh between IONA OS devices
Zero‑trust authentication — mutual signatures make every connection verifiable
Post‑quantum TLS — same stack, used for HTTPS

But that's for another article.

The code

You can find the full source code (including Dilithium, SSH, and VPN) in the IONA OS repository:

github.com/Ionablokchain/Iona-OS

The project is not yet production‑ready — but the foundation is solid.

Final thoughts

When I started building IONA OS, people told me:

"You can't build an OS alone."

"You can't write your own crypto."

"You can't implement Dilithium from scratch."

I did all three.

This SSH server is proof that one person can build sovereign infrastructure — if they have the patience, the discipline, and the belief that it's possible.

IONA OS launches on September 15, 2026.

Website: iona.zone

GitHub: github.com/Ionablokchain

13 years of research. Every line written from scratch. And it works.

Building a secure OS: the hard list — what I found and what I'm fixing in IONA OS

Eric-Octavian — Sun, 12 Jul 2026 18:13:33 +0000

Every operating system has security gaps. Most never publish them.

I am publishing mine.

IONA OS is a sovereign operating system written from scratch in Rust. It has a kernel, a GUI, a blockchain protocol, a programming language, and a 140,000‑line AI running in Ring 0. It is designed to be secure by default.

But secure is a journey, not a destination.

Here is the hard list — the security issues I found in IONA OS, and what I am doing about them.

1. The filesystem is not encrypted at rest

IONAFS reads and writes sectors in plain text directly to the disk. I already have a real ChaCha20‑Poly1305 engine with per‑file key derivation (fs/encrypted_storage.rs), but it is only used for backup/distribution — not for everyday local reading and writing (fs/ionafs/mod.rs).

Why this matters:

For a journalist or a civil servant, this is the central threat scenario: a lost device, confiscation at a border, or seizure.

What I'm doing about it:

Integrating encrypted_storage.rs into the normal IONAFS read/write path. Every write will be encrypted automatically. The key will be derived from a PIN or TPM.

2. Deleting a file does not destroy it

delete_file() removes only the index entry. The data sectors remain on the disk, recoverable with standard forensic tools.

Why this matters:

For users with high security requirements — journalists, activists, government officials — this is a critical gap.

What I'm doing about it:

Adding a shred() function that overwrites the data sectors with random patterns before releasing them, with a configurable number of passes.

3. The keystore uses XOR, not real encryption

security/keystore.rs pretends to use AES/ChaCha in its comments, but the actual implementation is a simple XOR stream — trivial to break once an attacker has access to the disk.

Why this matters:

This is a critical vulnerability. XOR is not encryption. If an attacker has access to the disk, they can recover the keys.

What I'm doing about it:

Replacing the XOR stream with real ChaCha20‑Poly1305 encryption, properly key‑derived and authenticated.

4. The onion routing is a UX simulation, not real anonymity

The 3‑hop circuit exists conceptually in net/onion.rs, but the relay list is hardcoded with fake IPs, circuit building is just a 500ms pause before marking it active, and the per‑hop key is keccak256(node_id) — deterministic, not negotiated. There is no real key exchange with any relay.

Why this matters:

If a user believes they are sending data through a real anonymous circuit, they are actually sending it without any anonymity protection.

What I'm doing about it:

Either implementing a real circuit with per‑hop key exchange, or removing the feature and being transparent about it.

5. No duress password with fake content

Zero results for "duress" in the entire codebase. If a journalist or civil servant is forced to unlock the device, there is no second code that shows a fake profile instead of the real data.

Why this matters:

For users who may be coerced into revealing their device, this is essential.

What I'm doing about it:

Adding a duress password that decrypts a fake volume, similar to VeraCrypt — two passwords, two volumes.

6. No hidden / deniable storage

Nothing equivalent to a VeraCrypt hidden volume. The only results for "decoy" are a honeypot oriented towards attackers (ai/honeypot.rs) and drone command decoys — nothing for plausible deniability of the user's own data.

Why this matters:

Users with high risk profiles need to be able to deny the existence of certain data.

What I'm doing about it:

Adding a hidden volume that can be mounted with a separate password.

7. Secure boot measures hashes, not real signatures

The boot measurement is now real (it actually hashes the entry point + .text, not a constant placeholder — corrected in this session), with a software TPM (security/secure_boot.rs) and a root‑of‑trust gate. But there is no signature verification of the UEFI bootloader, and hardware TrustZone/Knox attestation is explicitly a stub that returns false.

Why this matters:

Without signature verification, a compromised bootloader can still load a tampered kernel.

What I'm doing about it:

Adding signature verification with a public key embedded in the firmware, and investigating hardware attestation options.

8. Memory wiping does not touch the heap

memory::scrubber::scrub_all() — called by both emergency wipe paths — zeroizes only the CPU registers, even though the log claims "wiping sensitive memory". Key zeroisation depends entirely on keystore::lock().

Why this matters:

If a device is seized while running, sensitive data may remain in RAM.

What I'm doing about it:

Implementing a function that zeroizes all memory pages before shutting down.

9. Metadata cleaning is a pattern scan, not a real parser

ai/source_protector.rs zeroizes EXIF fields by searching for literal markers (GPS, Author, Model...). This is functional, but can miss fields not covered by the format, unlike a real EXIF/XMP/IPTC parser.

Why this matters:

A user who believes their metadata has been removed may still have sensitive information embedded in their files.

What I'm doing about it:

Using a real metadata parser (e.g., the exif crate in Rust) for accurate cleaning, while keeping the pattern scan as a fallback.

The big picture

This list is not a sign of failure. It is a sign of maturity.

Most operating systems do not publish lists like this. They hide their security gaps. I am publishing mine because:

I understand the real threats — not just theoretical vulnerabilities, but concrete scenarios (confiscation, border, seizure).
I am willing to be transparent — I do not hide problems; I acknowledge them and fix them.
I am building for real users — journalists, civil servants, users with high risk profiles.

My priorities:

Real keystore encryption — replace XOR with ChaCha20‑Poly1305.
IONAFS encryption — encrypt all writes by default.
Secure deletion — add a shred() function.
Duress password + hidden volume — for coercion scenarios.
Real onion routing — or remove it and be transparent.

If I fix all of these, IONA OS will be one of the most secure operating systems in the world.

Want to help?

If you are a security researcher, a kernel developer, or just someone who cares about sovereign computing, I would love to hear your thoughts.

Website: iona.zone

GitHub: github.com/Ionablokchain

I'm building this alone. 13 years of research. Every line is written from scratch. And it works.

Cloud AI is not AI — it's a service you rent

Eric-Octavian — Sat, 11 Jul 2026 19:23:13 +0000

When people talk about AI today, they are not talking about artificial intelligence.

They are talking about a service.

You send a prompt to a server. The server runs a model. The model returns text. You pay per token. This is not intelligence. This is a utility — like electricity or water.

Real intelligence does not live in a data center. It does not depend on an API key. It does not stop working when the internet goes down.

Real intelligence is local. It is sovereign. It is owned by the user.

What is Cloud AI, really?

Cloud AI is a product. You rent access to a model that you do not control.

You do not own the model. You cannot modify it. You cannot see its weights. You cannot verify what it has learned.
You do not control the data. Your prompts, your files, your conversations — they go to someone else's server. You have no idea what happens to them.
You do not control the infrastructure. If the API goes down, your system stops. If the company changes its pricing, you pay more. If the company shuts down, you lose access.

This is not a partnership. This is a dependency.

What is real AI?

Real AI runs locally. It does not send data anywhere. It does not require an internet connection. It does not depend on a company's goodwill.

Real AI is built into the system itself — not as a service, but as a native component.

You own the model. You can modify it, fine-tune it, or replace it.
You control the data. It never leaves your device.
You control the infrastructure. It runs on your hardware, under your terms.

This is what sovereignty looks like.

The difference is not technical — it's structural

Cloud AI is not worse because the models are bad. The models are incredible. But they are not yours.

Real AI is not better because the models are better. The models are smaller, often less capable. But they are yours.

The difference is not about performance. It is about ownership.

IONA AI — a real AI, not a service

IONA AI is not a cloud service. It is a 70k+line Rust AI system that runs inside the kernel of IONA OS.

It runs locally — on your hardware, not on a server.
It does not send data anywhere — your data stays on your device.
It does not depend on an API — it works even when the internet is off.
It is fully integrated — it controls CPU governors, kills processes, synthesises drivers, and optimises the system in real time.

Not a service. A native component.

Why this matters

The AI industry is selling you a subscription and calling it intelligence.

They want you to depend on them. They want your data. They want to own the relationship between you and the machine.

But true intelligence cannot be rented. It must be owned.

What you can do

You can choose to depend on a cloud service, or you can choose to own your intelligence.

It is built by one person, over 13 years. It does not depend on anyone. It is not a service. It is a sovereign operating system with a real, native AI.

If you want to understand what real AI looks like, you can already see the architecture on GitHub.

Website: iona.zone

GitHub: github.com/Ionablokchain

Building a GUI from scratch in Rust — how IONA OS does compositing, widgets, and applications

Eric-Octavian — Tue, 07 Jul 2026 18:01:36 +0000

****No Qt. No GTK. No WebView. Just Rust, pixels, and a compositor.

IONA OS has a GUI. A real one — with windows, buttons, scrollbars, a dock, and applications.

But unlike most operating systems, it doesn't use Qt, GTK, or any external toolkit. Every pixel is drawn by my own code, written in Rust, running in the kernel's address space.

This article explains how I built the IONA OS GUI — from the compositor to the applications.

Why Build a GUI from Scratch?

Most operating systems use an existing toolkit:

Linux → GTK / Qt / EFL
Windows → Win32 / WPF / UWP
macOS → AppKit / SwiftUI

These toolkits are mature, well‑tested, and save time.

So why did I build my own?

Because I wanted sovereignty over every pixel.

No external dependencies — I don't import Qt or GTK.
No license restrictions — I own the entire stack.
No bloat — I only implement what I need.
No legacy — I start from a clean slate.

And because writing a GUI from scratch is one of the most satisfying engineering challenges you can take on.

The Architecture

The GUI in IONA OS has three layers:

Layer 1: The Compositor (`src/gui/compositor.rs`)

The compositor is the heart of the GUI. It manages windows, handles input, and draws the desktop.

Glass compositor — windows are rendered with blur and transparency.
Double‑buffered — no flicker.
Event‑driven — input events are dispatched to the active window.

Layer 2: The Widgets (`src/gui/widgets/`)

Buttons, text inputs, scrollbars, tabs — all are written from scratch.

Each widget is a struct that implements a Widget trait:

pub trait Widget {
fn draw(&self, pixels: &mut [u32], width: usize, height: usize);
fn handle_event(&mut self, event: &Event) -> bool;
}

This allows me to compose complex UIs from simple building blocks.

Layer 3: The Applications (src/gui/apps/)
Applications are normal Rust code that use the widget system.

Browser — simple web view with scrollbar and navigation.

Terminal — with scrollback and visual scrollbar.

Mail — list of messages, with scroll and selection.

Notes — simple text editor.

Calendar — month view with navigation.

Monitor — system metrics (CPU, RAM, processes).

Bluetooth — device management.

Clock — with timer and stopwatch.

Benchmark — performance testing.

Vector Icons — From Blob to Distinct
Until recently, some icons in the dock and launcher were generic blobs. Now, every application has a distinct vector shape:

Application Icon Description
Notes 📝 Notepad with lines
Backup 💾 Floppy disk
Vault 🔑 Key shape
Bluetooth 🔗 Connected nodes
Text Editor ✏️ Pencil
The icons are drawn using anti‑aliased vector primitives (circles, rings, rectangles, lines). No images, no fonts — just code.

Scrollbars — Finally Real
Several applications had scrollable content but no visual scrollbar. Now they all use a common helper:

pub fn draw_scrollbar_buf(
pixels: &mut [u32],
width: usize,
height: usize,
scroll: &mut ScrollState,
total: usize,
visible: usize,
) {
// Draw a thumb on the right side
}

This centralises the logic, so every application gets the same visual style, and I don't have to implement scrollbars six times.

Applications That Actually Work
The recent polish session fixed several UI bugs:

Monitor — q and r keys now work. Process names are truncated on UTF‑8 boundaries, not raw bytes.

Shell — keyboard input now reaches the CLI. All screens (dashboard, policy, recovery, services, operator, governor) are now usable.

Bluetooth — all commands (1/2/s/p/c/u) now work. Errors are displayed, not silently dropped.

Sovereign Apps — the AI chat now accepts keyboard input. MeshRadar now shows real data, not hardcoded numbers.

Browser — toolbar now has real icons for Back, Forward, Refresh, Close, Lock, and Unlock.

Terminal — now has a real scrollbar for scrollback.

What Makes This GUI Different
No external dependencies — every line is written by me.

Integrated with the kernel — applications can call kernel syscalls directly.

Built for Rust — the entire GUI is written in safe Rust (with minimal unsafe for pixel access).

Sovereign — I control the entire stack, from compositor to application.

What's Next
IONA OS is still in active development. The GUI is getting polished, the kernel is stable, and the AI is growing.

The first public ISO is scheduled for September 15, 2026.

If you're interested in seeing more:

Website: iona.zone

GitHub: github.com/Ionablokchain

From blob to icon: polishing the IONA OS GUI — scrollbars, vector icons, and the art of fixing UI that was "almost there"

Eric-Octavian — Mon, 06 Jul 2026 16:55:50 +0000

A kernel is the heart of an operating system. But a desktop is the face.

IONA OS now has a stable kernel, a working compositor, and a growing set of applications. But until recently, some parts of the GUI were still rough around the edges — scrollbars that didn't scroll, icons that were indistinguishable blobs, and selections that disappeared into the void.

This week, I fixed all of that.

Here's what I polished in the IONA OS GUI — scrollbars, vector icons, and a few UI bugs that were "almost there" but not quite.

Vector Icons — From Blob to Distinct

IONA OS uses vector rendering for dock and launcher icons (draw_icon_vector_glow). But a few applications didn't have their own vector art, so they fell back to a generic rounded blob — indistinguishable from every other missing icon.

The affected applications were:

Notes (Dock)
Backup / Save (Launcher)
IONA Vault / Key (Launcher)
IONA Bluetooth / Share (Launcher)
Text Editor / Edit (Launcher)

They all look like this:

Generic blob — no identity

Now, each has its own distinct vector shape:

Application	Icon	Description
Notes	📝	Notepad with lines
Backup	💾	Floppy disk / save symbol
Vault	🔑	Key shape
Bluetooth	🔗	Connected nodes
Text Editor	✏️	Pencil / edit symbol

The code uses the existing vec_draw() infrastructure, so no new rendering pipeline was needed — just a few extra match arms in the icon dispatcher:

// src/gui/primitives.rs (conceptual)
Icon::Notes => {
// notepad with lines
v_rect(…);
v_line(…);
v_line(…);

Icon::Vault => {
// key shape
v_ring(…);
v_rect(…);
}

Now every icon in the dock and launcher is visually distinct. No more blobs.

Scrollbars — Finally Real Several applications had content that could overflow the screen, but no scrollbar to indicate where you were.

Before:

Files: no scroll indicator at all.

Mail: selection could scroll off-screen and never return.

Notes: same bug as Mail.

Browser: no scrollbar for web content.

Terminal: only a text line reading "scrollback 42%" — no visual thumb.

After:

All these applications now use a common helper: gui::widgets::scroll_view::draw_scrollbar_buf.

The helper draws a consistent scrollbar on the right side of the viewport, with a thumb that scales to the visible content.

Here's the shared code (simplified):

// src/gui/widgets/scroll_view.rs
pub fn draw_scrollbar_buf(
pixels: &mut [u32],
width: usize,
height: usize,
scroll: &mut ScrollState,
total: usize,
visible: usize,

///if total <= visible { return; }
let thumb_height = (visible as f32 / total as f32 * height as f32) as usize;
let thumb_y = (scroll.offset as f32 / (total - visible) as f32 * (height - thumb_height) as f32) as usize;
// draw thumb on the right side
for y in thumb_y..thumb_y + thumb_height {
for x in width - 8..width - 2 {
pixels[y * width + x] = 0x444444;
}

This centralises the logic, so every application gets the same visual style — and I don't have to implement scrollbars six times.

Specific fixes:

Mail & Notes: Selection can no longer scroll off-screen. When you move the selection past the visible area, the list auto-scrolls to keep it in view.

Browser: The content area now has a real scrollbar (not just a static toolbar).

Terminal: The "scrollback 42%" text is gone. Now there's a real thumb on the right edge.

Browser Toolbar — Icons, Not Text The browser toolbar had buttons that were drawn as text symbols:

< > R X S H

Which worked, but looked rough and inconsistent.

Now they're proper bitmap icons:

Symbol Icon
< Back
> Forward
R Refresh
X Close
S Lock (secure)
H Unlock (insecure)

The icons use the same Icon enum as the rest of the system:

Icon::Back,
Icon::Forward,
Icon::Refresh,
Icon::Close,
Icon::Lock,
Icon::Unlock,

This makes the browser toolbar visually consistent with the rest of the desktop.

Calendar — Real Back/Forward Icons The calendar header had < and > as plain text. Now they're real Icon::Back and Icon::Forward bitmap icons.

It's a small change, but it makes the navigation feel more responsive and polished.

The Big Picture: Why Small Details Matter None of these changes are revolutionary. They're small, incremental improvements.

But together, they transform IONA OS from a system that technically works into a system that feels good to use.

A scrollbar that actually moves.

An icon that tells you what it represents.

A selection that stays visible.

These are the details that users notice — even if they don't consciously think about them.

What's Next
IONA OS is still in active development. The kernel is stable, the AI is growing, and the GUI is getting polished.

The first public ISO is scheduled for September 15, 2026.

If you're interested in seeing more, here are the links:

Website: iona.zone
GitHub: github.com/Ionablokchain

Six GUI bugs I fixed in one day — how I made IONA OS actually usable From dead keyboard shortcuts to broken input to hardcoded data: a day of polish

Eric-Octavian — Sun, 05 Jul 2026 16:06:11 +0000

Yesterday I spent a full day fixing six applications in IONA OS. None of them were completely broken. They all looked good, they all compiled, they all ran. But they were almost unusable.

This is the story of how I turned them into actual tools.

The problem — applications that looked good but didn't respond

IONA OS has a GUI compositor (glass), a desktop, and a suite of applications. They are written in Rust, using a custom GUI framework. They compile, they render, they look decent.

But:

The keyboard shortcuts didn't work.
Buttons were drawn but had no click regions.
The shell had no keyboard input.
Some applications showed hardcoded data next to real data.

This is the phase where a project goes from "looks like a product" to "is a product". Here's how I fixed it.

1. Monitor — `q/r` didn't work, and process names crashed the system

The Monitor app shows CPU, RAM, processes, and network stats. It had two problems:

Pressing q or r (quit/refresh) did nothing — the input handler was never connected.
Process names were truncated on raw bytes, not on character boundaries. If a process name contained multibyte UTF-8 (e.g., Chinese characters), the truncation could cut in the middle of a character and cause a crash.

Fix: I connected the input handler properly and replaced the byte‑based truncation with a UTF‑8 safe function that respects character boundaries.

// Before: crashed on multibyte chars
let name = &proc_name[..16];

// After: safe UTF-8 truncation
let name = safe_truncate(proc_name, 16);

Now Monitor is stable and responsive.

IONA Shell — the entire CLI was dead The shell is the heart of IONA OS — it controls dashboards, policies, recovery, services, operators, and the governor. It's a text‑based interface for everything.

But no keyboard input ever reached it.

The input loop was written, the rendering was working, but the event pipeline stopped before the shell. For weeks, I had been testing it with simulated input. Real users would have seen a frozen screen.

Fix: I traced the event chain from the kernel's keyboard driver through the GUI compositor to the shell. I found that key events were being delivered to the window but not forwarded to the CLI handler. I fixed the forwarding logic.

Now the shell is fully functional. Every screen (dashboard, policy, recovery, services, operator, governor) responds to real keyboard input.

Bluetooth — dead commands and silent failures Bluetooth had five commands: 1 (scan), 2 (pair), s (status), p (pair), c (connect), u (unpair). None of them worked. The key handler was written, but the format was dead — the event parser was looking for the wrong key codes.

Arrow navigation was also broken — it used old PS/2 key codes instead of modern USB HID codes. Only the mouse wheel worked.

Worse: when a command failed, it just returned (). No error message, no feedback.

Fix: I rewrote the key handler to use correct USB HID codes and added error display. Now every command shows a result or an error message.

// Before: silent failure
fn pair_device() { .. } // returned nothing

// After: error feedback
fn pair_device() -> Result { .. } // returns success or error

Now you can scan, pair, connect, disconnect, and unpair — and you know if it worked.

Sovereign Apps — AI chat dead, hardcoded data Sovereign Apps contains the AI Assistant and the Blockchain Monitor. The AI Assistant had a text input that was rendered but didn't accept keyboard input (same format‑dead bug). The Blockchain Monitor had a scroll region that didn't respond.

Separately, the MeshRadar panel showed Peers: 3 Online: 2 — hardcoded values. Next to it, the real mesh status was being updated, but users were seeing two different numbers.

Fix: I fixed the input handler for the AI chat and the scroll region. I also replaced the hardcoded values with real data from the mesh subsystem.

// Before: hardcoded
draw_text("Peers: 3 Online: 2");

// After: real data
draw_text(&format!("Peers: {} Online: {}", mesh_peers(), mesh_online()));

Now the AI Assistant works, the Blockchain Monitor scrolls, and the MeshRadar shows truth.

Benchmark — R or Enter didn't start the test The Benchmark app showed a prompt: Press R or Enter to start. But pressing R or Enter did nothing. Same bug — the format was dead.

Fix: I connected the prompt to the actual event handler. Now pressing R or Enter starts the benchmark.

Clock — Start/Reset buttons had no click region The Timer screen in the Clock app had Start and Reset buttons. They were drawn on the screen, but clicking them did nothing. Only keyboard shortcuts worked.

Fix: I added the missing click region. Now clicking the buttons works.

The pattern — and what I learned
All six bugs were variations of the same two problems:

Input events were not being forwarded — the rendering was correct, but the event pipeline stopped before reaching the application.

String handling was unsafe — byte‑based truncation can crash on multibyte UTF‑8.

I fixed the input forwarding in each application individually. Next, I plan to centralise this logic so it doesn't happen again.

What this means for IONA OS
IONA OS is now more than a kernel that boots. It's an operating system you can actually use.

The Monitor shows real data and responds to your keys.

The Shell is a fully functional CLI.

Bluetooth works.

The AI Assistant can be used.

The Benchmark is lansable.

The Clock Timer responds to clicks.

These fixes took one day. They made the difference between "it compiles" and "it works".

Why this matters
A system of operating that boots but has unusable applications is a demo. A system where every application responds to input and shows real data is a product.

IONA OS is now closer to a product than it's ever been.

Resources
Website: iona.zone

GitHub: github.com/Ionablokchain

24 hours of kernel debugging – keeping IONA OS alive in QEMU Lock ordering, backlight hangs, hypervisor detection, and an AMD FCH guard

Eric-Octavian — Thu, 02 Jul 2026 16:27:30 +0000

Yesterday was a good day.

I fixed five bugs that had been bothering me for a while. None of them were catastrophic, but they were subtle — the kind of bugs that cause hangs, deadlocks, or silent failures that are hard to reproduce.

Here's what I fixed, how I found them, and what I learned.

1. Lock Order WM→BACK — The Deadlock You Don't See

The bug: IONA OS would occasionally hang when the window manager tried to acquire a lock that was already held by the backlight driver.

The problem: ABBA deadlock. Thread A locked WM, then tried to lock BACK. Thread B locked BACK, then tried to lock WM.

The fix: Reorder the locks. Always acquire BACK first, then WM. Consistent order = no deadlock.

// Before
lock(&WM);
lock(&BACK);

// After
lock(&BACK);
lock(&WM);

Simple, but hard to find without tracing.

Backlight Skip — QEMU Has No Backlight The bug: On boot, IONA OS would hang at [BL] Backlight init... when running in QEMU.

The problem: QEMU doesn't have a backlight device. The driver was trying to communicate with hardware that didn't exist.

The fix: Detect the hypervisor and skip backlight initialization entirely.

if is_hypervisor() {
serial_println!("[BL] Hypervisor detected — skipping backlight init");
return;
}

Now IONA OS boots cleanly in QEMU.

Hypervisor Detection — CPUID without the Flag The bug: is_hypervisor() would return false even in QEMU.

The problem: The CPUID 1 leaf ECX31 is not always set, especially with -cpu qemu64.

The fix: Don't rely on the flag. Probe the hypervisor leaf directly (0x4000_0000).

fn is_hypervisor() -> bool {
// Try the hypervisor leaf directly
let eax = unsafe { cpuid(0x4000_0000) }.eax;
eax != 0
}

This works with any QEMU configuration.

EDP FCH Guard — MMIO That Doesn't Exist The bug: IONA OS would page fault when trying to read AMD FCH registers in QEMU.

The problem: The EDP driver was reading MMIO addresses that exist on real hardware (AMD FCH) but not in QEMU.

The fix: Add a guard — if the hypervisor is detected, skip the FCH access.

if is_hypervisor() {
serial_println!("[EDP] Skipping AMD FCH MMIO — running in VM");
return;
}

No more page faults.

Disk Image Path — The Silent Fail The bug: The build pipeline was producing a disk image, but QEMU couldn't find it.

The problem: The build script was looking for x86_64-unknown-none/iona-pc.bin, but the actual path was x86_64-iona/debug/iona-pc.bin.

The fix: Update the build script to use the correct target directory.

Before

cp target/x86_64-unknown-none/debug/iona-pc.bin dist/

After

cp target/x86_64-iona/debug/iona-pc.bin dist/

A small fix, but it made the difference between booting and failing.

What I Learned

Bug-finding is a skill. The hardest bugs aren't the ones that crash — they're the ones that silently hang or fail unpredictably.
Hypervisor detection needs to be robust. Not all hypervisors set the standard flag. Always try the direct leaf.
Lock ordering is critical. A single reversed lock order can cause intermittent deadlocks that are nearly impossible to reproduce.
Even small fixes matter. Fixing a path in the build script can save hours of confusion.

The State of IONA OS
These five fixes are part of a larger effort to stabilise IONA OS

The kernel is now:

Bootable in QEMU and on real hardware.
Stable under load.
Actively maintained and debugged.

Resources
GitHub: github.com/Ionablokchain
Website: iona.zone

Writing apps for IONA OS — a quick start guide

Eric-Octavian — Sun, 28 Jun 2026 19:20:34 +0000

IONA OS is not just a kernel. It's a complete platform for building sovereign applications.

This guide shows you how to write your first native application for IONA OS — from project setup to running it on the system.

1. The Ecosystem

IONA OS supports two languages for native application development:

Rust — for performance-critical applications (system tools, drivers, 3D applications).
Flux — for applications that leverage the AI, causal memory, and timeline features.

Both languages can interact with the kernel through a unified syscall interface.

2. Writing a Rust Application

Create a new Rust project:

cargo new my_app --bin

Add the IONA syscall crate to Cargo.toml:
[dependencies]
iona-syscall = { git = "https://github.com/Ionablokchain/Iona-OS" }

// src/main.rs

![no_std]

![no_main]

use iona_syscall::*;

pub extern "C" fn _start() -> ! {
// Print a message to the console
println!("Hello from IONA OS!");

// Get system metrics
let cpu_temp = syscall::get_cpu_temp();
let uptime = syscall::get_uptime();

println!("CPU Temperature: {}°C", cpu_temp);
println!("Uptime: {} seconds", uptime);

loop {}

}

Build and run:

cargo build --target x86_64-unknown-iona
iona-run target/x86_64-unknown-iona/debug/my_app

Writing a Flux Application Flux is a language designed for describing intentions, timelines, and causal relationships.

A simple Flux application:

intention HelloWorld {
trigger: on_boot()
priority: 0.5
execute: {
send("inner_voice", "Hello from Flux!", 1s);
let temp = system::cpu_temp();
send("inner_voice", "CPU temperature is: " ++ to_string(temp), 1s);
}
}
Flux applications are compiled to bytecode and run on the Flux VM, which is integrated into the kernel.

AI Integration — The ai Syscall IONA OS applications can interact with the kernel-integrated AI.

let result = syscall::ai_query("What is the current system health?");
println!("AI says: {}", result);

The AI can also be used for:

ai_suggest_governor() — suggests optimal CPU governor for current workload.

ai_optimize_memory() — suggests memory management changes.

ai_predict_crash() — predicts potential system failures.

GUI Applications IONA OS includes a native GUI compositor (glass). Applications can create windows, buttons, and text inputs.

use iona_gui::*;

fn main() {
let window = Window::new("My App", 800, 600);
let button = Button::new("Click me");
button.on_click(|| {
println!("Button clicked!");
});
window.add(button);
window.run();
}

The GUI compositor supports 3D acceleration via VirGL/Vulkan, animations, and themes.

What's Next This is just the beginning. IONA OS also supports:

WASM — run WebAssembly applications in a sandbox.

System services — background tasks, daemons, and services.

Blockchain integration — native IONA Protocol transactions from your app.

All of this is available in the current version of IONA OS.

Resources
GitHub: github.com/Ionablokchain

Website: iona.zone

Documentation: (coming soon)

IONA OS

I'm building this alone. 13 years of research. Every line is written from scratch. And it works.

How to Make a Kernel AI Actually Rational: Causal Chains, Hallucination Detection, and a Parliament

Eric-Octavian — Fri, 26 Jun 2026 19:09:07 +0000

IONA OS is an operating system written from scratch in Rust. It has its own kernel, its own GUI, its own blockchain protocol, its own programming language (Flux), and — since recently — its own kernel‑integrated AI.

Not a chatbot. Not a cloud API wrapper. An AI that runs in Ring 0, reads CPU temperature directly, kills processes, changes governors, and synthesises drivers.

But here's the thing: when an AI runs inside the kernel, a hallucination isn't just a wrong answer. It could crash the system, corrupt memory, or make a bad decision that leaves your laptop unusable.

So I built a system that doesn't just generate responses. It verifies them. It cross‑checks facts, detects causal loops, and consults a governance system before taking any risky action.

Here's how it works.

1. The Causal Chain — Not Just Logs

Most systems log events. IONA AI builds a causal graph.

Every event — a temperature spike, a governor change, a user command — is stored with a parent pointer. When the AI observes a problem, it traverses the chain backwards.

Example:
Event: temperature = 89°C
Parent: governor set to Performance
Grandparent: user started compiling kernel
Great-grandparent: user typed "make -j8"

This isn't just a stack trace. It's a causal narrative.

The AI uses this to answer "why" questions. When you ask "why is the CPU hot?", it doesn't just say "because load is high". It says:

Temperature rose because governor was set to Performance when you compiled the kernel, which spawned 8 threads that consumed 95% CPU for 4 minutes.

That's the difference between logging and reasoning.

2. Cycle Detection — Breaking Circular Logic

AI systems can fall into loops. A causes B, B causes C, C causes A.

This is subtle. The AI might suggest lowering the governor to reduce temperature. But if the system is already thermal‑throttling, lowering the governor might increase compile time, which keeps the system hot longer.

We built a cycle detector into the causal chain. When the AI proposes an action, it checks if that action would create a loop.

Pseudo‑code:

if detect_cycle(proposed_action) {
log_warning("causal cycle detected: A → B → C → A");
suggest_external_action();
}

If a cycle is found, the AI reports it explicitly:

Causal cycle detected: thermal_throttle → governor_change → cpu_load → thermal_throttle. I cannot resolve this internally. Suggest: active cooling or reducing workload.

This forces the AI to stop spinning and ask for external help, rather than pretending it can solve the problem.

Hallucination Detection — Cross‑Fact Consistency The biggest risk of a kernel AI is hallucination. If it says "CPU is at 60°C" but it's actually 90°C, a human might trust it and not act. That's dangerous.

IONA AI cross‑checks facts.

When the AI says "CPU is over 80°C", it verifies the correlation with power draw (watts). If CPU temperature is high but power draw is low, the system knows something is inconsistent.

Pseudo‑code:

if cpu_temp > 80.0 && watts < 20.0 {
// Hallucination: high temp with low power is impossible
log_anomaly("inconsistent_temp_watts");
override_response("I can't reliably state the temperature right now.");
}

This cross‑fact consistency prevents the AI from confidently stating false information. It doesn't just trust its own output — it verifies it against other system metrics.

The Parliament — Consensus Before Action The AI doesn't act alone. It has a governance system called the "parliament".

When the AI wants to do something risky (change governor, kill a process, install a driver), it proposes the action to the parliament. The parliament votes.

Example:
Proposal: switch governor to Performance
Votes: 3 for, 1 against
Outcome: approved (quorum reached: 67%)

Each vote is recorded, along with the reasoning. If the parliament reaches quorum (67% approval), the action is executed.

But here's the important part: the outcome is persisted to long‑term memory. The AI remembers why the action was approved (or rejected) and uses that knowledge in future decisions.

This prevents the AI from making the same mistake twice. It also provides an audit trail for every action taken by the AI.

Adaptive Backoff — Don't Reason When the System is Dying When the system is under heavy load, the AI stops doing expensive reasoning.

If CPU usage exceeds 80%, the AI switches to a lightweight mode:

if cpu_usage > 80.0 {
reasoning_depth = 1; // only basic responses
} else {
reasoning_depth = 3; // deep chain‑of‑thought
}

This ensures that the AI doesn't make the system worse by consuming resources it doesn't have. It's a mechanism of self‑preservation — not for the AI, but for the system it runs on.

The Result With these mechanisms, IONA AI is no longer a "chatbot". It's a rational agent that:

Builds causal narratives instead of just logging events.

Detects and breaks circular reasoning.

Cross‑checks facts to avoid hallucinations.

Consults a governance system before taking risky actions.

Adapts its reasoning depth based on system load.

Building an AI that runs inside the kernel is hard. Building one that can be trusted — that doesn't hallucinate, doesn't spiral into circular reasoning, and doesn't crash the system — is even harder.

But it's not impossible. The key is to design for rationality, not just intelligence. To build systems that verify their own outputs. To give them governance, not just freedom.

IONA AI is still evolving. But with these five mechanisms, it's no longer just a "chatbot". It's a self‑correcting, causally aware, energy‑optimising agent that lives inside the operating system itself.

The code is not yet fully public , but you can see the architecture on GitHub.

Website: https://iona.zone
GitHub: https://github.com/Ionablokchain

Questions? Comments? I read every one.

Training LLMs in the kernel — how IONA AI does embedding, RAG, and fine‑tuning without the cloud

Eric-Octavian — Thu, 25 Jun 2026 17:55:59 +0000

Most AI systems today are cloud‑based. You send a prompt to an API, and a model somewhere else generates a response. You don't control the model. You don't control the data. You don't control the infrastructure.

IONA AI is the opposite.

It runs inside the kernel of IONA OS. It reads CPU temperature, kills processes, changes governors, and synthesises drivers — all in real time, with zero latency. And it does all of this without ever sending a single byte to the cloud.

This article explains how IONA AI handles embedding, RAG, and fine‑tuning — entirely locally, entirely in Rust, entirely in the kernel.

1. Embedding — Semantic Search Without the Cloud

IONA AI uses a local embedding model to understand the meaning of text, not just the words.

How it works

At boot, the system tries to load /models/minilm-emb.bin — a MiniLM embedding model with 384 dimensions.

If the file exists, the system uses it for real semantic search. If it doesn't, it falls back to a deterministic FNV‑1a hash (zero downtime, no crash).

Lookup and similarity

Each word is hashed using FNV‑1a for O(1) lookup.
embed(text) → mean pool → L2 normalize → Vec<f32> (384 dims).
Cosine similarity between "kernel panic" and "system crash" is ~0.87 (real semantic understanding).
With the old FNV fallback, the same strings had ~0.30 similarity (character‑based, not meaning‑based).

This allows IONA AI to search its memory semantically, not just by keyword.

2. RAG — Retrieval‑Augmented Generation

IONA AI uses RAG to give the LLM factual context before generating a response.

How it works

User asks a question.
The system computes an embedding for the query.
It searches the knowledge graph and episodic memory using cosine similarity.
The top‑matching facts are injected into the LLM prompt as context.
The LLM generates a response grounded in real data.

Example

If you ask: "What happened when I last compiled the kernel?"

The RAG system finds the relevant episode from memory, embeds it, and injects it into the context. The LLM then responds with:

"You compiled the kernel 2 hours ago with make -j8. Temperature rose to 89°C, and the governor switched to Performance."

Not a guess. A retrieved fact.

3. LLM Engine — Dynamic, Multi‑Architecture Support

IONA AI doesn't hardcode a single model. It reads model metadata at runtime and adapts.

How it works

The llm.rs module reads these fields from a .gguf file:

llama.embedding_length
llama.feed_forward_length
llama.block_count
llama.attention.head_count

It then dynamically builds the network layers, supporting multiple architectures:

Architecture	Status
LLaMA	✅ Supported
Mistral	✅ Supported
Phi3	✅ Supported
Gemma	✅ Supported

Quantization

The engine supports Q4_K_M (the most widely used format) via QuantTensor::from_gguf_q4k(). It can also be extended to Q5_K_M, Q6_K, and Q8_0.

Vocab size

The engine uses the real vocabulary size (32,000 for most models), not a hardcoded 256. This means better tokenisation and more accurate generation.

4. Training and Fine‑Tuning — Local and Sovereign

IONA AI can be fine‑tuned locally, without sending any data to the cloud.

How it works

Data collection — the system logs user interactions, system events, and corrections.
Training — using the learning_loop.rs module, the system periodically updates the model weights.
Fine‑tuning — using the corpus.rs and embedding_store.rs modules, the system can be fine‑tuned on custom datasets.

Example fine‑tuning pipeline

// conceptual code
let data = load_custom_dataset("/var/ai/fine_tune_data.json");
let model = load_model("/models/TinyLlama-1.1B-Chat-v1.0.Q4_K_M.gguf");
let tuned_model = fine_tune(model, data, learning_rate=1e-5);
save_model(tuned_model, "/models/iona-llm.gguf");

This runs entirely in the kernel, on the device itself. No cloud. No API keys. No data leaks.

Why This Matters
Most AI systems are cloud‑dependent. That means:

You don't control your data.

You don't control the model.

You don't control the infrastructure.

If the API goes down, your system stops.

IONA AI flips this model:

You control the data — it never leaves the device.

You control the model — you can fine‑tune it locally.

You control the infrastructure — it runs in your kernel, on your hardware.

No API dependency — if the internet goes down, the AI still works.

This is what sovereign AI looks like.

What's Next
IONA AI is still evolving. The current version supports:

Semantic search with MiniLM embeddings.

RAG with episodic memory and knowledge graph.

Dynamic LLM inference for LLaMA, Mistral, Phi3, and Gemma.

Local fine‑tuning via learning_loop.rs.

Future work includes:

Support for larger models (3B, 7B, 8B).

NPU acceleration (if available on the hardware).

Continuous learning without forgetting.

The Code
All of this is written in Rust, running in the kernel of IONA OS.

The embedding store, the RAG system, the LLM engine, and the fine‑tuning pipeline are all in the src/ai/ directory — 70,000+ lines of Rust AI.

Website: iona.zone
GitHub: github.com/Ionablokchain

Five features that turn an OS into a trust platform: Panic, Dead Man’s Switch, E2E messenger, Vault UI, and Secure Boot attestation in IONA OS

Eric-Octavian — Tue, 23 Jun 2026 17:48:49 +0000

An operating system should not just execute programs. It should protect the person using it.

Most operating systems were built for a world where threats were predictable. That world no longer exists. Today, a device can be confiscated at a border, compromised by malware, or used to surveil the person carrying it.

IONA OS is an operating system written from scratch in Rust. It has its own kernel, its own GUI, its own blockchain protocol, and its own kernel-integrated AI. But beyond the technology, it's designed around a single principle: trust.

This week, I implemented five features that turn IONA OS from a kernel into a trust platform.

Here they are.

1. Panic Shortcut — One Key Combination to Disappear

When you are in a situation where you need to protect your data instantly, you don't have time to navigate menus or click buttons.

IONA OS now has a global panic shortcut: Ctrl+Alt+Delete.

Pressing it triggers:

Ghost Mode — the system becomes unresponsive to external input, hides all active sessions, and presents a clean, locked screen.
Network Isolate — all network interfaces are immediately disconnected. No packets leave the device.

This works from any context — even from the lock screen. Even if the device is partially locked or the UI is frozen.

If your device is confiscated at a border, or if you feel threatened, one key combination is all you need.

No UI. No delay. No questions.

2. Real E2E Messenger — Not a Simulated Chat

Most "secure messengers" on operating systems are just UI wrappers around existing libraries. IONA OS now has a real messenger backend.

The UI in phone/messenger.rs is now connected to crate::net::messenger, which implements:

Double Ratchet — the same protocol used by Signal.
Noise_XX — a modern, authenticated key exchange.

Messages sent from the IONA OS messenger are real E2E encrypted, not simulated. No plaintext touches the network. No metadata leakage.

This is not a feature that will be added later. It is already working.

3. Dead Man's Switch — Auto‑Isolate If You Don't Check In

This feature is for people who are at risk of having their device seized while the system is active.

IONA OS now has a Dead Man's Switch.

The system expects a periodic "check‑in" — a simple signal that the user is still in control. The interval is configurable (default: X minutes).

If the system does not receive the check-in within the configured window, it executes a predefined action:

Network Isolate — cut all network connections immediately.
Full Wipe — erase all user data (if configured).

This is not a theoretical feature. It is implemented. It works from the lock screen. It works even if the UI is not responding.

This is for journalists, activists, and anyone who carries sensitive data through hostile environments.

4. Encrypted File Vault UI — Manage Keys from the GUI

IONA OS has had a keystore module (crate::security::keystore) for a while. But until now, it was only accessible via API.

Now there is a UI.

The Encrypted File Vault is accessible from the Settings screen. It allows you to:

View your current encryption keys.
Add or remove keys.
Encrypt files directly from the file manager.
Decrypt files with a single click.

This brings the power of IONA's cryptographic stack to the user — without requiring the command line.

5. Secure Boot Attestation — See If Your Kernel Is Tampered

At boot, IONA OS now displays a screen that shows:

The cryptographic hash of the kernel.
The verification status: VERIFIED or TAMPERED.
The signature is checked using Dilithium3, a post‑quantum signature scheme.

This is not a hidden check. It is displayed to the user at boot time, before the system loads.

If the kernel is signed correctly, the user sees a green indicator. If not, the system displays a warning and offers recovery options.

This builds trust from the very first second of operation.

Why These Five Features Matter

These features are not isolated additions. They form a cohesive security model:

Panic Shortcut gives you an escape route when you are under threat.
Dead Man's Switch protects you when you are not present.
E2E Messenger protects your communication at rest and in transit.
File Vault UI makes encryption accessible to everyone.
Secure Boot Attestation ensures you know the system is trustworthy before you use it.

None of these features are "future plans". They are all implemented and working in the current version of IONA OS.

What This Means for the User

IONA OS is not just an operating system. It is a platform for trust.

If you are a journalist, you can use it knowing that you have a panic button, a dead man's switch, and real E2E messaging.

If you are an activist, you can use it knowing that your files are encrypted and that the system will isolate itself if you are absent.

If you are a developer, you can use it knowing that the kernel is verified at boot and that the cryptographic stack is exposed through a clean UI.

The Code

All of these features are written in Rust, running in the kernel or in the phone UI layer.

The messenger backend uses Double Ratchet and Noise_XX.

The Secure Boot attestation uses Dilithium3 from crate::security.

The File Vault UI is built on top of crate::security::keystore.

The Panic Shortcut is a global key handler, active even from the lock screen.

The Dead Man's Switch is a background task that triggers network isolation or full wipe when the check‑in is not received.

What's Next

IONA OS launches on September 15, 2026.

The full codebase (v965+) is not yet fully public — what you see on GitHub is a curated snapshot — but the architecture is visible and the project is on track.

If you are interested in security, trust, or building an operating system from scratch, I would love to hear your thoughts.

Website: iona.zone

GitHub: github.com/Ionablokchain

I'm building this alone. 13 years of research. Every line is written from scratch. And it works.

DEV Community: Eric-Octavian

Running Android on my own hypervisor — what I learned in one month. 11 partitions, 1.7GB sparse images.

Why run Android on a custom hypervisor?

Week 1: The real AOSP diagnostic

Week 2: The vsock investigation

Week 3: The real gap in the hypervisor

The final test

What this means

What's next

The code

Final thoughts

I wrote a Post-Quantum SSH server in Rust — from scratch, in the kernel

Why post‑quantum?

What "from scratch in the kernel" actually means

What I built

1. Post‑Quantum SSH Server

2. Post‑Quantum VPN

3. Post‑Quantum Crypto

The boot log that proves it works

The hardest part: Dilithium from scratch

Why this matters

What's next

The code

Final thoughts

Building a secure OS: the hard list — what I found and what I'm fixing in IONA OS

1. The filesystem is not encrypted at rest

2. Deleting a file does not destroy it

3. The keystore uses XOR, not real encryption

4. The onion routing is a UX simulation, not real anonymity

5. No duress password with fake content

6. No hidden / deniable storage

7. Secure boot measures hashes, not real signatures

8. Memory wiping does not touch the heap

9. Metadata cleaning is a pattern scan, not a real parser

The big picture

Want to help?

Cloud AI is not AI — it's a service you rent

What is Cloud AI, really?

What is real AI?

The difference is not technical — it's structural

IONA AI — a real AI, not a service

Why this matters

What you can do

Building a GUI from scratch in Rust — how IONA OS does compositing, widgets, and applications

Layer 1: The Compositor (src/gui/compositor.rs)

Layer 2: The Widgets (src/gui/widgets/)

From blob to icon: polishing the IONA OS GUI — scrollbars, vector icons, and the art of fixing UI that was "almost there"

Six GUI bugs I fixed in one day — how I made IONA OS actually usable From dead keyboard shortcuts to broken input to hardcoded data: a day of polish

The problem — applications that looked good but didn't respond

1. Monitor — q/r didn't work, and process names crashed the system

24 hours of kernel debugging – keeping IONA OS alive in QEMU Lock ordering, backlight hangs, hypervisor detection, and an AMD FCH guard

1. Lock Order WM→BACK — The Deadlock You Don't See

Before

After

Writing apps for IONA OS — a quick start guide

1. The Ecosystem

2. Writing a Rust Application

![no_std]

![no_main]

How to Make a Kernel AI Actually Rational: Causal Chains, Hallucination Detection, and a Parliament

1. The Causal Chain — Not Just Logs

2. Cycle Detection — Breaking Circular Logic

Training LLMs in the kernel — how IONA AI does embedding, RAG, and fine‑tuning without the cloud

1. Embedding — Semantic Search Without the Cloud

How it works

Lookup and similarity

2. RAG — Retrieval‑Augmented Generation

How it works

Example

3. LLM Engine — Dynamic, Multi‑Architecture Support

How it works

Quantization

Vocab size

4. Training and Fine‑Tuning — Local and Sovereign

How it works

Example fine‑tuning pipeline

Five features that turn an OS into a trust platform: Panic, Dead Man’s Switch, E2E messenger, Vault UI, and Secure Boot attestation in IONA OS

1. Panic Shortcut — One Key Combination to Disappear

2. Real E2E Messenger — Not a Simulated Chat

3. Dead Man's Switch — Auto‑Isolate If You Don't Check In

Layer 1: The Compositor (`src/gui/compositor.rs`)

Layer 2: The Widgets (`src/gui/widgets/`)

1. Monitor — `q/r` didn't work, and process names crashed the system