IPC Timeouts

[Marcus Brinkmann]

At Wed, 23 Feb 2005 19:49:44 +0100 (CET),
"Ronald Aigner" <ra3 at os.inf.tu-dresden.de> wrote:
> It was brought to my attention that pagefault timeouts _are_ important as
> to enforce trust relation with your communication partner. I don't know
> what the semantic of a zero pagefault timeout is. If it means that the
> page has to be present and a infinite pagefault timeout means that you
> don't care, then finite pagefault timeouts seems reasonable. Still,
> defining a useful value seems unpractical to me.

If you use string items in a reply from a server to the client, I
think even small timeouts can be used for DoS attacks.  This is why I
use timeout and transfer timeout 0 for all IPC from the server to the
client.  The client just has to be ready, and all buffers to receive
string items need to be wired down (or other mechanisms need to be
used, like trusted buffer objects, or resuming the operation for the
not-transfered data).  Of course, other systems may have different
trust considerations.

To answer your original question:

Finite IPC timeouts seem to be necessary to sleep for a specified time
(receiving from yourself), for implementing functions like sleep() and
timed waits on a synchronization primitive.  I don't care much about
the mechanism, but it must be robust - dropping a timeout and thus
going into an infinite receive does not seem to be enough to me (maybe
I misunderstood your proposal).

However, a slightly different scheme could work.  The timer event is
not dropped, but instead defered - the next time the thread does an
IPC, and there are no pending partners, it is canceled immediately and
does not block.  In addition, any IPC operation will always clear any
pending timer before it returns (so it won't accidentially affect
later IPC operations).  I have not thought this completely through -
there seems to be some hair attached.

It's interesting that you raise this issue though - we have a patch
for L4 that implements asymmetric xfer timeouts (ie, the timeout
depends on where the page fault happens), and the semantics are clear
if you have only 0 or inf timeouts, but a bit unclear when you have
other timeouts _and_ multiple page faults, some in the sender and some
in the receiver (this is why we opted for another, simpler asymmetric
xfer timeout scheme, where the xfer timeout for local pagefaults
always defaults to "infinite").

Thanks,
Marcus