It sounds like there are a couple of good ideas here. Let me add my
refinements.
new_addr(); /* to get a secondary address space */
struct sandbox_params {
int return_reason;
int return_data;
int eax;
int ebx;
};
run_sandbox(int address_space, struct sandbox_params *params); /* to start a sandbox */
int fmmap(int address_space, void *start, size_t length, int prot,
int flags, int fd, off_t offset);
int fmunmap(int addresss_space, void *start, size_t length);
With the secondary address spaces being completely setup by uml.
And run_sandbox being the entry/exit point. The nice thing here is
that because they would share the same kernel stack/process most
registers can be left in registers. With run_sandbox putting as much
as possible on a fast path.
And then new_addr, fmmap, fmunmap would be all that you would really
need to manipulate those address spaces.
Usually processors only support a kernel/user space differentiation in
their page tables, and the sometimes support caching multiple address
spaces simultaneously cached in their tlbs. So I have designed this
interface to take advantage of the common processor features, and
additionally look as much like normal process execution as possible.
Any other implementation would need someone manually modify the page
tables, either the kernel or uml calling mprotect.
Any trap taken in the sandboxed address space should fill the
appropriate fields in struct sandbox_params and switch address spaces
back to the master process.
This interface is as cheap as I can imagine making it. And with
a little care can be really optimized on the kernel side if uml
becomes a common case.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 23 2002 - 21:00:40 EST