Linked by Hadrien Grasland on Sun 20th Feb 2011 13:20 UTC
OSNews, Generic OSes Now that you have an idea of where your OS project is heading as a whole, it's time to go into specifics. The first component of your OS which you'll have to design, if you're building it from the ground up, is its kernel, so this article aims at being a quick guide to kernel design, describing the major areas which you'll have to think about and guiding you to places where you can find more information on the subject.
Permalink for comment 463660
To read all comments associated with this story, please click here.
VM Based Kernel
by Alfman on Wed 23rd Feb 2011 08:12 UTC
Member since:

I am absolutely delighted that my suggestion to use a type safe language to provide isolation got attention in the "VM Based Kernels" section.

"The kernel must include a full featured interpreter for the relevant language, which means that the codebase will be huge, hard to design, and that very nasty VM bugs are to be expected during implementation."

Yes, a type safe VM language will require more work than simply using a traditional compiler.

As for devel effort, with any luck we wouldn't have to completely re-invent the wheel and could use existing VM implementations like Java or Mono. Writing a VM from scratch would be a ton of work - even if it has merit.

I think the term "interpreter" mis-characterizes the approach. A type safe language capable of isolation is not dependant on being interpreted, it can use JIT and pre-compilation too.

"Making a VM fast enough that it is suitable for running kernel-level code full of hardware access and pointer manipulation is another big programming challenge."

As discussed in the earlier comments, I don't think the type safe language would imply any overhead overhead over a correctly implemented unsafe-language version. All we require are safe language constructs which map efficiently over top of the underlying hardware like (memory mapped devices, port IO, DMA).

"A VM running on top of bare hardware will be harder to write, and thus more buggy and exploitable, than a VM running in the user space of an operating system."

This depends on how deeply integrated Java/Mono are with external dependencies (such as pthreads, or libc, or syscalls). Since I don't know the answer, I'll let the criticism stand.

"Currently, the Java Virtual Machine is one of the biggest sources of vulnerabilities in existence on desktop PCs."


Also, remember that, unlike a web browser sandbox, the kernel/VM isn't required to protect from maliciously altered kernel modules (untrusted code). It only needs to ensure that modules written in type safe code remain isolated.

As long as the compiler only produces in-spec modules, then we can reasonably get away with a VM which produces undefined results for out-of-spec modules.

Features I thought about for my OS many years ago:

It would be very nice to have support for clusters within the OS, such that you could take any running application and migrate it to another node while continuing to run. Similar to what VMware/KVM/Xen do, but would work with arbitrary applications.

Every single kernel interface should have the ability to be virtualized such that all interfaces on PC-A could be transparently redirected/aliased on PC-B without explicit support for this within the drivers.

PC-A: soundblaster, webcam
PC-B: remote alias to peripheral devices from PC-A

This would go hand in hand to make the application migration feature seamless.

This also means that all local applications could bind to remote devices transparently without being explicitly written to do so.

Other thoughts:

I hope you're not planning on copying the *nix signal model, it's pretty bad for modern requirements.

I also hope you opt for an asynchronous IO design within the kernel over a threaded IO design. This has been one of the weaknesses plaguing linux for years.

While Posix plays an important role in compatibility and standardization, it's a major impediment to revolutionary designs. Therefore I think strict Posix compliance should be an explicit non-goal, particularly with regards to fs permissions and some of the braindead APIs.

Now if only someone would employ me to work on these things... Is anyone else here woefully under employed?

Reply Score: 1