> However, honestly, that seems an absolutely unnecessary complication, since it's possible to just run any arbitrary binary code is a separate process, isolated by OS functionality that only allows a very limited set of system calls (e.g. seccomp in Linux).
Which is exactly what Chrome already does for its individual tab processes, so the Google folks are quite aware of this facility. They're going for more than just sandboxing of an individual process with NaCl, though.
> Windows might not provide a similar system call limitation feature, but it should be very easy to implement in a Windows kernel driver.
Actually, from all reports I've heard, Windows' built-in mechanisms for sandboxing are actually better than Linux's. (That is, at least when comparing Vista/7 to the least common denominator of what the popular Linux distributions provide; SELinux and such likely blow Windows out of the water in this area.)
> That would increase performance, allow to avoid having to use special compilers, as well as allowing trivial portability to any CPU with an MMU and built-in protection features.
I'm not sure at all that it would help performance compared to what Google is trying to do. One of the goals of what NaCl does with its opcode sanity checking is to allow trusted and untrusted code to exist inside the same process. That allows for trusted library code to be called by the untrusted application code without context switches, without IPC, without anything other than a simple function call.
For example, for something like a game, you probably don't want your D3D/GL calls to be going over an IPC mechanism. Especially when dealing with streaming buffer uploads and the like as that would just make NaCl useless for high-end games (or other graphically rich real-time interactive applications). So you want the actual NaCl process to directly communicate with the GPU driver, but you don't want the untrusted code to be able to do that itself. You also don't want the untrusted code to be able to access/subvert the memory owned by trusted parts of the same process, as that would subvert the sandbox. These goals require the opcode verification (and the accompanying x86 machine code restrictions) that NaCl enforces.