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

61–70 of 79 posts

Re: ZeroVM: lightweight containers based on Google Native Client

#61

Post by camuel »

[deleted] wrote: post #59
karterk wrote: post #58

what is less known is that when deployed at cloud, Hadoop cannot access that enormous dataset locally due to security restrictions and therefore is screamingly inefficient compared to on-premise Hadoop deployment. [1] Can someone explain what that means? [1]: http://zerovm.org/killer-apps/

[deleted]

you got (2) wrong, the reason is running code on S3 is insecure and would not be allowed and spawning VM inside S3 for some local calculation would be cumbersome at best as it is too bulky for such acrobatics.

Re: ZeroVM: lightweight containers based on Google Native Client

#63

Post by camuel »

mcartyem wrote: post #62

How secure is the VM given a binary that can dynamically modify itself to bypass the inspection of the VM?

I assume by VM you mean ZeroVM. Well, ZeroVM currently doesn't allow self modifying code at all. Nice try.... We haven't touched Google's provided validator in order not to break anything security-related. And if you think you have a good idea for vulnerability then you can claim some Google prizes.

If you meant more practical uses for it then unfortunately modern JIT would be difficult to support efficiently as they constantly recompile and with ZeroVM it is not only recompilation but also validation. However, JIT that recompile only once, on loading, is easy to support. In fact, next version of NaCl dumps GNU toolchain in favor for JITy LLVM, but then recompilation is happening only once.

Re: ZeroVM: lightweight containers based on Google Native Client

#65

Post by camuel »

[deleted] wrote: post #64

[deleted]

Well... this echoes ZeroVM ideas but so is PiCloud and a few others mentioned here. I think it goes without doubt that current OSes and VMs are not best suited for cloud technologies. How they can be? The were designed to completely different requirements.

Re: ZeroVM: lightweight containers based on Google Native Client

#66

Post by Ecio78 »

camuel wrote: post #65
[deleted] wrote: post #64

[deleted]

Well... this echoes ZeroVM ideas but so is PiCloud and a few others mentioned here. I think it goes without doubt that current OSes and VMs are not best suited for cloud technologies. How they can be? The were designed to completely different requirements.

sorry i deleted the post because i thought it was not useful. i was referring to this article http://highscalability.com/blog/2010/10/21/machine-vm-cloud-...

Re: ZeroVM: lightweight containers based on Google Native Client

#67

Post by ww520 »

camuel wrote: post #51
ww520 wrote: post #43

Earlier quoted context omitted.

Thanks for the responses; however, most of the attacks to OS process can happen in ZeroVM. - Kernel exploits can happen, so can exploits in ZeroVM. - DOS attack on OS, so can DOS attack on ZeroVM. I don't see any quota system or resource management in ZeroVM to mitigate it. At least the OS have better tools to deal with it - priority, scheduler, resource manager, memory partition, etc. - Same thing for the customer w…

ZeroVM is not a lightweight container so all the above doesn't hold. ZeroVM doesn't use any "syscall firewalling" techniques. ZeroVM efficiently emulates new hardware platform just as XEN/KVM. Now let me address your concerns one by one: 1. (Host) Kernel exploits cannot happen as no syscalls to host OS are allowed. ZeroVM app doesn't even have such a concept as host OS. 2. DoS attacks impossible on host OS as there a…

1. So there are 100% guarantee that ZeroVM does not and will not have exploit? The OP point was kernel can have exploit so kernel is inferior than ZeroVM. My point kernel can exploits, so can ZeroVM. You just don't know yet.

2. DOS on ZeroVM indirectly DOS on the host. There are so many way to DOS a system. How do you handle an app running in a tight loop access all the memory randomly? Queuing the max payload in a tight loop? Spawn off new instances across the entire cluster in a tight loop? Claiming DOS can happen in kernel and not possible in ZVM is just naive.

Re: ZeroVM: lightweight containers based on Google Native Client

#68

Post by ww520 »

camuel wrote: post #56
ww520 wrote: post #44

Earlier quoted context omitted.

I don't understand why multi-tenant is problem. Multi-user Unix (or others) have supported allowing multiple untrusted users/programs to run for a long time. Edit: I don't mean to be a downer on your project. It's a cool project, but I think you would prefer constructive criticism than me just saying "awesome, carry on."

Constructive criticism is always welcome. The answer is that multi-tenant is different from multi-user on so many aspects. Multi-user: 1. Usually closed institution or even single group within single institution where all know each other. 2. Usually a lot of shared data and application. 3. The risk of malicious activity is low. 4. The consequences of malicious activity are not severe/fatal. 5. Auditing followed by id…

What I was talking about is the multi-user as a capability to run untrusted code. You were talking about it as a policy and procedure. The multi-user capability allows one to use permission to create a lock down, low privilege area to let anyone to run in it. There are open Unix accounts out there that allow anyone to log in to play around with it for a long time. The multi-tenant problem claim is just not a valid one.

Re: ZeroVM: lightweight containers based on Google Native Client

#69

Post by camuel »

ww520 wrote: post #67
camuel wrote: post #51

Earlier quoted context omitted.

ZeroVM is not a lightweight container so all the above doesn't hold. ZeroVM doesn't use any "syscall firewalling" techniques. ZeroVM efficiently emulates new hardware platform just as XEN/KVM. Now let me address your concerns one by one: 1. (Host) Kernel exploits cannot happen as no syscalls to host OS are allowed. ZeroVM app doesn't even have such a concept as host OS. 2. DoS attacks impossible on host OS as there a…

1. So there are 100% guarantee that ZeroVM does not and will not have exploit? The OP point was kernel can have exploit so kernel is inferior than ZeroVM. My point kernel can exploits, so can ZeroVM. You just don't know yet. 2. DOS on ZeroVM indirectly DOS on the host. There are so many way to DOS a system. How do you handle an app running in a tight loop access all the memory randomly? Queuing the max payload in a t…

1) there is $100K bounty on each Chrome/NaCl exploit and we have only one ZeroVM 'syscall' that we allow with a lot of attention put how to make it easily secure. The situation is not same on Linux. First of all kernel exploits by process are not really considered severe in Linux and for sure it is not top priority to anyone. Linux built to be secure from outside not from inside.

2) All these is impossible in ZeroVM except accessing memory randomly and thrashing caches and TLB tables. Hm... that could work, I guess. For the first time in this forum we talk about real vulnerability. However, I think the problem exists also in KVM/XEN (will do a proper research now, Googling EC2 TLB thrashing doesn't yield anything interesting), no access to other tenant data just temporarily slowing down specific processor chip.

Re: ZeroVM: lightweight containers based on Google Native Client

#70

Post by DavidGruzman »

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?

I would expect about order of magnitude speed difference between interpreted language and optimized machine code. I can recall case when reducing analytical request from 10 hours to 10 minutes changes the qualities of research company was doing - since analysts where able to do more queries selecting better dataset for the report. Order of magnitude response time might also be go/no go for interactive analytics. In case of clouds where we can assume infinite resources it can mean 1/10 of cost. For the private clusters - it can be differenace in buying 10 machines (something common in hadoop's word) and buying 100 machines - something very few groups can get.
Post reply on HN