Monolithic microkernel (clicky!)

[Love4Boobies]

I am aware the subject for this thread is kind of weird, but let me explain what I mean by all this.

I'm sure everyone here's aware of Singularity's SIPs. I will discuss here a design inspired by that (to some very small extent) and by the experience I've had in compilers and language design so far (which alas, isn't much). I have designed a typed assembly language that targets the x86 instruction set (at least a subset of it). Having this designed, I thought it might prove quite useful in OSDev. So here's what I came up with:

I'm thinking of creating a compiler (I'll probably need to design a high-level language fit for it) that would target my typed assembly language and build everything in a monolithic fashion, yet provide isolated processes for the memory manager, file system, etc. thanks to the assembly language. Processes would still run at ring 3. So what's the catch? I actually see this as a fancy way of creating a reliable monolithic kernel. It WON'T have the flexibility a microkernel has because changing the file system code with your own WILL work (in the end it's still x86 code), it will just behave like a regular monolithic kernel.

All of this should work just fine with any high-level (Java, C#, etc.) language compiler as long as it compiles to x86 and not CIL or Java bytecode or whatever. Comments?

[earlz]

I don't get it..

[Love4Boobies]

The idea is that anything written in this typed assembly language won't reach anything outside its given address space. Thus say a bug in the file system won't bring down the kernel or anything else although they're all running together in ring 0. Applications run in ring 3.

[earlz]

ah.. Nice idea.. the only problem I could see then is speed and what if the compiler has a bug in it that lets you access outside space? it would be pretty fatal if a hacker got hold of it..

but really, I thought of doing the same thing though as a JIT approach.. too much effort for me though lol.. but really sounds like a pretty good idea if it can work right.

[Love4Boobies]

JIT is either too slow or inefficient. A bug in a compiler can't bring down the whole system because it comes down to the assembler, not the compiler. A hacker should only have access to ring 3, since he would be an application developer. If he decides to write a malicious driver and use that instead of the default one, it's pretty much the same thing as it is for monolithic kernels.

However I'm not talking about a pure monolithic design here. Drivers will probably run in ring 3 as well. But other critical parts (like the memory manager, file system, IPC) would be inside the kernel.

[JohnnyTheDon]

[quote="Love4Boobies"]JIT is either too slow or inefficient. [quote]

JIT compilation doesn't have to be slow, and if implmented properly it can be faster than normal compilation at runtime. Programs using JIT compilation can take advantage of all of a processor's extended features (like SSE) and be optimized for a specific processor without breaking compatibility with other machines. It also allows the user to optimize code for their purposes, such as setting the ammount of runtime checks to trade off stability and performance. Users would also be able to customize how the operating system works. For example, a user might decide to put all of the drivers in userspace, or all in kernel space, or make groups of drivers that talk with each other frequently and have them share address spaces (but be seperate from other groups of drivers and the kernel). IPC between the drivers in the same address space could be reduced to simple function calls.

But in general, good idea. I'm implementing something along the same lines myself, but I've been emphasizing JIT compilation.

[Colonel Kernel]

Singularity can run in the configuration you describe, with all OS services and drivers running in a single ring 0 domain, and each app in its own ring 3 domain. They all still run in SIPs and communicate via IPC.

IMO SIPs make the usual ring0/ring3 distinction orthogonal to the issue of whether the system is monolithic or micro.

Also, do you have a formal model of your typed assembly language and a proof of its soundness and type safety?

[Love4Boobies]

Singularity can run in the configuration you describe, with all OS services and drivers running in a single ring 0 domain, and each app in its own ring 3 domain. They all still run in SIPs and communicate via IPC.

The difference is that it's still managed code, whereas mine is pure x86 code.

Also, do you have a formal model of your typed assembly language and a proof of its soundness and type safety?

Sure. I'll put up a link as soon as I get home so whoever's interested can check it out.

[Colonel Kernel]

The difference is that it's still managed code, whereas mine is pure x86 code.

At runtime, it's all x86 code. Singularity doesn't do any JIT. From what you've said so far, it looks like the main difference in your system is where the type-safety verification happens. For Singularity, it happens on the MSIL that is fed into Bartok at compile-time. They also intend to move to typed assembly language so that the native code could be verified after compilation by Bartok, but the last I heard this was a hard research problem, which leads us to...

Also, do you have a formal model of your typed assembly language and a proof of its soundness and type safety?

Sure. I'll put up a link as soon as I get home so whoever's interested can check it out.

If this is for real, maybe you should consider applying for a job at MS Research.

[Love4Boobies]

The difference is that it's still managed code, whereas mine is pure x86 code.

At runtime, it's all x86 code. Singularity doesn't do any JIT. From what you've said so far, it looks like the main difference in your system is where the type-safety verification happens. For Singularity, it happens on the MSIL that is fed into Bartok at compile-time. They also intend to move to typed assembly language so that the native code could be verified after compilation by Bartok, but the last I heard this was a hard research problem, which leads us to...

In Singularity applications also need to be managed. In my design they don't since they run in ring 3. This is a way o fixing compatibility problems with existing applications, as I see it.

[Colonel Kernel]

In Singularity applications also need to be managed. In my design they don't since they run in ring 3.

The definition of "managed" gets a bit fuzzy in this kind of architecture. Do you mean applications in Singularity must use garbage collection...?

As I said, it is possible to have ring 3 domains in Singularity as well. While support for native code without GC has not been implemented (to the best of my knowledge), it would be possible to run it in such a domain.

BTW, do you plan to have a garbage collector in your kernel? If not, how do you guarantee type-safety for the components that run in ring 0?

[Love4Boobies]

The garbage collector is a trusted file that needs to be linked in with the assembled program, together with a small runtime. I can give more info on this but I still need to dig deeper into a few issues. Will try to write more ASAP.

[Benk]

I still dont understand how this will work in practice. Singularity could easily run x86 unmanaged code in ring 3 user processes however they dont ( though Midori probably will) .

The whole problem with unmanaged code is it is impossible to verify unless you remove pointers and do not allow self modification. At this point you almost have a managed language and adding the GC removes a whole class of bugs . Managed code reduces a whole class of bugs and in the case of Sing. even allows OS inlining as it knows its safe and hence is typically fast enough.

Now a Singularity style Monolothic kernel kind of makes sense and could prob run everything at ring 0 as you can choose to only expose certain strongly typed interfaces - instead of the piped messages, it would be fractionally faster however if a sub system failed you cant easily restart it. Also note device drivers are responsible for over 60% of OS failures ( and faulty hardware is most of the rest) are you still going to have native device drivers in the kernel ? Sing . has managed device drivers and all there IO is controlled through the HAL ie they cant touch the hardware themselves.

Ben