Re: ipc security

[Marcus Brinkmann]

At Fri, 08 Oct 2004 19:41:16 +0200,
Bas Wijnen <address@hidden> wrote:
> My problem is on page 63 of the reference manual, where Xfer pagefaults 
> are described.

Volker already explained that.  There is another mail by me continuing
this discussion, so I will stick to containers only in this mail.

> > Using containers is _very_ expensive and may be even more complicated
> > to use properly than string items.
> 
> Aren't containers just memory pages which are mapped into more than one 
> address space?

Containers are objects in physmem, from which you can create mappings,
yes.  But this means that you have to create them in physmem, grant
permission to the server to map them, and in the server you must make
sure that the user does not access them while you are using them.
When you return to the user, the user may have to revoke permission of
the server to the container etc.  There is a lot of overhead.

Sure, you can pre-create containers and provide them in numbers
up-front to servers to reduce the overhead at the time of the actual
RPC, and I suppose that this is an important optimization.  But it's
still more expensive.

BTW, I am talking here about the client and server sharing a container
directly.  No "container manager" is required (in some sense, you can
call physmem to be that manager).

> It seems to me you think there 
> is more overhead than that.  Am I missing something?  Or do you think 
> the container must be resized in the operation?  That can happen 
> sometimes, but I think it should be possible to give it a reasonable 
> size, so it doesn't need to resize often.

As containers involve several calls to physmem, including mapping
operations, for me this means additional context switches and
latencies.  And yes, copying the data if required.  If you compare
this with string items, it is much more expensive.

Containers are intended for use of I/O of data in large chunks, like
several kilobytes at a time usually.  For example, we can use them in
the stream library.  You can also use them for read/write (although
for smaller reads and writes it's worth to use string items and
read/write directly from/to the user provided buffers).  The decisions
which to use when can be made transparently in the C library (maybe
even with hints from the user, or heuristics).

In any case, I don't want to paint a black picture of containers.  As
they are in the I/O path, their performance is critical and we will
have to make them fast.  But I am doubtful if we can make them so fast
that you can use them instead of string items everywhere, and
actually, I don't see a reason to avoid string items, if we use them
correctly.

Thanks,
Marcus