SeoulOS (sos) architecture

seoulos.md

SeoulOS

SeoulOS (SOS) is a toy microkernel project, with the core written in a mix of ASM and rust. Pretty much everything is done in modules, which plugin to the kernel via some kind of socket

Goals

1. I'd like to learn a bit of rust
2. I'd like to expand on BambiOS, the kernel/OS I built to display which flightcase records in my collection live in)
3. I'd like to build a microkernel- they seem cool, and I reckon the potential of an operating system running on many nodes is cool
4. I'd like to find a way of running kernel code in go
5. I reckon modular kernels, with lots of unit testing, is the way to go

Core

• Core contains routing for interrupts
• When a plugin starts, it registers a list of interrupts it wants to know about
• When an interrupt occurs, core will lookup the relevant interrupts and pass them on
• Core also routes systemcalls in the same way
• Core also implements a klog call which spits kernel log messages

Plugins

• We use the word plugin, because words like 'kernel module' and so on have different meanings in many other OSes, though they all largely refer to chunks of code that the kernel runs inside its self (maybe not with Plan9 which helps make my point, I think, about ambiguity of terminology), whereas we have specific, different processes
• Plugins can be written in any language (kinda- I want to sign plugins, which may be difficult. Perhaps interpretters also need signing)
• Core starts an initial set of plugins which are compiled into the core binary, including display, disk, process drivers (with an init path, perhaps)
• We sign plugins in some kind of simple manner (I want to avoid writing complex signing code); the trusted signatures are baked in, too

Plugin boot process

• When a plugin starts, it makes a SYSCALL requesting a sos_kernel_sock, passing in the process ID of the caller
• Core validates the PID is from the correct caller, and validates the signature of the binary on disk (based on the binary assigned to the process, which is immutable)
• Core assigns and returns a file-handle
• Plugin sends a set of interrupts and syscalls it wants to subscribe to, and a set of capabilities (should it be able to write to disk, or network for instance- this should pretty much be no)
• Core returns true, or kills the process (if, for example, requested capabilities are too high, or masked syscalls/ interrupts (there are some things, I reckon, that we will never want to allow plugins access to- certainly non-initial plugins)

Build Process

• Stuff like initial-plugins (disk, network, security, process, whatever), the path to an init process, capabilities, and a set of initial keys to trust are built in at compile
• We require a 'build-sos' script/tool which can be run to handle this stuff (pull some source, build)