Re: Vulnerabilities in Synchronous IPC Designs

[Marcus Brinkmann]

On Mon, Jun 02, 2003 at 10:31:45PM +0200, Espen Skoglund wrote:
> A more promising alternative (IMO) is
> to have the IDL compiler automatically handle IPC abort cases due to
> string copy pagefaults and issue retry RPCs.  This is what I meant in
> my previous posting on this thread about not optimizing for the
> exceptional case (i.e., use optimistic protocols that handle the
> exceptions as they arise rather than going to great troubles to avoid
> the exceptions in the first place).

I think that this is perfectly adequate for the send phase of an RPC, where
the server has not yet processed the message.  This is in particular relevant
if the bare words in the message actually carry semantic meaning and can be
"consumed".  For such arguments, special clean up and set up operations are
necessary before the operation can be retried, and I am not sure you want
this to be part of the IDL compiler (so far I thought of such specially
typed argument as being part of one level above the IDL compiler).

Another example is an atomic (for clients) exchange of a string in the
server: As long as the send fails, nothing is lost.  But if the reply is
lost, then the old value will be gone (the server should not be obliged to
cache it for the client).  This is a contrieved example, of course, but it
illustrates the problem.

For the receive phase, I actually think that using a pinned down buffer is
a good compromise.  As you don't know how much space to allocate before you
see the data, you probably want to allocate a fitting area after receive and
copy the data into it anyway (for strings with a large bound this is
particularly important to not waste memory, while for strings with a small
bound you will not waste much time by this extra copy).  This assumes that
you want to save the result, if you process it directly no copy is needed
of course.  Such pinned down areas can be managed dynamically and be
requested by the IDL compiler on demand.  Assuming that such special RPCs
requiring this are few there will probably only a few threads in such an RPC
at the same time, and being space conservative in dealing with pinned memory
is certainly not a bad idea.

As Volkmar pointed out, this behaviour could be used for explicitely or
implicitely tagged RPCs which are difficult or impossible to retry.

All the other options are then still available for the simpler or harder
cases.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/