[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Vulnerabilities in Synchronous IPC Designs

From: Volkmar Uhlig
Subject: RE: Vulnerabilities in Synchronous IPC Designs
Date: Mon, 2 Jun 2003 22:35:00 +0200

> -----Original Message-----
> From: Marcus Brinkmann [mailto:address@hidden 
> Sent: Monday, June 02, 2003 10:09 PM
> > 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.

This heavily depends on the particular client and is just another aspect
of the interface stub, similar to performance.  If you have an interface
which requires wired memory for security reasons you should give this
information to the IDL compiler. Of course it requires certain
interaction with the memory subsystem.  If your IDL specifies that trust
and DoS is an issue the IDL compiler can choose the best optimization,
for example agressively avoid string copy IPC.

Furthermore, alternative methods to deal with timeouts are possible. For
example one could automatically resend the message on a fault, or
alternatively branch into an exception handler.  However, this is an
implementation and optimization detail. As long as the mechanism allows
to deal with the scenario we are fine.

- Volkmar

PS: Espen was a little faster, here my 2 cents anyway...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]