Shared publicly  - 
 
Okay folks. We have decided to give G+ pages a try as a blogging tool... We'll start by an article from Lord Glauber of Sealand on the subject of "What about C?". Enjoy

It's been almost a week since OSv has been officially released, and we are very excited about the reception and positive comments we have been seeing. Many people are asking questions, and we plan to answer them all in the next couple of weeks.

Today I want to start with one that is probably the one we have received the most: What is up with the Java thing? Can I run other runtimes? Can I run C?

The short answer is yes, you can. We aim to be as compliant with the Linux interface as we can, so in theory many Linux applications should be able to run unmodified. The main difference, obviously, is that by calling those Linux system calls you won't pay the full price of a system call. Because OSv runs everything in the same address space, it's just a function call away. We also have no users, and a single process. Therefore our implementation can be a lot simpler. Take for instance the following two examples from runtime.cc:

int getpid()
{
    return 0;
}

uid_t getuid()
{
    return 0;
}

So where are the caveats? First, there is one fundamental limitation: because we run everything in a single address space, we cannot run new processes, just new threads. This means we cannot call anything like fork() and vfork(). We currently don't implement clone(), although we could as long as we would error out on the right set of flags. But in any case, the most common interface for thread creation is pthread, and that is supported.

Secondly, we cannot run ELF executables, because, well, we cannot execute any other binaries other than "the one" we execute. So the way OSv execute things is by loading a shared library and jumping to its main() entry point. This means that your program needs to be at least recompiled to generate not an executable, but a shared library.

The last caveat is that the interface is not complete, although this is not only fixable, but will be fixed in the future. As a good example, links are not yet supported by our filesystem. So if your program needs to create links (either symbolic or hard), it probably won't run. We are working on this one but there may be others. If you hit a syscall that is not yet implemented by OSv, you will either receive an explicit error message that the call is not present, or an error message from the loader saying that the symbol isn't found.

We don't keep a list of missing syscalls because we are proudly moving quite fast. If you happen to hit something that isn't there, please report it to us together with the application you are trying to run. Or even better: send us patches. We would be delighted, and I will even pay you a beer if we ever meet in person. Just make sure to warn us beforehand so you don't start working on a duplicate effort.

So provided you are not doing any of the forbidden syscalls, porting your C app to OSv is very simple. Just make sure it is not doing any fork()s and exec()s, recompile it
with CFLAGS="-fPIC -shared" so to generate a shared library, and ... debug. Also, any shared libraries that you use as dependencies would have to be copied to the image.

So what is up with the Java thing? As explained above, C is doable, but not convenient or easy. Java basically allows us to have a stable interface for deploying applications to OSv. They don't have to be changed at all, they don't need to be recompiled, and the interface can be fully supported. The eventual native calls through JNI can be reasonably isolated and - as long as it is not fork()/exec() - is easily supportable without any change. We also foresee a very good path in the future by allowing the JVM to merge a bit more with the OS. By running it in Kernel Space, we can allow the JVM access to facilities such as the page table, more control over used memory and even drive the process of garbage collecting in a more efficient way.

Another advantage is that while an unbounded memory access in a C application would crash your VM (in a normal OS it would crash your app, but for us your app and your VM are pretty much the same. So no, we are not less secure because of that), the JRE can catch those accesses and at least fail gracefully, or in most cases throw exceptions and allow your application to recover. Obviously, Java is not the only runtime out there that can display such properties. It is just one that is commonly deployed in the Cloud in important applications and fits our model quite nicely. We ourselves don't plan to support another runtime, but we would be more than happy to review your patches.

Keep sending your questions, and we'll do our best to answer them
19
4
Avi Kivity's profile photoGlauber Costa (Lord Glauber of Sealand)'s profile photoElazar Leibovich's profile photodor laor's profile photo
8 comments
 
Hi Glauber, thanks for the clear explanation. I would just like to add my two cents that we can run native Linux code (compiled into a shared object) on OSv, but that code does not necessarily have to be written in the C language. Bjarne Stroustrup already wondered (see http://isocpp.org/blog/2013/09/startup-cloudius-announces-osv-a-new-c-open-source-vm-operating-system) if OSv can't run C++ applications. It definitely can! C++ applications, just like C applications, can be compiled with "-fPIC", "-shared", and can be run on OSv. In fact, the JVM itself is a C++ application :-) You can also program in Fortran, Pascal, D, or whatever, assuming (I didn't check) that these respective compilers can also generate shared libraries and export the symbol main().
 
Have you guys tried Mono?  That would be pretty hot for a lot of people.
 
No, but you are the third person to ask. I doubt any of us in the core team will have time for that in the near future, but if anyone would like to give it a try, I think this would be a very welcome addition.
 
Cool, I'll try to get that added to our research queue here, since if it worked it could be a significant resource savings for us.
 
scripting language runtimes (Perl, Python, Ruby, ...) would be pretty cool...
Shawn C
 
sounds nice! I have a few questions about OSv: 1, Is this a independent operating system which compatible with some POSIX interfaces or it's another building block based on GNU/Linux kernel? 2, How OSv security mitigations looks like? Is it use the same concepts such as, stack canary, PIE, ASLR? 3, Does it do use-after-free detection in runtime? Thanks, anyway.
 
Hi Shawn, a few answers:
1. Indeed, OSv is an independent operating system which can run Linux programs but shares no code with Linux (it can't, Linux has the GPL license while OSv has a BSD license).
2. OSv is a young OS, and doesn't yet have all the mechanisms you mention. For OSv's typical use case - running a single JVM - it's not clear they are very important. In any case, all executables in OSv are position-independent, so it's a good start.
3. We have an option of use-after-free detection, yes, but it's not enabled by default. Why are you interested in this feature in particular?
Please join the osv mailing list (osv-dev@googlegroups.com) for more a more detailed discussion :-)
Shawn C
 
hey Nadav, thanks for your explanation. I'm a sec guy, so I'm interested in use-after-free detection feature. I don't know how GNU/Linux or other OS( OSX, windows)'s implementation. One thing for sure, a lot of OS has been suffering from use-after-free-similar vulnerabilities. I'll join the mailinglist;-) btw, I wrote a report on solidot( Chinese slashdot): http://www.solidot.org/story?sid=36649 . Perhaps, post a thread on slashdot is a good idea. What do you think?
Add a comment...