
Unikraft Unikernel Project - iou
https://www.linuxfoundation.org/press-release/xen-project-introduces-unikraft-unikernel-project/
======
andreynech
Huge efforts and a lot of time was spent to develop multi-user, multi-
application infrastructure (aka. standard kernel, FS, networking, etc.). The
reason was to offer reusable functionality for applications on top of it to
get the most out of hardware. Now they start building exactly in the opposite
direction by packaging everything in one artifact where probably the most
content will be duplicated (multiplied). Somehow I am failing to see how it
should improve/increase/advance/blah/blah...

~~~
catwell
There are use cases where users run several applications on a single machine,
which could even be shared by several users. They are the desktop PC, mobile
phone, old school Unix server...

Now we see a use case (call it "microservices" if you want) where people want
to run a single application as if it was alone on a machine, and where the
concept of "user" doesn't even make sense.

This second use case is what unikernels are for. It may make a lot more sense
to run a Unikernel application on an hypervisor than a whole OS in a VM, and
probably than a container too.

~~~
xj9
hwvirt is what most people think of when you say "virtualization", so they try
to compartmentalize things at that level. i don't see why Xen/KVM/whatever is
fundamentally more secure than something like Illumos Zones or FreeBSD Jails.
Linux, unfortunately, doesn't think that way, but that doesn't mean it _can
't_.

i think osvirt is a more efficient abstraction, but the industry clearly has
other ideas.

~~~
aassddffasdf
It's more secure due to automatic address space layout randomization. In fact,
it's both space layout and space content randomization-- each
application/kernel is unique.

~~~
xj9
if your kernel is doing ASLR correctly, i'm not sure doing it _again_ in each
virtual kernel will meaningfully increase the entropy of the memory layout.

~~~
aassddffasdf
Also, there is no kernel but the unikernel itself in such systems. So no idea
what you mean by _again_ here.

~~~
xj9
that would be true if the unikernel was running alone on bare metal, but the
more likely case is that you are deploying multiple unikernels on top of some
hypervisor.

in the case of Xen, you will have linux or *bsd in dom0 which will probably
have aslr enabled. so, when you launch your unikernel and do aslr you will be
randomizing an already random memory layout.

my point of contention is with the hypervisor+unikernel model. once you try to
increase the tenant density of a particular piece of hardware with
virtualization you lose most of the advantages of removing the os and re-
introduce the complexity in a different way.

