Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atmanos: Build Go programs that run directly on the Xen hypervisor

github.com

Post reply on HN
Print view View original

11–20 of 56 posts

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#11

Post by masklinn »

yahoo234 wrote: post #9
hamandcheese wrote: post #6

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?

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

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#12

Post by jsiepkes »

md_ wrote: post #5
jsiepkes wrote: post #3

Earlier quoted context omitted.

Well performance aside there is also the benefit of not having to maintaining userland.

What are the overheads of maintaining userland? Not trying to be stupid, but I'm not really clear on what the advantage is of this system. Do I understand correctly that the dom0 OS is still providing drivers and hardware abstraction? So both that and some userland exists somewhere in the stack; it's just not duplicated in the virtualized OSes? Is the main goal simplicity, performance, or something else?

Userland isn't duplicated, it's 2 totally separated userlands. The userlands may be the same distro in case of Xen (for example RHEL 7) but they still lead separate lives; They are different installations. So that's also multiple userlands in which you have to for example deploy patches (RPM's, Deb's, etc.) for your SSH install.

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#13

Post by ComputerGuru »

zlynx wrote: post #10
ComputerGuru wrote: post #7

Earlier quoted context omitted.

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.)

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#14

Post by md_ »

jsiepkes wrote: post #12
md_ wrote: post #5

Earlier quoted context omitted.

What are the overheads of maintaining userland? Not trying to be stupid, but I'm not really clear on what the advantage is of this system. Do I understand correctly that the dom0 OS is still providing drivers and hardware abstraction? So both that and some userland exists somewhere in the stack; it's just not duplicated in the virtualized OSes? Is the main goal simplicity, performance, or something else?

Userland isn't duplicated, it's 2 totally separated userlands. The userlands may be the same distro in case of Xen (for example RHEL 7) but they still lead separate lives; They are different installations. So that's also multiple userlands in which you have to for example deploy patches (RPM's, Deb's, etc.) for your SSH install.

Yes, that's what I meant by "duplicated." :)

And yes, I see some value in the reduction of maintenance costs, but you're not doing this manually--you have a package manager of some sort and you're automatically tracking some standard image (either for your company or from some upstream maintainer like Canonical). So conceptually I get the simplicity argument, but practically speaking, it's not really more work to maintain two userlands vs one, right?

I guess there's also an argument of resource (disk, memory footprint, etc) overhead of the second userland. It's not clear to me how significant that is, which was part of my question.

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#16

Post by fiokoden »

zlynx wrote: post #10
ComputerGuru wrote: post #7

Earlier quoted context omitted.

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.

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.

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#17

Post by baruch »

fiokoden wrote: post #15

How can any performance gain match the benefits of running on a tuned SMP kernel? What exactly happens with SMP with this sort of application?

You either run it on a single CPU or the "os" layer needs to provide for thread migration. It also obviously needs to provide thread scheduling.

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#18

Post by fiokoden »

baruch wrote: post #17
fiokoden wrote: post #15

How can any performance gain match the benefits of running on a tuned SMP kernel? What exactly happens with SMP with this sort of application?

You either run it on a single CPU or the "os" layer needs to provide for thread migration. It also obviously needs to provide thread scheduling.

Which is to say, DIY symmetric multiprocessing, or BYO kernel code in-application.

I'd have to read a compelling technical explanation before believing this could perform better than a Linux or BSD kernel.

In most cases, the Go code is going to be single CPU, and that ain't the way the world works anymore. There's going to be a bunch of wasted computing power on that VM

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#19

Post by viraptor »

fiokoden wrote: post #16
zlynx wrote: post #10

Earlier quoted context omitted.

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.

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.

Re: Atmanos: Build Go programs that run directly on the Xen hypervisor

#20

Post by ihsw2 »

viraptor wrote: post #19
fiokoden wrote: post #16

Earlier quoted context omitted.

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.

Post reply on HN