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

A developer building IONA OS, a sovereign operating system written in Rust, has published a list of security vulnerabilities found in the system. Issues include unencrypted disk reads/writes, a fake onion routing circuit, and a keystore using XOR instead of real encryption. The developer is actively fixing these gaps by integrating encryption, adding file shredding, and implementing duress passwords.

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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: My priorities: shred function.If I fix all of these, IONA OS will be one of the most secure operating systems in the world. 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 https://iona.zone GitHub: github.com/Ionablokchain https://github.com/Ionablokchain I'm building this alone. 13 years of research. Every line is written from scratch. And it works.