[camuel]

1. ZeroVM abstraction is C including full support for native inline assembly/intristics. Make your own conclusions about portability with regards to platform. OS portability could/will be provided and it is piece-of-cake (for geeky overoptimism of course)

2. Don't want to go into JIT / C flamewar... but let's take a sorting example. In samples directory you can find my hand-coded assembly code (thank you Takeshi Yamamura for the help) for sorting. GB is sorted within seconds. I am sure no JIT comes even close and I tried it hard. I my self SCEA and Javaist and JIT/LLVM enthusiast. If you need my help with compiling the sample let me know I'll gladly help... I know it is not ready for the prime time, very very cryptic badly commented too... which should not be for a sample. So you are warned. But it I never ever saw in my life a single threaded sorting performance that comes even close. Let me know if I mistaken.

3. Why not just use process isolation.... Well this is right way to go and zerovm would be a solution looking for a problem if and only if OS process would be secure in multi-tenant sense. However, there is no such OS. The only way is to use KVM/XEN and this is just too heavy... Another issue: why I use NaCl and not native hardware support for memory protection? The answer is two fold:

a) I was afraid of the amount of work needed to write my own complete OS from scratch (if I use existing stuff it would have most of shortcomings I am trying to solve in the first place)

b) It would be useless in its initial years if not decades as there are would be not enough applications for it to justify complete hardware dedication for zerovm. I thought about writing it as lightweight real OS running under some quickly spawned KVM processes, but still was afraid I and my team just had no spare engineering capacity for that and missing knowledge also that would be fun to acquire but just could take too long and even then it would be heavily linux-specific.

[ww520]

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

[camuel]

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 identification and penal actions are an effective strategy to stop malicious activity.

Multi-tenant: 1. Usually open to anyone without "background checks". 2. Single instance of malicious activity is severe, repeated malicious activity is fatal. 3. Auditing, identifying the intruder and suing him in court is not an effective strategy to stop malicious activities.

[ww520]

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.

[camuel]

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