
Chromium Blog: A sneak peek at the Native Client SDK - boundlessdreamz
http://blog.chromium.org/2010/05/sneak-peek-at-native-client-sdk.html
======
stuntmouse
Done right, this will change the world. I'm currently working on porting an
emulator. The major sticking point so far is the audio API, which seems rather
primitive, but should be sufficient for my needs.

------
aidenn0
It seems to me that while this would have been interesting a few years ago,
it's tied to x86 just as people are starting to browse the web more and more
on mobile devices.

~~~
wmf
PNaCl is "write once, run on x86 and ARM".
<http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf>

~~~
papachito
FTA: "The Native Client SDK preview, in contrast, includes just the basics you
need to get started writing an app in minutes: a GCC-based compiler for
creating x86-32 or x86-64 binaries from C or C++ source code"

------
nissimk
How does this differ from ActiveX controls in IE, aside from being cross
platform?

~~~
wmf
NaCl is sandboxed; ActiveX is not.

~~~
briansmith
ActiveX can be sandboxed pretty strongly, but plugins can opt out of it. NaCl
seems to leave no way to get out of the sandbox. I think Microsoft could
easily add something very similar to NaCl to ActiveX, and then create a
distinction in the UI between these sandboxed plugins and the current kind.

Edit: To clarify, ActiveX plugins cannot really "opt out" of IE's sandbox.
There are some things they can do to reduce some of the default restrictions,
but the most important ones always remain in place.

~~~
tptacek
ActiveX's controls are nothing at all like NACL's.

NACL restricts the actual ABI. It enforces constraints that make disassembly
to basic blocks deterministic (regular x86 isn't). It then uses the X86 MMU to
prevent control flow blocks that could escape the sandbox.

Say whatever you want about ActiveX security (ActiveX is, for what it's worth,
not secure --- though at some point all of IE might be), but they aren't doing
basic block analysis, an MMU-enforced sandbox, or requiring special compilers
for everything linked into the controls.

~~~
briansmith
It's been a long time since I read the NaCL publications so I might be
forgetting some things. But, let's say IE9 were to move plugins to their own
low-integrity processes (instead of being in the tabs' low-integrity processes
like now). Given a perfectly-functioning mandatory integrity control system,
how much of the additional NaCL infrastructure really provides extra security?
How much of it "just" provides an extra layer of defense against kernel bugs
and/or security for pre-Vista/non-Windows systems?

In other words, is this extra infrastructure something that Microsoft would
really find useful to implement in IE9? Or, is it just needed for operating
systems that IE9 won't support anyway?

~~~
tptacek
Because WinAPI, no matter what MAC system it implements, isn't enforced at the
basic-block level, and NaCL is. NaCL has a smaller auditable attack surface.
No matter what WinAPI does, the entire memory map of an x86-64 process is
exposed to IE, and the same system call gates are exposed, and the same set of
inherited process attributes are there.

I'm not saying one is more secure than the other (NaCL's model is more elegant
but theoretically riskier, WinAPI's is better tested and more conservative).

------
JeffJenkins
To what degree does "Embrace and Extend" apply to what Google is doing?

~~~
stuntmouse
That's pretty vague. How does it apply to this situation?

The code is open; part of the NaCL API is designed around Posix/Linux; the
Plugin API is the familiar NPAPI and its extensions.

Which part is proprietary or controlled by Google?

To my mind, some more relevant questions are: Does this tie the web to x86
(and ARM)? Can it be adapted securely to x86-64? Can it be made secure? Can
multiple implementations be made secure?

~~~
papachito
> Can it be adapted securely to x86-64?

FTA: "a GCC-based compiler for creating x86-32 or x86-64 binaries from C or
C++ source code"

------
equark
This looks horrendous. Watch the video for the hello world example. It's
probably 100 lines of unintelligible code.

Miguel de Icaza's CLI for the web idea
(<http://tirania.org/blog/archive/2010/May-03.html>) looks like a much better
approach.

~~~
weavejester
It doesn't really matter that the code is unintelligible. One can use higher-
level languages on top.

What isn't so good is that NaCl targets the architecture of the host machine.
So you're not going to be able to run a NaCl app compiled on x86 on a browser
running under ARM. Someone please correct me if I'm wrong.

Miguel suggesting CLI isn't exactly surprising ;), but personally I'd prefer
to use a sandboxed VM based on LLVM. CLI makes too many assumptions about the
architecture of your language, whilst LLVM is more low-level.

~~~
Detrus
You can compile your binary for multiple architectures, check the type of
processor and give it the appropriate binary.

They also have the LLVM option so that old binaries keep working on new
architectures without recompiling and rewriting NaCl for them, but it has
downsides [http://blog.chromium.org/2010/03/native-client-and-web-
porta...](http://blog.chromium.org/2010/03/native-client-and-web-
portability.html)

The reason they didn't go with LLVM as the main approach was performance.
Google wants there to be no distinction between desktop and web apps, and for
web apps to have even 60% of desktop performance is still unacceptable. 90+%
is more like it.

~~~
weavejester
It's good to know that there's work being done in marrying LLVM to NaCl. Even
60% performance seems a very fair trade-off for low-level, platform-neutral,
sandboxed binaries.

------
pinhead
Also pretty interesting if you haven't read it (PDF):
[http://nativeclient.googlecode.com/svn/data/docs_tarball/nac...](http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/documentation/nacl_paper.pdf)

------
kixxauth
Browsers are going to be getting closer and closer to the metal all the time.
That's what this is telling us. It's like 1991 all over again.

~~~
andywood
Right. And in 1991, applications achieved much more of the potential
performance and capability due to the available hardware than web apps do
today. So going back to 1991 is an improvement in that respect. The rise of
the web has been a trade-off - well-known and significant benefits have been
realized, but at the cost of devolution and dead-ends in areas like the
developer experience and UI flexibility. (As an example, think about all the
reasons why World of Warcraft is not a web app.)

