1

The benefit of unikernels is managing a large number of applications in a protected space. (Some might say all the benefits of Docker without all the overhead). (Please don't get me wrong - I'm a huge fan of docker and use it 20 times a day in my work - I'm using this question as a a way to explore an idea).

The following commentator writes:

Another minor point is that outside of memory-managed code execution runtimes (JVM, Go, etc.) the usefulness of unikernels starts to rapidly decline.

Now to me, a server application written in C++ (not memory managed) vs Java (memory managed) has no impact on the utility of a unikernel. In both you get the isolated protected way to manage your application lifecycle. Perhaps I'm missing something.

My question is: What does it mean that "outside of memory-managed code execution runtimes (JVM, Go, etc.) the usefulness of unikernels starts to rapidly decline"?

0

Well, I'm not a big expert on the matter and, in fact, I don't understand the statement. I've read it several times and there is no further explanation, so I cannot say it's make sense or not for me because I just don't know where the idea comes from.

Anyway I'll try to expose what I think here. The main difference about managed and unmanaged code is who is in charge of the memmory management. If it's the developer, we're talking about unmanaged code (C language). If there is a garbage collector or any other similar mechanism, it's managed (Go, Java, .Net platform, Python even bash if you want to consider it!!). So I don't undertand how important is who reserves/frees/whatever the memmory.

And, IMHO, pros of unikernels are supossed to be:

  1. Performance.
    1. Kernel modes are supressed (rings for x86, modes for arm, ...) and the application that will be running in the system, as well as any library needed, is compiled and statically linked into the kernel and the overhead introduced by these mechanism (syscalls basically) are supressed.
    2. Kernel is reduced as much as possible. No USB, bluetooth, support for lots of FS and unnecessary code is just not compiled. Kernel gets tiny.
  2. Security. This is a sensitive topic. Again, I think unikernels are safer than the traditinal ones. If it's a well-done job, there won't be nothing than the minimun functionalities implemented into the system, so this should reduce possible break-points. However, if any is found, this will be more dangerous. Every single process is running by the privileged privileged (and only, multiuser capabilities are disabled in unikernels) user in the system. Privileged Remote code executions can happend. However, it should be in a container-like system. You just can restart it and (in no persistent systems) all the work done by the attacker should be gone (but still an upgrade should be needed...).

As I said, I cannot figure out the reason of this statement, but I think it's related to performance rather than security. In that case, I'm wondering why should be a performance improvement reducing syscalls compared to containers if:

  1. Containers share the running kernel within the host where are running, so syscalls are done just once as there is just one instance of the kernel running.

  2. Unikernels, as said, do not use syscalls and every procces runs in privileged mode (can access the harware directly). But, in this case (I THINK) as far as kernels are different, you need a virtualization layer, so total running kernels are 2. Unikernel has no syscalls but the host kernel does, so syscalls are not supressed and will run once. Of course, I'm assuming that no-one will run a unikernel system on a bare-metal.

So, the number of syscalls should be pretty similar to the containers scenario. Isn't it?

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.