OSDev.org

What is this?

So, I'm going to be writing a kernel over the next several months. I am doing this for a school project, with the following goals in mind:
Hybrid Kernel
Single user, multitasking (will be using a dynamic multilevel feedback queue)
(mostly) Posix compliant.

To provide an overview of my hybrid kernel design:
- Drivers run inside of userspace
- Process Scheduling and Memory Managing are done inside of kernelspace.
- File System is inside of kernel space.
- Message Passing System to communicate with drivers.
- Drivers will be mountable and unmountable like a filesystem. Only root can mount and unmount drivers, and they go inside of a new folder '/drivers'.

When I say drivers run inside of userspace, I mean that _all_ drivers will run inside of userspace. Now, the kernel will ship with a default tty driver, etc. but that will be running inside of the userspace.

So far I have done a lot with memory management. When I'm done with that, I'm going to move on to the rest of process management. The kernel will facilitate the message passing system.

Why a hybrid kernel?

In the future I will be using my kernel for robotics projects, which will have many different programs piping data to eachother (I'm a UNIX man, I like that way of doing things) and I need it to be _guaranteed_ that the process manager and file system will live no matter how misbehaved a driver might act. The worst case scenario is that a driver crashes, I get an error message, and then worry about fixing that driver when I need to. I can't have the risk of my kernel space being corrupted by a bad driver when I'm going to be working with tons of different hardware.

Thoughts?

You do realize what you are talking about is more akin to a microkernel?

Note that even if the driver can't directly attack the kernel, it can likely send malicious requests to the hardware (such as setting the HaltCatchFire register to nuclear).

Note that even if the driver can't directly attack the kernel, it can likely send malicious requests to the hardware (such as setting the HaltCatchFire register to nuclear).

The point of it isn't to protect against attacks, it's to protect against bad/stupid driver code being executed at ring 0.

madmax wrote: - Drivers run inside of userspace
- File System is inside of kernel space.

Wait, why?
File system is not even a driver, it's just an interface that uses a driver and a bunch of additional interpretation of what driver returns to give you access to files. If you have drivers in userspace, filesystem can also be there, or even be a loadable library for the applications.

My thinking is that (from a stability standpoint) having a known filesystem (probably Minix's) implemented in Kernel Space will be more stable. Would that be an incorrect assumption?

madmax wrote:My thinking is that (from a stability standpoint) having a known filesystem (probably Minix's) implemented in Kernel Space will be more stable. Would that be an incorrect assumption?

Where drivers and file systems are implemented, kernel or user space has nothing to do with stability with drivers themselves as both can fail regardless. Having a driver or a file system in user space can have a few advantages though, that it can be restarted if it crashes without restarting the entire OS, development might be easier as it resides in user space process, debugging might be easier.

In popular operating systems like Windows and Linux, there is a trend to move functionality into user space.
Examples.
FUSE (Filesystem in Userspace)
Windows, sound drivers to user space among many more (happened a while ago)
LibUSB, which is a USB driver interface library running in user space.

As performance allows it, the trend to move drivers to user space will continue.

madmax wrote:My thinking is that (from a stability standpoint) having a known filesystem (probably Minix's) implemented in Kernel Space will be more stable. Would that be an incorrect assumption?

Yes. About the first thing you want to move to userspace is the filesystem code, because the complexity of it and the many caches and pointers is what primarily threatens the stability of your kernel.

madmax wrote:My thinking is that (from a stability standpoint) having a known filesystem (probably Minix's) implemented in Kernel Space will be more stable. Would that be an incorrect assumption?

Well, filesystem is probably the best one to easily trash your kernel memory space.

Imagine not checking sufficiently the superblock data you've read from disk and then following a pointer, this can easily lead you to overwrite some important data.

So as far as development goes, the best way is to put everything in user space - this way it will be almost trivial to catch many memory errors, and whatever is left uncaught will only crash that single user space process, which you can then dump, analyze and restart.