NaCl sel_ldr behavior and system calls

The Google NaCl SDK sel_ldr.py

(Native Client) has a (secure eelf loader) that allows the user to run an executable NaCl ( .nexe

) created with the NaCl or PNaCl toolchain. What exactly does it do sel_ldr.py

when these .nexe

files are run ?

Specifically, how does sel_ldr handle operating system calls to NaCl executables? Reading NaCl documentation. Most of the information pertains to using the enumeration API to build portable Chrome browser applications, and there is no detail on how sel_ldr service-runtime handles these NaCl binaries.

I have created many NaCl executables that while running in sel_ldr can create directories, files, pipes, hibernate and use various other system calls, and it works correctly. I know that the native client is in control of the system calls itself. Is this monitoring done using the enumeration API, or does sel_ldr.py intercept and redirect syscalls to implement native NaCl syscalls in its service sandbox?

+3


source to share


1 answer


NaCl is a small operating system that handles calls to the underlying operating system. The internal sandbox cannot make regular system calls (the validator enforces this), so it must go through the NaCl trampoline system calls, which flow to trusted code that performs similar checks that normal operating systems would do before calling the underlying operating system's own system call systems.

Pepper APIs are another syscall type, but they are only present when embedded in Chrome. Perfection calls are actually inter-process communication between the NaCl module and Chrome processes.



The overall implementation is the service runtime, a good description can be found in the original NaCl research paper . There's an older site (unfortunately not the current documentation) with syscall anatomy , and the source is clearly open source.

+4


source







All Articles