Suppose I want to build an operating system based on a very small native lower kernel that acts as a managed code interpreter/runtime and a larger upper kernel compiled to a non-native machine language (Java bytecode, CIL, etc.). Examples of similar operating systems would be Singularity and Cosmos.

What pitfalls and development challenges exist writing an OS with this sort of infrastructure in contrast to a purely-native solution?


2 Answers 2


Depending on the language, there can be many development challenges:

  1. Pointers: If a language doesn't have pointers, it will be a challenge to do relatively-easy tasks. For example, you can use pointers to write to VGA memory for printing to the screen. However, in a managed language, you will need some kind of "plug" (from C/C++) to do the same.

  2. Assembly: An OS always needs some assembly. Languages like C#, Java, etc. don't work so well with it, unlike C/C++. In C or C++ you can also have inline assembly which is very, very useful for many tasks. There are MANY cases where this is needed (examples in x86): loading a GDT, loading an IDT, enabling paging, setting up IRQs, etc.

  3. Control: If you are using something like Cosmos, you aren't having full control. Cosmos is a micro-kernel and essentially "bootstraps" your "kernel". You can implement something like Cosmos from scratch if you really wanted to, however, that can take a long, long time.

  4. Overhead: With managed languages, there is A LOT of overhead compared to C or even C++. Things like Cosmos need to implement a lot of things before even a C# hello world kernel can be run. In C, you are ready to go, no real setup needed. In C++, there are just a few things that need to be implemented to use some of C++'s features.

  5. Structures: In C/C++ there are structs which many managed languages do not have, and so, you would need to implement some way of having something like a struct. For example, if you want to load a IDT (Interrupt Descriptor Table), in C/C++, you can create a struct (with a packed attribute), and load it using the x86 ASM instruction lidt. In a managed language, this is much harder to do...

Managed languages, syntax-wise, are easier, however, for many OS related things are many times not very-well suited. That doesn't mean they can't be used, however, something like C/C++ are often recommended.

  • $\begingroup$ This answer is pretty weak. What are the “relatively-easy tasks” that you can't do without pointers (excluding a tiny foundation)? What are the parts that need assembly? What control do you lack? What do you base your statement about overhead on? Why can't you have structures in a managed language? $\endgroup$ Aug 20, 2014 at 10:41
  • $\begingroup$ 1. There is no reason why a managed language wouldn't offer the ability to access VGA memory, it's only the mapping/unmapping that would have to be provided as a primitive (a memory management primitive). 2. Some task switching (e.g. saving registers) typically has to be done as assembly code, but it's very localized, it isn't an argument against having 99% of the OS in a managed language. Manipulating the MMU is a memory management primitive. 4. C needs setup too (set up a stack and heap); managed languages need a bit more setup but there is no qualitative difference. $\endgroup$ Aug 20, 2014 at 11:44
  • $\begingroup$ @Gilles, the question is what are developmental challenges for using a managed language. These are developmental challenges, however, you can still successfully overcome such challenges... $\endgroup$
    – mmk
    Aug 20, 2014 at 12:23

I have heard it claimed (by a researcher working on a competing microkernel technique) that very little is known about how to evaluate security of systems that are extensible through managed code.

The problem is that the kinds of bugs that might cause a security hole are very different than security researchers are used to. In a traditional microkernel all the drivers and other subparts of the kernel are isolated from one another by running them in different address spaces. In a microkernel where the isolation is implemented through type checking managed code you avoid the enormous overheads of switching address spaces every time you need to use a sub-service, but the tradeoff is that now evaluating the isolation mechanism is more difficult.

Any particular part of the kernel (say a device driver) written in the managed language is safe if and only if the type checker says the driver is safe and the type checker has no bugs. So the type checker is part of the kernel core. In practice it seems that type checkers are considerably larger and more complicated than are traditional microkernel cores. That means that the attack surface is potentially larger.

I don't know whether traditional micro-kernel isolation techniques or managed-code based isolation techniques are really more or less reliable. There's a bootstrapping problem here: until managed-code isolation techniques are widely used, we're not going to know how often they are insecure. But without knowing how insecure they are, it is difficult to deploy them in situations that are security critical.

  • $\begingroup$ That's an excellent point. $\endgroup$
    – Adam Maras
    Aug 20, 2014 at 18:09
  • $\begingroup$ I find these arguments very strange. (Granted, I may be biased by my background in formal methods, but this is not the only basis for my opinion.) A typechecker is not so complex, compared with a microkernel plus an MMU. For example, Coq's microkernel is about 14kLoC of OCaml — bigger than a microkernel, but not by all that much, and written in a language that is less error-prone than most kernels (no C or assembler). Type checkers are not susceptible to race conditions, which are a particularly subtle class of bugs. $\endgroup$ Aug 20, 2014 at 19:06
  • $\begingroup$ Managed code gives a better opportunity to handle certain class of bugs; for example, information flow analysis can prove the absence of side channels (it's likely to take a lot of work, and I don't know to what extent it's been done, but it's doable in principle), whereas hardware isolation only lets you test the side channels that you've thought of. $\endgroup$ Aug 20, 2014 at 19:07
  • $\begingroup$ On the practical side, several virtual machines providing isolation have been certified at EAL5 and up. Here are two examples that you may well have in your wallet if you're European, because they are used in smartcard such as credit cards: MULTOS, Java Card open platform. In the security evaluation community, I've heard many doubts that MMU isolation could go beyond EAL2. $\endgroup$ Aug 20, 2014 at 19:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.