[cap-talk] Google's Native Client (NaCl)

[Mark Seaborn]

On Mon, 2009-10-05 at 22:20 +0100, Sam Mason wrote:
> On Mon, Oct 05, 2009 at 09:02:26PM +0000, Karp, Alan H wrote:
> > Minor point.  I don't recall seeing anything to indicate that NaCl
> > uses capabilities.
> 
> It's structure seemed a very capability-like design to me.  It starts
> confined and communication to and from a nativeclient seems through a
> "NaCl socket", it's the calling code's choice which other NaCl modules
> it sees, and so on.  The original paper[1] says:
> 
>   NaCl resource descriptors are analogous to capabilities in systems
>   such as EROS.

They are actually closer to Unix sockets than to EROS capabilities.

NaCl's system call interface is quite Unixy.  NaCl sockets are basically
the same as Linux SOCK_SEQPACKET sockets - that is, reliable datagram
connections.  NaCl allows you to create socket pairs (bidirectional
connections) and send FDs across sockets.  Byte stream connections
(SOCK_STREAM in Unix) are not available.

NaCl has an mmap() system call, and there are file FDs (for read-only
files fetched through the browser) and FDs for shared memory regions.

There is no filesystem, at least for NaCl processes running inside the
Web browser.  There is an open() system call, but it is for testing
purposes and is only available in debug mode.  My glibc port provides an
open() *library* call, which operates via RPC over a socket (as in
Plash), where the RPC calls are handled by Javascript.

It's not yet clear to me whether NaCl is going to end up with ambient
authority, or features that are hard to virtualise.  There is (or was) a
special syscall for setting up graphics rendering via shared memory.
I'm not sure if it is still there.  I'd like to see this syscall be
replaced with an RPC over a socket.

At the moment I don't think there is a general way to launch multiple
processes and connect them together via sockets, so the issue of
protecting one NaCl process from another has not really come up.

Mark