100 lines
5.0 KiB
Markdown
100 lines
5.0 KiB
Markdown
# 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](https://kernel.org): A highly featureful monolithic kernel, with
|
|
support for namespacing different kinds of resources.
|
|
- [The seL4 Microkernel](https://sel4.systems/): Formally verified, capability
|
|
based microkernel, setting the gold standard for secure kernels. Capable of
|
|
hosting virtual machines as well as normal processes.
|
|
- [Redox OS](https://www.redox-os.org/): Linux-compatible microkernel, written
|
|
almost entirely in Rust.
|
|
- [Fuchsia's Zircon Kernel](https://fuchsia.dev/): 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.
|