Re: Vulnerabilities in Synchronous IPC Designs

[Espen Skoglund]

[Marcus Brinkmann]
> On Mon, Jun 02, 2003 at 08:41:26PM +0200, Volkmar Uhlig wrote:

>> So one possible way to avoid the DoS is the following:
>> 
>> - Set receive transfer timeout to zero -- means that the first pagefault
>> will abort the IPC
>> - Clients have to touch (i.e. read) their message memory before sending
>> to make sure/likely it is paged in
>> - On pagefault the IPC is aborted immediately. Client and server get the
>> total amount of transferred bytes stored in the Error TCR
>> - now it is up to a to-be-defined protocol to either restart the message
>> or continue at the point of the pagefault

> This is barely useful because it would require the server to keep
> state between client RPCs.  If the client doesn't follow up with the
> rest of the string, the partial string consumes resources in the
> server, and the server must be prepared to find them back at the
> follow up RPC and deallocate them after some timeout if the client
> does not behave.  At least you have an upper bound on the number of
> such states you need to keep (one per client thread), but it is
> cumbersome.

For certain servers/protocols it certainly makes sense to resend the
whole message.  For other services it might make sense to only resend
part of the message.  For example, if a scatter-gather IPC to a
fileserver is aborted in the middle, the semantics of the agreed upon
protocol between the server and the client might be that the server
will commit all the disk blocks which were actually transferred to the
server.  The client then only needs to resend part of the whole
message.  No extra state needs to be kept at the server side.

It is important to remember that aborting IPC operations is an
exceptional event and should therefore be handled accordingly (i.e.,
the implementation should not be optimized around handling these
cases).

        eSk