Google's Chromium sandbox
Posted Aug 20, 2009 0:43 UTC (Thu) by cventers
In reply to: Google's Chromium sandbox
Parent article: Google's Chromium sandbox
I should have been more clear about why a thread is needed. Certain
operations, memory allocation for example, cannot be done in one process
on behalf of another because they don't share address space.
On the contrary, I experimented with a technique to do just that. This
may not be the perfect solution for Chrome's needs, but I played around
with the idea of open()ing a shared memory segment on the vfs, using
ftruncate() to resize it, and then sending the fd via a UNIX-domain socket
to the untrusted process and allowing it to mmap() the pages.
Now, in my case, I was using this technique to allow dynamically-grown,
runtime-allocated shared memory segments between untrusted processes.
There are still complications (such as the need to install a SIGBUS
handler since the untrusted process might ftruncate() the mmaped fd() to
0, causing the trusted process to fault when it tries to access its own
mmap()), and perhaps the requirements for this kind of an implementation
are not easy to satisfy for desktop applications. But it's Linux, and
there's more than one way to do it. My implementation had the advantage of
being architecture-agnostic, as well-behaved user-space code should
to post comments)