shibedrill/gila
shibedrill/gila
1
0
Fork 0
Code Issues 3 Pull Requests Actions Packages Projects 1 Releases Wiki Activity
f0177d2d4d
gila/docs/DESIGN.md
August f0177d2d4d
Some checks failed
Continuous Integration / Check (push) Failing after 3m23s
Details
Continuous Integration / Clippy (push) Failing after 2m12s
Details
Memory investigations
2026-03-16 21:27:47 +00:00

5.0 KiB
Raw Blame History

Design Outline

Gila is a microkernel, and almost all functionality of the OS is relegated to "server" processes. A server is a process that provides a specific functionality. The means by which processes will locate services is still up in the air as of right now, but I believe I want to implement something similar to (if not compatible with) D-Bus.

Development Goals

  • No custom tooling: Gila should compile, build, and run, without any custom languages, syntaxes, formats, emulators, build tools, frameworks, compilers, etc.
  • Easy to work on: Gila should be easy for developers to understand- not just the kernel itself, but the way userspace works together, and the way an ISO image is built by the build system. I want people to be able to easily write, compile, install, and run a program within a bootable ISO.

Inspiration

  • Linux: A highly featureful monolithic kernel, with support for namespacing different kinds of resources.
  • The seL4 Microkernel: Formally verified, capability based microkernel, setting the gold standard for secure kernels. Capable of hosting virtual machines as well as normal processes.
  • Redox OS: Linux-compatible microkernel, written almost entirely in Rust.
  • Fuchsia's Zircon Kernel: A new kernel and OS by Google, which aims to replace the Linux kernel within Android. Features a really cool component model for applications/system services.

Boot Process

After being initialized by the bootloader at a random address, the kernel will perform some memory management work to start allocating memory for the Userboot binary. Userboot is a binary executable that will be loaded as a module, and it will be initialized as the very first process.

The Userboot concept was taken from the Zircon kernel, used in Google's Fuchsia OS.

Userboot has only one job, and that is to parse the compressed initramfs image and start the true init system based on the contents of that image. After that, it can exit. This approach eliminates a lot of code from the kernel, since we don't have to parse ELF files or perform decompression in-kernel.

The init system will rely only on a small set of kernel & userboot APIs to bring up other "system software". Userboot will be treated as a part of the kernel, effectively, allowing the user to build userspace initramfs archives without having to recompile the kernel.

The benefit of this approach is threefold:

  • The system does not need to include a filesystem OR disk driver, if neither the disk nor the filesystem are read or written.
  • The driver or filesystem server can crash, and the whole stack can recover.
  • The user or developer can trivially introduce new drivers without a reboot. This goes for filesystem drivers AND disk device drivers.

The system, hence, can be configured in two ways:

  • The drivers can all be included in the initramfs for diskless operation.
  • The bare minimum drivers needed for disk access are included in the initramfs, and all other drivers are included in the root filesystem.

Integration as a Full OS

Gila is just a kernel. It does not do much outside of scheduling and memory management. To make it useful, you must provide a correctly versioned and formatted initramfs image as a boot module, and include it in the ISO.

The structure of the initramfs will soon be formally defined, and Userboot will handle parsing it and confirming it is a valid and compatible version before initializing the full operating system from its contents.

My ideal vision of an OS built on Gila is composed of several "realms", or privilege levels, which define how information may flow within the system.

  • Realm 0, "Kernel Realm", consists solely of the kernel.
  • Realm 1, "Driver Realm", holds device drivers and protocol/filesystem drivers. This realm provides a solid hardware abstraction layer which the service realm may build upon. This is where I would choose to place a memory allocator & any standard library implementations, developing them as a part of the driver realm.
  • Realm 2, "Service Realm", contains components and services that rely on the driver realm or the standard library. This may include things like access control, user management, application management, and standard APIs for applications to access. This is the software abstraction layer, or framework layer.
  • Realm 3, "Application/User Realm", contains processes, applications, and libraries that are totally untrusted. To perform any functionality they must correspond with the Service Realm so it can enforce security policies. Anything which can reasonably be written as an unprivileged application should be one, to allow for the best isolation and security boundaries.

This structure works well with the Biba security model, which dictates how information must or must not flow between privilege levels to preserve integrity. No realm may write data to any realm above it, and no realm may read data from any realm below it except to arbitrate communication between components within the same realm.