5a5146ec13
SMAP makes the rule the copy layer has followed since it was written into a rule the hardware keeps. A ring-0 read or write of a user page now faults, so any code that reaches for a user pointer directly fails the first time it runs rather than the first time someone attacks it — and the suite becomes the enforcement test, because every case exercises the kernel with the bit on. Nothing had to be fixed to turn it on, which is the retrospective proof that the nine stragglers converted earlier were all of them. The interrupt entry needed one instruction first. Hardware does not clear the alignment-check flag on its way into a handler, and ring 3 sets that flag freely, so a process could have taken an interrupt with SMAP suspended for the duration. The system call path was already covered — its flag mask clears it — but the interrupt path needed a `clac`, which cannot simply be assembled in: it is an invalid instruction on a processor without SMAP, and danos boots on those too. So the entry ships as a three-byte NOP and is patched at boot, through the physmap, because the kernel maps its own text read-only. The ordering that makes that safe is enforced rather than described: the patch sets a flag, and no core will set the SMAP bit until it is true. A translation that fails, or bytes that read back wrong through the address they will actually be fetched from, leave the machine unhardened and saying so — which is the same posture the IOMMU takes, and better than enforcing over an entry path that cannot comply. The patch runs before interrupts are enabled and before any second core exists; a comment says so, because the three bytes pass through an encoding that must never be executed and a future change that moves this later has to deal with that first. Suite 114/114, with a case that reads a user page from ring 0 and requires the fault, and the multi-core case asserting every core that ran work had the bit — the same shape SMEP got, for the same reason: CR4 is per-core, and a hardening is only as wide as its narrowest core. |
||
|---|---|---|
| boot | ||
| build | ||
| build-support | ||
| docs | ||
| library | ||
| system | ||
| test | ||
| tools | ||
| usr/share/fonts | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| README.md | ||
| build.zig | ||
| build.zig.zon | ||
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 orzigupwill pick up.zig-versionautomatically. - QEMU (
qemu-system-x86_64) — to run and test the kernel. On macOS,brew install qemualso bundles the OVMF firmware below. - OVMF UEFI firmware — the
edk2-ovmfpackage (Arch),ovmf(Debian/Ubuntu), oredk2-ovmf(Fedora); on macOS it ships inside the Homebrewqemuformula. 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.
Logo
San Serif Text "Dan OS" with a black karate belt around it.