[elysium-developers] Kernel status and design revisited

[Kasper V. L. <ve...@da...>]

To: Elysium Developers
Cc: ely...@li...
[sorry to those of you who receive this e-mail twice]

Since there has been quite a number of new developers during the last 24 hrs
I'll quickly outline the status and design of the project.

The role of the Elysium Kernel is to safely multiplex physical memory,
central processing unit(s), and i/o ports. The kernel should avoid
abstracting away any information or control - from the applications - which
isn't strictly necessary for protection.

1. Multiplexing Physical Memory
-------------------------------
To multiplex physical memory the kernel will hold a table of all physical
pages in the system. Each page may be marked as free or used. If it's marked
as used it will be protected by an associated guard (in form of a
capability). In addition to being free or used the page can marked as being
a page table or a page directory. I suggest these system calls for managing
the address space of a process:

/* set page directory of a process */
int sys_pd_set(uint32_t pd);

/* set an entry in a page directory */
int sys_pde_set(uint32_t pd, uint32_t pde, int e);

/* set an entry in a page table */
int sys_pte_set(uint32_t pt, uint32_t pte, int e);

Of course the process that uses these system calls will have to provide a
capability to access the pages it modifies, but the above mentioned system
calls is just to give you an idea of the current design. Comments are
welcome.

2. Multiplexing CPU(s)
----------------------
To multiplex the CPU we can represent the CPU as a (circular) vector of
quantums. Quantums in this vector should be protected by a guard - as it is
the case for physical pages. A process can allocate any number of free
quantums using system calls like:

/* allocate any available quantum */
int sys_quantum_alloc(int *quantum);

/* set quantum */
int sys_quantum_set(int quantum, pid_t pid);

Again this is just an outline. The scheduling is driven by the timer
interrupt, and works like this:

a) the scheduler picks a process to run
b) the scheduler does an upcall to an agreed-upon program point in the
process
c) the process picks a thread and restores it's stack and registers
d) once the timer interrupt fires the scheduler does another upcall to the
process, but this time at another entry point (also agreed-upon)
e) the process saves the thread context (stack and registers)
f) the process yields to the scheduler, which will start over at (a)

It's possible to build scheduler activations - or any thread scheduling
model - on top of this scheme.

3. Multiplexing I/O Ports
-------------------------
The Intel x86 architecture provides hardware ports - we'll need to multiplex
them in a safe and secure manner. One way would be to protect a range of I/O
ports by means of a guard. A process could then request access to a range of
ports, and if the capability it provides allows access to the ports the
kernel should flip some bits in the I/O permission bitmap of the process.

I know this is probably a bit too vague, but it's meant to be a starting
point for further discussion. Comments, questions, and the like are not only
welcome, but expected!

/Kasper

-------------------------------------------------------------------
Kasper Verdich Lund, Computer Science Department, Aarhus University
Office: 34P.218              | Phone: (+45) 8942 5680
Email:  ve...@da...  | WWW: http://www.daimi.au.dk/~verdich