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

41–50 of 79 posts

Re: ZeroVM: lightweight containers based on Google Native Client

#41

Post by camuel »

ww520 wrote: post #24
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?

tl;dr It's basically a lightweight sandbox to let you run untrusted code from un-managed languages (i.e. C/C++/Assembly/etc) in the native host format (i.e. in Linux i686 or Win32 or iOS). My comment: In other quarters, people usually use OS process plus permission to isolate the running of a untrusted program. This is basically what ZeroVM is, a more restricted process. One major downside of this approach is that yo…

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.

Re: ZeroVM: lightweight containers based on Google Native Client

#42

Post by camuel »

eklitzke wrote: post #39
ww520 wrote: post #25

Earlier quoted context omitted.

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…

Thanks for that, I feel the same way for process isolation. In theory that should be a solution but in practice doesn't work for historic reasons.

Just one comment. ZEROVM IS NOT NACL. It uses NaCl, moreover we explicitly refrained to touch validator in order to remain under its proven security blanket (Google established hefty monetary prizes for each found exploit). However, except of validator it is heavely refactored and rewritten.

MAIN DIFFERENCE:

NaCl has "syscall firewalling" feature that is called Pepper. ZeroVM forbids all host syscalls. In fact ZeroVM is a new virtual hadware architectures (a subset of x86 and subset of ARM and new ones in future) so there is no such concept for code running inside as "host syscalls".

Re: ZeroVM: lightweight containers based on Google Native Client

#43

Post by ww520 »

eklitzke wrote: post #39
ww520 wrote: post #25

Earlier quoted context omitted.

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…

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 worry. They could worry about other users attacking the ZeroVM or the host system.

If you prefer security VM, there are a lot of mature VM's - JVM, .Net, Xen, or KVM.

My point is there have been so much research, work, and experience have gone into the security in OS that I would trust an OS isolation than a new research system in term of security. It's easy to have a lock-down OS to restrict access to most subsystems.

Re: ZeroVM: lightweight containers based on Google Native Client

#44

Post by ww520 »

camuel wrote: post #41
ww520 wrote: post #24

Earlier quoted context omitted.

tl;dr It's basically a lightweight sandbox to let you run untrusted code from un-managed languages (i.e. C/C++/Assembly/etc) in the native host format (i.e. in Linux i686 or Win32 or iOS). My comment: In other quarters, people usually use OS process plus permission to isolate the running of a untrusted program. This is basically what ZeroVM is, a more restricted process. One major downside of this approach is that yo…

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

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

Re: ZeroVM: lightweight containers based on Google Native Client

#45

Post by prodigal_erik »

ww520 wrote: post #43
eklitzke wrote: post #39

Earlier quoted context omitted.

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…

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…

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

Re: ZeroVM: lightweight containers based on Google Native Client

#46

Post by ww520 »

prodigal_erik wrote: post #45
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…

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?

Re: ZeroVM: lightweight containers based on Google Native Client

#47

Post by wladimir »

Tobu wrote: post #16

This is intended as a way to run computation close to data. Some databases embed Lua or pluggable languages for that; ZeroVM can run NaCL binaries (compiled with a special toolchain), verified in the same manner as the JVM checks bytecode, on a very limited sandbox (just some pre-configured data channels). Besides the NaCL verifications, they are enforcing functional programming: the program only has access to determ…

Is it right to equate functional programming and determinism though? Functional programming implies a certain programming style / type of language, whose output is guaranteed to be deterministic if only pure functions are used. But they're not the same thing.

Re: ZeroVM: lightweight containers based on Google Native Client

#49

Post by camuel2 »

wladimir wrote: post #47
Tobu wrote: post #16

This is intended as a way to run computation close to data. Some databases embed Lua or pluggable languages for that; ZeroVM can run NaCL binaries (compiled with a special toolchain), verified in the same manner as the JVM checks bytecode, on a very limited sandbox (just some pre-configured data channels). Besides the NaCL verifications, they are enforcing functional programming: the program only has access to determ…

Is it right to equate functional programming and determinism though? Functional programming implies a certain programming style / type of language, whose output is guaranteed to be deterministic if only pure functions are used. But they're not the same thing.

ZeroVM invocation is a pure function. ZeroVM cluster invocation is a pure function.

Functional programming according to wikipedia is - "a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data"

ZeroVM invocations satisfy that definition. With existing Swift integration all storage is immutable and ZeroVM cannot have any state by design.

Re: ZeroVM: lightweight containers based on Google Native Client

#50

Post by andybak »

skrebbel wrote: post #29
Tobu wrote: post #28

Earlier quoted context omitted.

Why downvotes? I provided an explanation because the initial reaction on HN was confusion.

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?
Post reply on HN