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

71–79 of 79 posts

Re: ZeroVM: lightweight containers based on Google Native Client

#71

Post by StavrosK »

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

Well, sure, but there's no high level overview. Even something like "It's a virtualizing solution, like Xen/VMware/VirtualBox, that uses Chrome's Native Client".

Re: ZeroVM: lightweight containers based on Google Native Client

#72

Post by prodigal_erik »

ww520 wrote: post #46
prodigal_erik wrote: post #45

Earlier quoted context omitted.

Has OS isolation ever been implemented successfully? I think I've seen local root exploits reported for every OS I've heard of.

And what are the evidence of VM based isolation have more security?

True, even the JVM verifier was flawed, maybe neither approach can succeed. It just seems to me we now have good reason to believe it's a dead end to try to sandbox native code in legacy instruction sets.

Re: ZeroVM: lightweight containers based on Google Native Client

#73

Post by lobster_johnson »

camuel wrote: post #60
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/

If you use EMR or just roll your own Hadoop in EC2 then: 1. Hadoop runs on EC2 2. Data is stored on S3 3. Intermediary results stored in EC2 4. Hadoop loads the data from S3 to EC2 5. EC2 S3 bandwidth is not that fast or efficient (S3 proxy, network contention, TCP/IP processing) Hypothetical MapReduce/ZeroVM/Swift scenario: 1. Data is stored on S3/Swift 2. Map and Reduce functions are run inside S3/Swift secured by…

That criticism is specific to S3, not EC2 or Hadoop. It's perfectly feasible and probably preferable to have Hadoop work on local files in instance store volumes (or EBS if you're mad).

Re: ZeroVM: lightweight containers based on Google Native Client

#74

Post by camuel »

prodigal_erik wrote: post #72
ww520 wrote: post #46

Earlier quoted context omitted.

And what are the evidence of VM based isolation have more security?

True, even the JVM verifier was flawed, maybe neither approach can succeed. It just seems to me we now have good reason to believe it's a dead end to try to sandbox native code in legacy instruction sets.

Every system might have weaknesses. What matters is:

1. Small surface for attack. With NaCl it is all concentrated in single tiny validator module. The model is also simple and mathematically proven to be secure. 2. Prior testing. It is especially hard for security product. Establishing motivating prizes is good way to ensure it is not easily breakable. 3. The speed with which patch is made available 4. Defense-in-depth, ability to have multiple levels of defense cheaply.

Re: ZeroVM: lightweight containers based on Google Native Client

#75

Post by camuel »

ww520 wrote: post #68
camuel wrote: post #56

Earlier quoted context omitted.

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 on…

If all is that simple & rosy why no hosting/cloud service uses it?

Why entire shared hosting industry custom-patches their kernel constantly with OpenVZ and stuff?

Why shared hosting has such a bad reputation for being insecure (despite all efforts).

Re: ZeroVM: lightweight containers based on Google Native Client

#76

Post by camuel »

lobster_johnson wrote: post #73
camuel wrote: post #60

Earlier quoted context omitted.

If you use EMR or just roll your own Hadoop in EC2 then: 1. Hadoop runs on EC2 2. Data is stored on S3 3. Intermediary results stored in EC2 4. Hadoop loads the data from S3 to EC2 5. EC2 S3 bandwidth is not that fast or efficient (S3 proxy, network contention, TCP/IP processing) Hypothetical MapReduce/ZeroVM/Swift scenario: 1. Data is stored on S3/Swift 2. Map and Reduce functions are run inside S3/Swift secured by…

That criticism is specific to S3, not EC2 or Hadoop. It's perfectly feasible and probably preferable to have Hadoop work on local files in instance store volumes (or EBS if you're mad).

but instance store is transient! You may argue if you do triple replicated in different availability zones then you are ok. Well, in this case it would be very costly as you will end up with constantly spinning EC2 cluster. Even if you don't do any computation you must keep it all spinning. And see what happened to elasticity... you end up paying inflated cloud prices for constantly spinning fixed size EC2 cluster! Instead of being able to rapidly roll out large cluster, make the computation and fold it back and pay only for what you have used - isn't it the true promise of cloud?

Re: ZeroVM: lightweight containers based on Google Native Client

#77

Post by DavidGruzman »

lobster_johnson wrote: post #73
camuel wrote: post #60

Earlier quoted context omitted.

If you use EMR or just roll your own Hadoop in EC2 then: 1. Hadoop runs on EC2 2. Data is stored on S3 3. Intermediary results stored in EC2 4. Hadoop loads the data from S3 to EC2 5. EC2 S3 bandwidth is not that fast or efficient (S3 proxy, network contention, TCP/IP processing) Hypothetical MapReduce/ZeroVM/Swift scenario: 1. Data is stored on S3/Swift 2. Map and Reduce functions are run inside S3/Swift secured by…

That criticism is specific to S3, not EC2 or Hadoop. It's perfectly feasible and probably preferable to have Hadoop work on local files in instance store volumes (or EBS if you're mad).

There is other issue with running hadoop on EC2 (w/o S3). Instance storage is relatively small - about 3.6 TB on largest instance and 1.5 TB on other "large" instances. In typical Hadoop machine I would expect about 8TB. So local storage is prohibitively expensive for the big data tasks. In the same time - if we use local storage we a loosing elasticity - we have to run cluster all the time, even there is no jobs to run. It kills main point of using hadoop in the cloud - to pay for the computational resources on demand.

Re: ZeroVM: lightweight containers based on Google Native Client

#78

Post by skrebbel »

andybak wrote: post #50
skrebbel wrote: post #29

Earlier quoted context omitted.

They're called the downvote mafia. Little to do about them.

Is it people or scripts? What's the motivation or is it a mystery?

It's people. I'm slightly blinded by their motivation. Something inside me wants to believe they're 14 year old mischievous scriptkiddies, but I bet they're really just guys and girls like you and me.

Re: ZeroVM: lightweight containers based on Google Native Client

#79

Post by rektide »

OpenMirage project is a similar-ish idea, providing numerous implementations of a std-lib for different targets (sample targets: Android, Linux OS, raw x86), and using this limited API. Sure, ZeroVM has it's own "vm instructions" rather than "library calls," but the ideas both reduce to building virtual machines for great glory and profit.
Post reply on HN