Desert Spring-Time (DST) is an OS based on the OCaml runtime+native code compiler. Their goal is to build a robust system through extensive use of OCaml language features, such as static type checking. Currently, this is only a prototype, and is best tested with qemu. More information can be found here.
Anyone know what benefits might be derived from an OS built with OCaml vise C/C++?
There are a several benefits:
1) Ease of development. Ocaml is a high level language, which means its faster to write code in than a low-level language than C. Being a functional language, its also easier to refactor and retarget code written in Ocaml.
2) Safety. A badly-behaved kernel component cannot trash memory quite so easily. This is particularly important in something like a kernel, where your debugging capability is rather limited. It’s much easier to fix bugs when random, unrelated components cannot overwrite each others’ data structures.
3) Security. Ocaml, being a safe language, also is invulnerable to buffer overflows. Security exploits resulting from buffer overflows are thus made impossible. This is significant, because it is estimated that half of all security exploits result from buffer overflows.
4) Performance. The Ocaml compiler has a fast machine-code generator for x86 that gets performance close to that of C. However, there is a potential to get even faster than that. Because C programs can randomly trash memory, systems go to insane lengths to pretend that each one has the whole system memory all to itself. You’ve got virtual memory, TLBs to make virtual memory bearably fast, privlege levels to allow only the OS to randomly trash memory, and a giant VM in the kernel to support it all. With a safe language, you don’t need any of that.
DST appears to use a microkernel architecture. The cost of this architecture is traditionally the fact that it imposes an overhead for context switches. Now, in a second-generation microkernel like L4, an IPC is about as fast as a system call on other OSs. But its still an order of magnitude slower than a regular function call. Now, I don’t know of DST takes advantage of this aspect of using a safe language (though other OSs have), but it could easily run all Ocaml tasks in a single address space. This not only reduces the cost of context switches, but also allows fine-grained sharing of memory without requiring complex and expensive (in memory and CPU time) mechanisms in the VM.
Most of that post is over my head, but it sounds good. I’m all for OS diversity. Bring it on! Good luck team!
At Microsoft Research, they’re also working on a research OS, written in C#, where all the components (except a very small part) are managed.
There’s a video about it at Channel 9:
http://channel9.msdn.com/ShowPost.aspx?PostID=68302
Very good idea to get Objective Caml more widely known.
This language has a lot of potential !
OCaml has a fast machine-code generator for x86, but not much else. Performance won’t be as good on other archs.
The bigger problem, though, is that delegating protection responsibilities to the programming language means you’re restricted to using only that language for all apps you write.
Actually, the trick would be to decouple the code generator, and building it up from more elementary semantics, then any language which didn’t try to model semantics which would not be supported by the runtime (READ: try to do anything unsafe) would be fine for this environment.
Here, LLVM would likely be quite useful.
Actually it only restricts you to OCaml for kernel coding, not application coding. I think they’re still using a kernel/user-space boundary and not *fully* delegating security to the programming language.
I don’t see a copyright or a license. Is it public domain?
Personally, I’d prefer a GNU license to protect developers, but I don’t really care. Public domain would be nice for a change.
Actually, it only restricts you to using apps compiled with trusted safe-language compilers that take advantage of the performance benefit of having no memory protection. Unsafe apps can still be run in a protected environment, they just suffer a performance hit relative to other apps (though, not relative to regular apps on an unsafe OS).
I’m lovin’ the name!
O’Caml is a multi-paradigm language. That is, it’s an imperative, functional, objective-oriented language. Pick a few random projects from the Hump, and they will more likely than not be littered with imperative programming.
O’Caml when taken with its standard library and FFI are less safe than the core of the language since they provide ways to undermine the type system:
http://caml.inria.fr/pub/docs/manual-ocaml/libref/Printf.html
http://caml.inria.fr/pub/docs/manual-ocaml/libref/Marshal.html
http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html
The O’Caml compiler actually doesn’t necessarily enforce bounds checking, specifically offering -unsafe to disable array and string checking for performance reasons. The infamous Language Shootout compiles with -unsafe for the microbenchmarks.
The performance of O’Caml code varies considerably depending on what aspects of the language are being used, what style you’re programming in, and precisely what it is that you’re doing. For instance, message dispatch in the object system is typically not impressive. Code that would normally make use of all of the bits of a machine word is going to be boxed, and many times floats are boxed. Curried functions are naturally more expensive.
The benefit of being able to use a single address space would require that all of the code was verifiable, or generated in a tightly-constrained manner that would require modification of the language and standard library. Actually using type-safe languages for system programming has been an interesting subject of research for quite some time.
O’Caml doesn’t really have native code dynamic loading, so making shared libraries is basically out. You can dynamically load byte-code but that’s obviously much slower.
There have been efforts:
http://www.boblycat.org/~malc/scaml/index2.html
but they aren’t maintained, portable, or particularly convenient.
There’s a library Dl that basically acts as a small wrapper over dlopen and dlsym that isn’t safe for dynamic loading of shared libraries written in C, but that isn’t the same, either.
Revisions of OCaml frequently break binary compatability, so updating the compiler can mean recompiling a lot of libraries in order to compile programs.