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

[Jonathan S. Shapiro]

On Mon, 2008-03-24 at 15:00 -0700, Jed Donnelley wrote:
> 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?

Yes. More precisely: any place where parameters are passed by copy.
Responses to database queries are another example.

>   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.

Yes, but this has a price. The price is that GC must now cross domain
boundaries, because it becomes possible for more than one domain to hold
a reference to a piece of state. Also, it can create storage reclaim
issues if it isn't handled with some care.

> 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?

Yes, in part, but there is also a failure isolation concern. Also, for
language based systems, there is a typing concern.

> >> 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.

How is that any different from what happens in domain crossings anywhere
else?

I think you are tacitly assuming that domain calls will be normal
procedure calls. No sensible design would do this. IDC (inter-domain
call) replaces IPC. What is eliminated is the address space crossing
issue.

shap