3 ms·

Why is Google insisting on the use of NativeClient? Not insinuating anything, but a NaCl-compiled distributed task would be an excellent fit for farming out to

by 0x0 14y ago

Why is Google insisting on the use of NativeClient? Not insinuating anything, but a NaCl-compiled distributed task would be an excellent fit for farming out to unsuspecting browser clients. (Reminds me about that sneaky javascript-based bitcoin miner that was injected on a few web sites some time ago)

jey 14y ago
Because NaCl is a fully sandboxed way to run full-performance native code.
dekhn 14y ago
We looked at several security and sandbox technologies, and NaCl was closest to our requirements: near-native performance, easy access to the NaCl software development team and supported C and C++. Strictly speaking, we use it as a "Native Server", rather than a "Native Client" (it runs on server-class machines, not desktop browsers). We've talked with Vijay Pande (of Folding@Home fame) about making "Folding@Chrome", but that would be opt-in (IE, you'd install a Chrome App). If you have an alternative sandbox and security framework, I'd be happy to hear about it.
- 0x0 14y ago
  That's cool, I never really thought of using NaCl on the server side like that. So you are saying it is a better solution than any combination of Java, Ruby, SELinux, any other regular OS ACL, Xen, or any other virtualization platform?
  - dekhn 14y ago
    At least in my experience, most of the codes we expected to run were written in C or C++. We would like to support Java, but it's not an option right now (Native Client doesn't support Java, and I'd need to research the Java sandboxing technologies). Another issue is that we limit memory usage, and Java memory usage tends to be higher than C++ programs; ditto for virtualization. Note that virtualization isn't really a security solution on its own. I can't really see Ruby being the right approach for CPU-intensive computing (we're talking hundreds of thousands of cores, so it's worth investing in making the code efficient). BTW, I definitely think seccomp http://en.wikipedia.org/wiki/Seccomp http://en.wikipedia.org/wiki/Seccomp and linux containers http://lxc.sourceforge.net/ http://lxc.sourceforge.net/ or perhaps OpenVZ: http://wiki.openvz.org/Main_Page http://wiki.openvz.org/Main_Page could be engineered into a secure sandbox, without having to resort to virtualization (which I'd like to emphasize isn't really a security solution). This is called "container virtualization" (as compared to hardware/CPU-based), and has a number of very nice properties.
drivebyacct2 14y ago
You might be interested in this: http://zerovm.org/ http://zerovm.org/ (No association but it seems highly relevant.)

by 0x0 14y ago

jey 14y ago

Because NaCl is a fully sandboxed way to run full-performance native code.

dekhn 14y ago

We looked at several security and sandbox technologies, and NaCl was closest to our requirements: near-native performance, easy access to the NaCl software development team and supported C and C++. Strictly speaking, we use it as a "Native Server", rather than a "Native Client" (it runs on server-class machines, not desktop browsers). We've talked with Vijay Pande (of Folding@Home fame) about making "Folding@Chrome", but that would be opt-in (IE, you'd install a Chrome App). If you have an alternative sandbox and security framework, I'd be happy to hear about it.

0x0 14y ago
That's cool, I never really thought of using NaCl on the server side like that. So you are saying it is a better solution than any combination of Java, Ruby, SELinux, any other regular OS ACL, Xen, or any other virtualization platform?
- dekhn 14y ago
  At least in my experience, most of the codes we expected to run were written in C or C++. We would like to support Java, but it's not an option right now (Native Client doesn't support Java, and I'd need to research the Java sandboxing technologies). Another issue is that we limit memory usage, and Java memory usage tends to be higher than C++ programs; ditto for virtualization. Note that virtualization isn't really a security solution on its own. I can't really see Ruby being the right approach for CPU-intensive computing (we're talking hundreds of thousands of cores, so it's worth investing in making the code efficient). BTW, I definitely think seccomp http://en.wikipedia.org/wiki/Seccomp http://en.wikipedia.org/wiki/Seccomp and linux containers http://lxc.sourceforge.net/ http://lxc.sourceforge.net/ or perhaps OpenVZ: http://wiki.openvz.org/Main_Page http://wiki.openvz.org/Main_Page could be engineered into a secure sandbox, without having to resort to virtualization (which I'd like to emphasize isn't really a security solution). This is called "container virtualization" (as compared to hardware/CPU-based), and has a number of very nice properties.

drivebyacct2 14y ago

You might be interested in this: http://zerovm.org/ http://zerovm.org/ (No association but it seems highly relevant.)