daniel
/
danos
1
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects 1 Releases Wiki Activity
Operating System written for me
399 Commits 19 Branches 0 Tags 41 MiB
Zig 94.2%
Python 4.7%
Assembly 1.1%
Go to file
Daniel Samson cb30faf15f
kernel: a hostile return address cannot fault the kernel 
SYSRETQ with a non-canonical RIP raises a general protection fault in ring
0 — on the kernel stack, an instruction after the swapgs that installed the
user's GS base. It is one of the better-known escalation primitives, and
ring 3 reaches it without any kernel bug at all: the processor saves the
address of the instruction after SYSCALL, so a program whose SYSCALL is the
last two bytes of the last canonical page returns to the first
non-canonical address. The new test does exactly that.

The exit path now sign-extends the return address from bit 47 and compares;
if the value changed, it returns through IRETQ instead, which commits the
privilege change before fetching the new address, so the fault arrives from
ring 3 and the process dies like any other. Four register-only operations
and a branch that a correct program can never take — it could not have
executed at a non-canonical address in the first place. Bit 47 is the right
pivot because danos builds four-level page tables and nothing sets the
five-level bit; a future port must move the pivot, and the comment says so.

SFMASK grows one bit while we are here. SYSCALL, unlike an interrupt gate,
does not clear the nested-task flag, so the kernel had been running every
system call with whatever ring 3 last chose — harmless while the only exit
was SYSRETQ, and a question worth not having now that one exit is IRETQ.
The kernel is never nested; ring 3 still gets its own flag back.

Suite 113/113. The new case asserts the refusal counter rather than the
dying process: the emulator we test on kills it either way, so only the
counter distinguishes a guard that ran from one that did not.
 		2026-08-01 11:22:07 +01:00
boot reorg: move test fixtures to test/system/services (source + boot volume) 2026-07-23 00:11:07 +01:00
build build: the unix paths retire — configuration, logs, and volumes move into the danos tree 2026-07-31 19:41:35 +01:00
build-support build: delete module_homes — imports resolve through the declared zon 2026-07-30 07:49:19 +01:00
docs kernel: a hostile return address cannot fault the kernel 2026-08-01 11:22:07 +01:00
library library: the harness keeps the subscribers, and an id belongs to whoever opened it 2026-08-01 09:05:26 +01:00
system kernel: a hostile return address cannot fault the kernel 2026-08-01 11:22:07 +01:00
test kernel: a hostile return address cannot fault the kernel 2026-08-01 11:22:07 +01:00
tools boot: the capsule — one-file system image first, manifest and walk as fallbacks 2026-07-21 18:57:33 +01:00
usr/share/fonts assets: add font families under usr/share/fonts 2026-07-14 18:39:23 +01:00
.editorconfig editorconfig 2026-07-12 16:09:11 +01:00
.gitattributes gitattributes 2026-07-12 16:09:18 +01:00
.gitignore gitignore: /var/log — real-hardware log pulls stay out of the tree 2026-07-21 20:09:29 +01:00
README.md re-org docs 2026-07-23 00:25:34 +01:00
build.zig library: the harness keeps the subscribers, and an id belongs to whoever opened it 2026-08-01 09:05:26 +01:00
build.zig.zon library: the harness keeps the subscribers, and an id belongs to whoever opened it 2026-08-01 09:05:26 +01:00

README.md

DanOS

Codename: Shodan

A very small resilient operating system.

Zen of DanOS:

  • Resilient Micro-Kernel Architecture.
    • Every process run in an isolated user space not kernel space.
    • Processes cannot take down the entire OS with it when they die or is killed
  • Stable public runtime library, private OS ABI.
    • Keeps a stable runtime for user space processes between OS versions (great for backwards compatibility)
    • Allows the underlying OS to be changed without effecting applications
    • Provides a boundary to enable compatibility between OS's e.g. POSIX, MUSL etc
  • Drivers are just isolated processes in user space.
    • Thin binaries that can be restarted like applications.
    • Useful during driver development.
    • Drivers can claim MMIO / ports
    • Driver resources (e.g. IRQ/Port/MMIO) claims are automatically cleaned up if the driver dies or is killed
    • Drivers can also hook into the process lifecycle to clean up or reset hardware
  • No legacy to deal with
    • Zig code uses a clean coding style (Zen of Zig)
    • Favor reading code over writing code.
    • No magic numbers.
    • No shortened names unless its for ABI compatibility or acronyms
  • Inter-Process Communication (IPC)
    • Publish and subscribe to Asynchronous Messages
    • Talk to services and processes synchronously

Prerequisites

  • Zig 0.16.x — the build is pinned to this line (.zig-version); other minor versions are rejected, because Zig makes breaking changes between releases pre-1.0. A toolchain manager such as zvm or zigup will pick up .zig-version automatically.
  • QEMU (qemu-system-x86_64) — to run and test the kernel. On macOS, brew install qemu also bundles the OVMF firmware below.
  • OVMF UEFI firmware — the edk2-ovmf package (Arch), ovmf (Debian/Ubuntu), or edk2-ovmf (Fedora); on macOS it ships inside the Homebrew qemu formula. Both the build and the test harness probe the known Arch/Debian/Fedora/macOS layouts and use the first that exists, so no configuration is normally needed. Override with -Dovmf-code= / -Dovmf-vars= (build) if yours lives elsewhere.
  • Python 3 — for the QEMU integration test harness.

Build

zig build

Produces a FHS-shaped zig-out/ that is the danos filesystem and the boot volume: the UEFI bootloader at zig-out/EFI/BOOT/BOOTX64.efi, the kernel at zig-out/system/kernel, init at zig-out/system/services/init, drivers under zig-out/system/drivers/, the test fixtures under zig-out/test/system/services/, and the initial-ramdisk at zig-out/boot/.

Release media

zig build release-x86-64

Produces zig-out/danos-x86-64.iso, a hybrid ISO that boots flashed raw to a USB stick (balenaEtcher, dd) or burned to optical media — see docs/release-iso.md. zig build check-iso-image validates it without booting.

Run

Boot it in QEMU with OVMF (opens a display window):

zig build run-x86-64
# distro with OVMF elsewhere:
zig build run-x86-64 -Dovmf-code=/path/OVMF_CODE.fd -Dovmf-vars=/path/OVMF_VARS.fd

Test

zig build test            # host unit tests (the platform-independent shared code)
python3 test/qemu_test.py  # QEMU integration tests: boots the kernel and asserts
                           # on its serial output (see docs/testing.md)

The integration harness builds and boots the kernel once per test case, checking memory, the frame allocator, paging (incl. NX and the null guard), the heap, interrupts, and exception handling. It exits non-zero on any failure, so it drops straight into CI.

Documentation

Design notes explaining why behind the code live in docs/ — start with docs/README.md.

For the hardware needed to run DanOS — minimum specs plus a plain-language guide matching Intel/AMD CPU generations by name — see docs/system-requirements.md.

San Serif Text "Dan OS" with a black karate belt around it.