Hacker News Reader

Hacker News

Comment by hamandcheese | Hacker News Reader

Full thread

hamandcheese

I’d be interested to see performance comaprisons between this and Go on a Linux variant.

Aside from performance, what are the alleged benefits of a unikernel? Security?

View on HN

I agree. The performance difference is critical.

Other wise - just have a slimmed down OS with ACLs.

Is anyone running JVM on a slim OS? http://unikernel.org/projects/ seems to have quite a list OSv ? mirageOS?

Squawk[0] ran pretty much directly on the hardware, Sun had a JVM-on-Xen project, OSv provides a lightweight pseudo-OS (not unlike rump kernels it looks) which support JVMs. Possibly one step down, Oracle has a JRockit VE edition which runs directly on the Oracle Hypervisor, but despite being Xen-based it's unclear whether that can run on raw hardware.

[0] https://en.wikipedia.org/wiki/Squawk_virtual_machine

Much smaller attack surface.

Not really. Now instead of having to break the application, then break the kernel it's running under and then attack the VM host, you only have to attack the app and can then go directly at the VM host.

Unikernels just remove a whole security layer. May as well run the app as a user process on the host and forget the VM.

It depends on what you're securing and what the weakest link in your chain is. The assumption is that your app is doing something valuable (i.e. there is value in compromising the app, not just as a means of compromising the host).

Perhaps I should have phrased that differently, but you've reduced the attack surface for compromising your _app_ via the environment (instead of the environment via your app).

(big disclaimer: this is assuming Xen bugs are much more valuable than app bugs and someone with a Xen exploit won't be focusing on you.)

Wrong. Cracking the app does not give you access to the VM host. These apps are running in a VM. There's no relationship at all between cracking the app and cracking VM host.

I believe what zlynx meant was that if you want to escalate from the VM to the host, you usually do that via the virtualised devices. On a normal system, your path (for a web service on Linux) would be:

App exploit (-> LSM breakout?) -> local to root escalation -> VM to host escalation via device.

For a unikernel deployment that's just:

App exploit -> VM to host via device.

Maybe I'm mistaken but it seems to me that the parent's argument was that running your app in a unikernal prevents another app from crapping all over it, ie: root escalation happened in an adjacent app and now your app is at risk.

It does move the hypervisor up a few levels of abstraction, which could be dangerous, but (more to the point) the benefit is isolation from other misbehaving apps.

unikernels do not have to run in ring 0 although a lot of early ones did. You can run them in ring 2, and they probably never need ring 0 access after boot so there does not have to be any way to return.

Good luck getting RCE in Ocaml.

Reply on news.ycombinator.com