Check out the new USENIX Web site. next up previous
Next: Extensibility of User-level Sandboxing Up: Implementation on Windows NT Previous: Experience with NT implementation

Differences in Linux implementation

Linux provides support very similar to Windows NT for instrumenting application binaries, and monitoring and controlling resource consumption. For instance, library functions such as the sockets and memory allocation APIs, can be intercepted by preloading shared libraries. The mechanisms and performance of network bandwidth control are identical across the Windows NT and Linux platforms. However, there are small differences in how CPU and memory resources are constrained under Linux.

Controlling CPU resource    Adjusting scheduling priorities requires superuser privilege on Linux. Therefore, we use a scheme based on thread suspend/resume: the sandbox sends an application a SIGSTOP signal to suspend and a SIGCONT signal to resume its execution.

Controlling memory resource    Linux provides a setrlimit API for limiting the maximum amount of physical memory a process can use. However, current versions of the kernel (e.g., v2.2.12) do not enforce this constraint. Consequently, we adopt a scheme identical to the one on NT. However, unlike on NT, where an implicit protocol (using NoAccess protection bits) between the OS and the application permits the former to collect pages not required by the latter, no such protocol exists on Linux. The page protection bits can be set as on NT, but the kernel swapper ( kswapd), does not check the page attributes to decide which page must be swapped out.

We get around this problem somewhat inelegantly by handling the swapping ourselves. First, we intercept memory allocation functions (e.g., malloc) to make sure that only the requested amount of physical memory is kept valid; all other memory pages are protected to be unavailable for access. When a page fault happens due to invalid access, we pick another page (in FIFO order) from the resident set (maintained by the sandboxing code), save its contents to our own swap file, and take it out of the resident set using the munmap mechanism in Linux. Subsequently, an invalid access requires that the saved contents be mapped back to the corresponding virtual address.


next up previous
Next: Extensibility of User-level Sandboxing Up: Implementation on Windows NT Previous: Experience with NT implementation

Fangzhe Chang, Ayal Itzkovitz, and Vijay Karamcheti 
2000-05-15