Re: Vulnerabilities in Synchronous IPC Designs

[Espen Skoglund]

[Marcus Brinkmann]
>> As for using string transfer instead of message registers, in the
>> current implementation of L4Ka::Pistachio, using string buffers
>> instead of message registers for messages containing less than 64
>> words is definitely going to be slower.

> I was advised by Volkmar to consider RPCs to be abstract, and leave
> the implementation details to IDL4 (or whatever the IDL compiler
> is).  The IDL compiler can then always pick the fastest mechanism on
> the platform in question.  However, we can not simply leave string
> buffers and mappings to the IDL compiler.  If the IDL compiler uses
> string buffers, the user must be given a chance to fault in and wire
> pages.  If the IDL compiler uses mappings, the server must be
> involved in protecting against page faults.

> I think that wiring down pages used for IPC in the client is a
> satisfying solution to avoid timeouts and truncation.  A simple
> upcall that locks and releases certain buffers could be done
> (optionally) by IDL4.

Another solution is for an application to have certain pinned memory
regions.  These regions can be used as temporary buffers for string
transfers that must not page fault.  Whether to use such a temporary
buffer or to pin memory dynamically will of course depend the amount
of data needing to be copied.  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).

        eSk