[cap-talk] Domain change (IPC?) overhead

[Jed Donnelley]

On 3/24/2008 12:41 PM, Jonathan S. Shapiro wrote:
> On Mon, 2008-03-24 at 11:54 -0700, Jed Donnelley wrote:
>> On 3/24/2008 9:52 AM, Jonathan S. Shapiro wrote:
>>> However: robustness implies introducing IPC, and each IPC adds overhead.
>>> As applications are factored and multiple layers of IPC are introduced,
>>> performance of IPC becomes critical very quickly.
>> Isn't the above consideration where the language systems for
>> POLA provide significant additional value?
> 
> Not clear. Depends on what percentage of your IPCs are doing data
> motion. If you want to avoid storage denial of service issues and keep
> GC local to each domain, you still have a copy boundary at the domain
> boundary, and the copy cost can get large.

I don't understand that above, but I'd like to.  When you say
"doing data motion", I guess you mean non-control bulk data
transfers - e.g. like a file I/O?  Some of our NLTSS experience
suggested that it was possible to push such bulk data movement
down through control stacks so that they matched up at a
data transfer level.

For example (hoping this is relevant to the above concern) our
file read and write operations passed what amounted to data
transfer (receive or send) capabilities to the file server
along with the other needed control information (the capability
to the file, what and where to transfer, etc.).  Hmmm.  Maybe
I'm seeing your point.  While one could imagine emulation
of the file capabilities themselves going through multiple
levels (e.g. membranes) without causing any more overhead
than "subroutine" parameter overhead, if the capabilities for
those data transfer operations go such layers of "emulation"
then it seems the data copies must be done multiple times
through the layers.  Is that your point above?

>> I'm still a bit skeptical in this area, being reluctant to
>> accept compilers/interpreters as part of my TCB...
> 
> Compilers are in your TCB either way unless you have a proof-generating
> compiler. Complexity of fast dynamic translation plus language runtime
> is probably less than complexity of microkernel. Optimizing dynamic
> translation is another matter, but that doesn't need to be in the TCB.

Hmmm.  I think I understand your point.  My concern about language
systems are not so much that they might be malicious, but rather
that there can be subtle issues in the domain protection mechanisms
(e.g. stack manipulation issues, etc.) that the language system
may miss that can be exploited by code intending to exploit such
flaws, code that is itself malicious.  To me (perhaps because I've
written a microkernel?) it seems simpler to provide the domain
protection in an IPC kernel (the interface is very well defined
and limited) than it is to protect separate domains in a language
system (compiled or interpreted).  Perhaps that view is distorted
by my experience?

--Jed  http://www.webstart.com/jed/