Google released an update to its Native
Client (NaCl) framework in June, which is an open source utility to enable web developers to deploy faster applications by allowing them to run native binary code in a sandboxed environment within the browser. The new release incorporates API changes and updates to the SDK and toolchain, but the technology remains disabled by default in the Chrome browser. NaCl has been listed as "experimental" since its inception, but the company is beginning to shift its message, trying to attract developers to the platform and other browser makers to the framework.
NaCl is essentially a plugin in which "untrusted" native code can be
executed in a secure, sandboxed environment within the browser. Native
code in this context means machine language — compiled binaries,
delivered as self-contained modules. They do not have access to OS
subsystems or toolkits, but only a minimal support library provided by
NaCl. Most other browsers plugins (Java, Flash, etc.) are already native
code, of course, and like them NaCl modules can only interact with the
course, the mere mention of Java and Flash raises warning flags about security and performance, to which Google is
doing its best to respond.
Shaking it out
The NaCl plugin isolates code in the sandbox by using the memory
segmentation available in processes, thus providing a contiguous, private
address space for each component — currently 256MB in size. It also
attempts to detect insecure code (and refuses to run it), by restricting
each component to a set of "safe" instructions, and enforcing structural
rules to prevent code obfuscation techniques — such as jumping to a
location in the middle of an instruction. Loaded modules are also read-only in memory, to prevent self-modifying code.
In addition to the "inner sandbox" dedicated to isolating native code
modules, NaCl also implements an "outer sandbox" that intercepts any system
calls. Furthermore, code modules are isolated from each other. They can
only communicate by calling NaCl's inter-module communication (IMC)
mechanism. IMC is a bi-directional datagram service designed to resemble
Unix domain sockets. IMC is also used to facilitate communication between
modules and the document object model (DOM) object that created them
Each NaCl module also runs as its own OS process (although at the moment, the NaCl plugin itself is run in the browser's process). NaCl cannot provide secure, cross-platform exception handling for modules to recover from hardware exceptions. As a result, a module that triggers a hardware exception will be shut down by the OS, but, by running each module in its own process, other modules should be unaffected.
Developing NaCl modules
For application developers, the project is also introducing a native code API named Pepper, which is currently provided in C and C++ form. Pepper evolved out of Google's earlier efforts to expand on NPAPI, and is thus sometimes referred to in NaCl documentation as the Pepper Plugin API (PPAPI).
Pepper includes interfaces for NaCl's messaging systems and the existing NPAPI functionality, but also provides interfaces for image handling, 2D drawing, and audio, plus memory management, timing, threads, strongly typed variables, and managing module instances.
June's 0.4 release of the NaCl SDK includes minor changes to the C interfaces, and introduces a new method for including an NaCl module in an HTML page: by linking to it with the
src= attribute inside of an
<embed> tag. However, there are more substantial changes in the build system. It has migrated to the Python-based SCons build tool in place of GNU make, Cygwin has been removed from the Windows toolchain, and experimental support for Valgrind on 64-bit Linux has been added.
The toolchain itself is built on top of a customized version of GCC and GNU binutils that implement the constraints of the NaCl sandbox. Thus re-compilation is necessary, even for the "existing software components" and "legacy applications" use cases. The NaCl plugin provides a C library customized from NewLib.
As discussed earlier, the current SDK can build binary modules for x86-32, x86-64, and ARM, and there are mechanisms for web developers to provide all three varieties of their module within an application. Google is intent on expanding the processor support offerings, however, by adapting the build tools to produce a "portable" binary instead of the processor-specific code. Portable NaCl (PNaCl) compiles source to an intermediate LLVM bytecode format, which is then translated at runtime into the relevant machine code.
Google maintains a gallery
of NaCl examples, including a Monte Carlo pi calculator, audio synthesizer, and Conway's game of Life. The NaCl white papers also describe internal efforts to port Quake, Bullet, and an H.264 decoder to NaCl, and claim the performance to be "indistinguishable" from normal executables, although that code has evidently not been released to the public.
The view outside the Googleplex
From a security standpoint, most of the ideas implemented by NaCl are
not new. Rather than using code signing to provide a measure of security
as ActiveX does for its binary modules, NaCl uses a static verifier to
check all modules before they are allowed to run, and terminates any that
pass that check and still manage to make an unsafe system call. The
fault-isolation methods used by the code verifier are also well-known. On
the development side, the modified GCC and binutils act as a "trusted"
compiler, in theory ensuring that no unsafe code gets executed in the first
place. Code that doesn't conform to the structural and alignment
requirements that the toolchain emits will be rejected.
Reaction from other browser vendors has been decidedly negative, however. Although NaCl is marketed as an open source project open to any browser developer, both Mozilla and Opera have said they have no interest in the technology, and view it as conflicting with the goal of promoting open standards like HTML5 as the unified, cross-platform target platform for web application developers.
The specific version could make a difference; Mozilla introduced TraceMonkey (a
code) with the release of Firefox 3.5 in 2008. Firefox 4.0 then introduced
a second optimizer named JaegerMonkey, further improving
Of course, NaCl lines up with Google's interest in promoting
the ChromeOS platform. If NaCl can squeeze additional performance out
of netbook CPUs with code delivered in the browser, the need for
locally-installed applications is reduced. But that concern may not
line up with increasing the performance of standards-based web
applications that run in every browser. The NaCl project itself is not on a
standardization path, although the FAQ hints at interest in pursuing it
If Google remains unsuccessful at persuading the other browsers to include support for NaCl, it might attempt to build NaCl plugins for the other browsers (which it did in years past, but it's been deprecated due to the limitations of having only the NPAPI interface). But it may have a harder time convincing a significant number of developers to re-engineer NaCl-based applications. As tantalizing as "native speed" sounds from afar, the double sandbox security restrictions, limited execution environment, and current need to develop for three separate processor architectures does not sound as exciting up close. As for PNaCl's promise to eliminate the architecture problem by targeting an intermediate byte-code representation instead — that platform starts to sound more and more like client-side Java. Perhaps it does hold the key for a performance increase, but it is not going to be an easy sales pitch.
Comments (19 posted)
Andi Hellmund has announced
publication of a
white paper on the GCC front end [PDF]
. It's a work in progress, and
he is interested in comments from readers.
Comments (none posted)
Version 7.3 of the GDB debugger is available. New features include OpenCL
language support, better Python support, better debugging of threaded
programs, Blackfin CPU support, and more.
Full Story (comments: none)
A 6-hour training DVD on drawing comics with Krita
is now available
for pre-order. Also available is a 20-page printed comic book that includes two comics created in Krita. Proceeds go to fund further Krita development. "Drawing Comics with Krita, helps you learn how to draw, color assemble and publish comics yourself using Krita, the free and open source digital painting suite. The DVD, comic book combo shows you, step-by-step how to use the most important of Krita's flexible painting tools. These are skills that can be used in any drawing or painting project. Better yet, each purchase helps fund getting creative commons training out there to help get more digital artists into Krita, free culture and free software in general.
" (Thanks to Armijn Hemel.)
Comments (none posted)
The Mozilla project has announced
a project called "Boot to Gecko"
which appears to be a sort of competitor to ChromeOS and/or Android. "Mozilla
believes that the web can displace proprietary, single-vendor stacks for
application development. To make open web technologies a better basis for
future applications on mobile and desktop alike, we need to keep pushing
the envelope of the web to include --- and in places exceed --- the
capabilities of the competing stacks in question.
" The associated
contains only a
README file thus far.
Comments (34 posted)
The PowerDNS 3.0 release is out. "The largest news in 3.0 is of
course the advent of DNSSEC. Not only does PowerDNS now (finally) support
DNSSEC, we think that our support of this important protocol is among the
easiest to use available.
" Other new features include TSIG support,
a MyDNS-compatible backend, Lua-based incoming zone editing, a native
Oracle backend, and more.
Full Story (comments: none)
is an audio tool
"which allows to analyze samples of musical instruments, and to
combine them (morphing). It can be used to construct hybrid sounds, for
instance a sound between a trumpet and a flute; or smooth transitions, for
instance a sound that starts as a trumpet and then gradually changes to a
" The 0.2.0 release - the first to actually support morphing,
is now available. Other new features include a BEAST plugin, JACK support,
a graphical instrument inspector, and more.
Full Story (comments: none)
Newsletters and articles
Comments (none posted)
Ross Bencina has put up an
introduction to glitch-free audio programming
"The main problems I'm concerned with here are with code that runs
with unpredictable or un-bounded execution time. That is, you're unable to
predict in advance how long a function or algorithm will take to
complete. Perhaps this is because the algorithm you chose isn't
appropriate, or perhaps it's because you don't understand the temporal
behavior of the code you're calling. Whatever the cause, the result is the
same: sooner or later your code will take longer than the buffer period and
your audio will glitch.
Comments (14 posted)
Dave Phillips begins
a three part review of SuperCollider on Linux Journal. "SuperCollider is composer/programmer James McCartney's gift to the world of open-source audio synthesis/composition environments. In its current manifestation, SuperCollider3 includes capabilities for a wide variety of sound synthesis and signal processing methods, cross-platform integrated GUI components for designing interfaces for interactive performance, support for remote control by various external devices, and a rich set of tools for algorithmic music and sound composition. And yes, there's more, much more.
Comments (none posted)
Eric Allman takes
another look at Postel's law
("be conservative in what you send,
liberal in what you accept") in the Communications of the ACM. "For
many years the Robustness Principle was accepted dogma, failing more when
it was ignored rather than when practiced. In recent years, however, that
principle has been challenged. This isn't because implementers have gotten
more stupid, but rather because the world has become more hostile. Two
general problem areas are impacted by the Robustness Principle: orderly
interoperability and security.
Comments (22 posted)
Page editor: Jonathan Corbet
Next page: Announcements>>