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

ZeroVM: lightweight containers based on Google Native Client

zerovm.org

Post reply on HN
Print view View original

31–40 of 79 posts

Re: ZeroVM: lightweight containers based on Google Native Client

#31

Post by camuel »

iseyler wrote: post #27

This is very interesting! It will be even more interesting to see if it can be compiled to run on my OS. This is exatly the kind of application I have been looking for. ESXi is too big :) Shameless plug: http://www.returninfinity.com/baremetal.html

I can assure you it can easily be ported and used on any OS. We just a few guys right now and don't have the capacity to test it on anything but Ubuntu. However, we are designed it to portable (and NaCl/Chrome code is also portable which helps a lot). Even to run on bare-hardware. So tried to keep OS usage to minimum. In fact, porting would be a more extensive effort to architectures not naively supported by Nacl. For example zerovm on tilera-linux (MIPS variant) will be much more effort then FreeBSD on x86-linux.

As a side note, I personally convinced that today OSes are an overkill for cloud-based number crunching (the prime case for zerovm) wasting resources. I am looking forward for future a lot lighter 'cloudware'. Think 'opencompute' approach for OSes. zerovm is being a humble experiment here.

Re: ZeroVM: lightweight containers based on Google Native Client

#32

Post by camuel »

mike_ivanov wrote: post #14
hobbyist wrote: post #3

how is it different from freebsd jails or containers in linux?

Containers/jails draw the isolation boundary around your processes, whilst this technology confines your code within a singe process and completely isolates it from the system.

exactly!

Further from being a different abstraction, container technologies (at-least in their current implementations of 'chroot on nukes') are not completely sealed or 'secure'. OpenVZ seems to be the most secured one over-there, requires kernel-patching and still... close but not 100% airtight. That is one of the reasons that many lightweight containers are used only as secondary sandbox (like Heroku) and not allowing you to run arbitrary C/assembly inside your environment. So, practically, LXC always ends up as secure-python-environment or ruby-environment as so on... never as secure x86 execution environment.

Correct me here if I'm wrong...

Re: ZeroVM: lightweight containers based on Google Native Client

#33

Post by camuel »

mike_ivanov wrote: post #13

This is a perfect Mobile Agent platform ( http://en.wikipedia.org/wiki/Mobile_agent )

Correct!

I wonder how I missed this on zerovm site. For the folks not familiar with the issue, it is not about mobile phones :)

With the emergence of large immobile datasets, software mobile agents may have a renaissance era... especially with AI being cool again.

Re: ZeroVM: lightweight containers based on Google Native Client

#34

Post by iseyler »

camuel wrote: post #31
iseyler wrote: post #27

This is very interesting! It will be even more interesting to see if it can be compiled to run on my OS. This is exatly the kind of application I have been looking for. ESXi is too big :) Shameless plug: http://www.returninfinity.com/baremetal.html

I can assure you it can easily be ported and used on any OS. We just a few guys right now and don't have the capacity to test it on anything but Ubuntu. However, we are designed it to portable (and NaCl/Chrome code is also portable which helps a lot). Even to run on bare-hardware. So tried to keep OS usage to minimum. In fact, porting would be a more extensive effort to architectures not naively supported by Nacl. Fo…

Agreed on the overkill part. That is the reasoning behind the work we are doing. I sent you an email to discuss further.

Re: ZeroVM: lightweight containers based on Google Native Client

#35

Post by xal »

I love how many high level technologies are left to mature in the java environment and then are reintroduced on a level that's a lot closer to the kernel and the metal.

ZeroMQ is another great example of the progression that started with AMQP.

Hadoop hopefully will see a similar fate. ZeroMQ combined with ZeroVM actually offers two important building blocks.

Re: ZeroVM: lightweight containers based on Google Native Client

#36

Post by camuel »

ericbb wrote: post #26
vardump wrote: post #8

I read this as RPC with code instead of just data. If so, this is exactly what I've been looking for a long time, because traditional RPC roundtrip latency is often high - so high, that you need to create a more complicated API to avoid excess iteration. Combine this with ZeroMQ and MessagePack, and you have some serious power at your fingertips. Messages can execute at destination, do iteration, API calls and return…

Typical solution is to use an interpreter (turning data into code). How often is it necessary to run arbitrary machine code on demand?

In most cases within distributed computing you need either move the data or move the code. It could also be something in between with the case of "request" and "query", if they simple they are surely data, if they are complex they look more like code.

Ok, now if we agree that something should be moved lets think what makes more sense to move dataset or to move code?

And my take is "it depends". Dataset size plays a role... security plays a role and etc.. think what if dataset for another reasons than size cannot be moved. In all these cases you need to move code.

In the case the code is untrusted (malicious suspect or just being buggy) you will want some kind of sandbox.

Re: ZeroVM: lightweight containers based on Google Native Client

#37

Post by camuel »

vardump wrote: post #8

I read this as RPC with code instead of just data. If so, this is exactly what I've been looking for a long time, because traditional RPC roundtrip latency is often high - so high, that you need to create a more complicated API to avoid excess iteration. Combine this with ZeroMQ and MessagePack, and you have some serious power at your fingertips. Messages can execute at destination, do iteration, API calls and return…

ZeroVM uses both. Well, not now, but one contributor took the clustering thing on himself and implementing it right now with zeromq while another is developing a client library with collection of serdeses verified to compile and work on zerovm.

We decided on micro-kernel design with zerovm so all data-crunching libraries will go into untrusted code part.

Re: ZeroVM: lightweight containers based on Google Native Client

#38

Post by camuel »

willvarfar wrote: post #5
StavrosK wrote: post #4

I have never read so many words and understood so little about a technology before. The density of marketing-speak per word is approximately 1. Why can't some people just explain things simply?

I read it the other way around: the prose is poor - perhaps not written by a native English speaker - but its very technical, accurate and not BS

Thanks for this.

I'm indeed not a native English speaker. And I apologies for not having diagrams, in fact I was working on this part right now... And planned HN exposure little later after more diagrams are added to website, VirtualBox image ready with whole environment to save time for folks who want to experiment and a well tested initial version separated from development branch.

However it went out earlier, uncontrollably, while I'm travelling... and I will play now a catch-game...

Re: ZeroVM: lightweight containers based on Google Native Client

#39

Post by eklitzke »

ww520 wrote: post #25
reginaldo wrote: post #9

Earlier quoted context omitted.

From what I read it's something like this: It gives a bare-bones environment for you to run your programs that is presumably very low overhead. Think of it as an embedded system where programs run without an OS. This is the environment a program running inside zerovm will see. All you have is libc and the zerovm-provided APIs. If you want more, you'll have to statically link your programs. The thing is, you can run m…

Actually as long as you set up your permission correctly, you can run any untrusted user-mode C code (non-privileged code). Just deny access to most of the system except the places you let it access. Chroot actually let you emulate the system directories for the process. Set up the firewall correctly to restrict its network access. The multi-user environment in Unix is the very old idea to let untrusted codes and unt…

I think in practice there have been a few historical problems with this approach. A major one is that while in theory it's possible to secure a process to a chroot jail (either the Linux or the BSD variety) in practice it's hard to defend against arbitrary, possibly malicious programs in that jail.

Kernel exploits that rely on local access are uncommon but not incredibly rare. You could easily have a hosting service like this that ran fine for a few months, or even a few years, and then a 0-day kernel exploit comes out (that relies on having local access to the machine) and then you're SOL.

Another issue is that in practice some system calls are very expensive. With a little knowledge you can DOS a machine hosting your process if you can run arbitrary system calls -- for instance, if you can create some sort of resource that is expensive for the kernel to track, and then create a lot of that resource. Sort of related to this, at least in Linux there are a very large number of syscalls and new ones are added relatively frequently, and not all syscalls have had the same amount of security auditing.

Even if you're not worried about your own servers getting hacked, you need to convince your customers that other users aren't going to be able to intercept or modify their data or attack their VMs.

In my mind, one of the main innovation of a lot of the VM stuff in recent years, and in particular the NaCL approach of limiting what system calls can be invoked, is that you are fundamentally reducing the interface by which malicious programs have to attack the hosting machine. If you can securely limit system calls to a small subset, you can more easily audit the paths those system calls make to ensure that they're secure and can't be used in a DOS scenario. In a virtualization environment like Xen or KVM, the amount of code that you have to audit is limited to the Xen/KVM code which is much smaller than the rest of the code base.

Just my 2c., etc.

Re: ZeroVM: lightweight containers based on Google Native Client

#40

Post by shykes »

camuel wrote: post #32
mike_ivanov wrote: post #14

Earlier quoted context omitted.

Containers/jails draw the isolation boundary around your processes, whilst this technology confines your code within a singe process and completely isolates it from the system.

exactly! Further from being a different abstraction, container technologies (at-least in their current implementations of 'chroot on nukes') are not completely sealed or 'secure'. OpenVZ seems to be the most secured one over-there, requires kernel-patching and still... close but not 100% airtight. That is one of the reasons that many lightweight containers are used only as secondary sandbox (like Heroku) and not allo…

dotCloud (http://dotcloud.com) supports arbitrary code execution inside LXC containers (pre-2010 versions used OpenVZ, and very early versions were built on V-server). The main limitation is that the process runs under an unprivileged uid under a kernel managed and deployed by dotCloud.

I agree with the assessment that containers are not "completely secure" - I would not trust it to contain a root-privileged process. However an unprivileged process running inside an lxc container on a recent kernel will have an extremely hard time escaping.

Post reply on HN