So, uh, who cares if you can run ring 0 code in a unikernel? You get full “administrative access” to the little toybox of the unikernel. What are you doing to do? How is that any different than running ring 3 code on a normal system?
Also, what system actually uses rings 1 and 2 for device drivers? That sounds like it was copied out of some 1980s textbook.
Right, isn’t the whole point of the unikernel idea to move the administrator charade up a level of abstraction, anyway?
I hear being insulting to pretty much everyone is a great way to send a point across. Or at least to look brilliant to everyone who has no real idea what the guy is talking about. Surely, some headhunters would be titillated by this at least. If all else fails, one can always assume that it made him feel better to put that in writing somehow.
Unfortunately, while @tedu is being brusque he’s also correct.
As pointed out in other comments here, there is no real benefit to pwning a unikernel over pwning a sandboxed application. Further, there is perhaps some wisdom in slamming a hit piece on unikernels by somebody who is a veep at EMC, a company *who derives significant revenue from containers and VM technology.
I personally think that unikernels are a silly idea for a number of reasons–least of all because you end up with the administration at the hypervisor level and then the hypervisor is basically the OS and then look all we did was define some different abstractions and change names and rearrange the food on our plates–but every criticism in this thread so far, including the “Hey, what kind of FUD are they attempting with the privilege ring diagram?” from @tedu, is correct.
Wait a minute, huh?!
VM-x means we page fault on privileged access attempts for hypervisor inspection. Your hypervisor gets to decide which pages you get to see.
Even if you’re doing software virtualization VMs only see a virtual ring 0 - they’re really in a higher ring, and the same isolation applies.
If you pwn a unikernel, great job - but you’re effectively in a userspace ring (be it a ring 0 guarded by a hypervisor at ring -1, or a ring 1 with a hypervisor at ring 0), and can see… what, everything that the unikernel handles? It’d be no different than pwning a well-sandboxed daemon, you’ve got it and everything it handles, but you’re still blind to what’s above you. You’ve got to attack the hypervisor before you can do anything with all the other unikernels running on the iron. But the assumption is that a hypervisor is a much smaller attack surface than a general-purpose operating system, and should be easier to secure.
PLUS, this doesn’t get into possible mitigations we could work on in the future.
I could take an OpenBSD-esque pledge() approach and make my unikernel immediately promise to the hypervisor that the only thing my app does is DNS resolution and TCP sockets. The moment someone tries DMA, boom, page fault, hypervisor sees a constraint violation and shoots it. Maybe it’ll even spin up a new one for me!
I’m really wondering what Randy Bias is playing at with this article. There’s no way he truly thinks that every unikernel runs in a flat ring 0 space with all other unikernel. I can’t believe that. But unfortunately the alternative is for me to think that he has an interest to try to convince people that they do…
I think this is a good argument against the rumpkernel-approach, whereby lib-netbsd is effectively linked into your app, and your app is basically unix+application all running as root. That’s bad. I think this will be the most common kind of “unikernel” made – the kind that springs from CV-driven development.
However, a lot of unikernel designs can introduce an element of compartmentalization that is very difficult with lib-netbsd: I’m using a unikernel on systems with just virtio-networking (i.e. no block devices) so exploitation would allow someone to generate arbitrary packets, and send messages to my other machines. The former is Amazon’s problem, and the latter is a problem I have to deal with anyway, so I’m balancing this with having a bigger system, that boots slower, and might already have a lot of the infrastructure to run their prebuilt exploits. It is in this way I argue unikernels can be more secure than traditional operating systems, but it is also in this way that I appreciate that in practice, they might not be.
PoC || GTFO
Any buffer overflow could mean …
For the most part, those pushing unikernels are also pushing memory-safe languages.
[Comment removed by author]
Just as there are risks of various other kernel exploits in a traditional model. Security is a holistic game. In terms of memory-protections, uni-kernels may be one step backwards, but memory-safe languages are three giant leaps forward.
This is premature FUD on research tech that won’t hit production for years. These are not real concerns. The author doesn’t know how computers work.
It’s not wrong though. For all the article talks about threat models and rings, it does a very poor job of synthesizing those facts in a way that demonstrates understanding of the security risks of uni kernels.
Part of the reason why I like lobsters is that when the articles aren’t strong the comments are.
Literally the definition of fear, uncertainty and doubt.
There may be security problems with unikernels, the main one being that the (re)implementation of things like SSL isn’t as battle tested as what we have now. I’m not saying it’s a strong argument, but it is an argument.
The author on the other hand comes across as fairly incoherent. There was a lot of talk of buffer overflows which is incongruous with the push for unikernels in memory and type safe languages like Ocaml.