Virtualize at the Runtime Layer
James Larisch, James Mickens,
and Eddie Kohler
Alto: Lightweight VMs using
Virtualization-Aware Managed Runtimes;
Traditional virtual machines, like Xen,
virtualize at the hardware layer. Docker,
on the other hand, virtualizes at the
POSIX layer. This paper suggests a new
approach to virtualize at the runtime layer.
One of the more difficult questions
in this space is how to handle state. In
traditional environments, state for the
file system and network is handled in
the kernel. The authors suggest moving
as much kernel state as possible into the
virtual machine through a user-space
networking stack and FUSE filesystem.
They also suggest explicitly depicting
each state object as an addressable
server (each with its own IP address), allowing operators to easily migrate and
update applications since there is clean
separation of a program’s code, stack,
Through innovations in memory allocation, garbage collection, and managing state, Alto seems to be the closest
solution to securing processes minimally while giving a new set of controls to operators. As someone who has
spent quite a bit of time thinking about
the problems faced by creating a minimal, virtualized container runtime, I
truly enjoyed the problem statements
and solutions this paper laid out.
Deterring Attackers In Your Application
Zhenghao Hu, Yu Hu, and Brendan Dolan-Gavitt
Chaff Bugs: Deterring Attackers
by Making Software Buggier;
Defense of software and systems usually
consists of correcting bugs that can be
exploitable and building software with
more than one layer of security, meaning
that even if attackers penetrate one layer
of the system, they must also penetrate
another layer to discover anything of value. Static analysis of code helps automate
some of this today but is still not a guarantee of software security.
People tend not to take “security
through obscurity” seriously, but there
is some value to the technique. Address space layout randomization is an
example of this approach, however, it
comes at a performance cost.
a hypervisor” ( https://bit.ly/2K5tzNi)
methods are still needed for securely
running those processes that require
the entire syscall interface. Solving
this problem has led to some interesting research.
Let’s take a look at some of the research being done in these areas.
Virtual Machines Versus Containers
Filipe Manco et al.
My VM is Lighter (and Safer)
Than Your Container; https://dl.acm.org/
Containers became popular as an alternative to virtual machines (VMs) because they are better in the areas of fast
boot, small memory overhead, and
allowing high density on a single machine. This paper explores creating
VMs that meet those same requirements, along with the container features of pause and unpause.
Taking into consideration that the
required functionality for most containers is a single application, the authors explored unikernels (minimal
VMs where the operating system is
linked directly to the application) and
TinyX (a tool to create minimal Linux
distributions for an application). The
smaller the VM image is, the smaller
the memory footprint will be and the
faster the image will boot.
For containers, just like a typical process running on a host, the number of
processes or containers you start does
not affect the time to start them, given
the usual caveats about resources not
being infinite, even in the cloud. This
is not true for VMs. The overhead to
start a VM increases as more of them
are run. The authors found, in the case
of Xen, this is a result of both device-creation time and interactions with the
XenStore. The authors implemented
their own LightVM to solve a lot of the
algorithmic and design problems they
found with Xen.
The result of their efforts is mini-
mal VMs that can be booted in as
little as 2.3ms. A standard Linux pro-
cess starts in about 1ms, and a docker
container starts in about 40ms, de-
pending on the size of the image. The
boot time remains constant the more
VMs are launched, which is in stark
contrast to typical VMs. Unikernels,
however, are not as easy to create as
containers and require individual de-
velopment time to be made function-
al for each application.
Isolation of Applications
In a Minimal Way
Dan Williams and Ricardo Koller
Unikernel Monitors: Extending
Minimalism Outside of the Box;
Minimal software has the benefits
of reducing attack surface and making software more understandable
with less overhead. Unikernels are
frequently discussed in the context
of minimal and secure ways to run
programs in the cloud. In the traditional approach a unikernel is a VM
and, as such, is run in a VM monitor,
which is a program that watches and
controls the lifecycle of VMs, such
as VMWare, QEMU, or VirtualBox.
Unikernel monitors are bundled into
the unikernel. This creates a minimal way to boot unikernels without
the added complexity of using a standalone VM monitor.
Most VM managers/monitors are
heavyweight, with features for devices
that are not used in modern or cloud
environments. Take QEMU, for example: it comes with the emulation for
devices such as keyboards and floppy
drives. If there is an exploit in the flop-py-drive emulator, it is game over for
the whole system, even though a floppy drive obviously has no usefulness
in the cloud.
If a monitor is purpose-built for
booting unikernels, its computing
base is much more minimal than the
VM monitors in use today (about five
percent of the size). The authors of this
paper created a monitor that has only
two jobs: creating the isolation to run
the unikernel and performing actions
when the unikernel exits. The monitor is also baked into the executable
for the unikernel, creating a simplistic and minimal approach for distributing and executing unikernels.
The boot time for their prototype
was 10ms, which is eight times faster
than a traditional monitor. This paper has a positive vision of the future,
running applications in a minimal
and secure way in the cloud. IBM recently released a container runtime
called Nabla (
https://nabla-contain-ers.github.io/) around the topics and
implementations of this paper.