Re: Vulnerabilities in Synchronous IPC Designs

[Marcus Brinkmann]

On Mon, Jun 02, 2003 at 08:33:00PM +0200, Espen Skoglund wrote:
> It is trivial to add a check in the IDL compiler (and generated code)
> for the length of a variable length buffer.  If the variable length
> buffer fits within 256 bytes (or 512 bytes on 64-bit architectures),
> the content can be transferred using message registers.  If this is
> your only concern, then you shouldn't worry.  (I was actually sort of
> suprised to learn that IDL4 didn't support this in the current
> implementation.)

Well, it certainly would be useful to force IDL4 to use MRs if possible and
to avoid string buffers.  However, if we are talking about sufficiently
large arrays, that spill the available MRs, one of the other methods
(mappings or string items) must be used.

However, this is from my perspective not a transparent change.  The
semantics of the IPC change completely if mappings or string items have to
be transferred.  For mappings, the server must be careful to handle page
faults on the mapped pages.  For string items the client must be careful to
have all underlying pages locked down.  The client can assure that the
memory is wired down for the whole send phase (and/or receive phase) of the
RPC if we are doing user space paging, and available physical memory allows.
However, it must know when to do so.  IOW, the client must then be intimate
with the generated IDL4 stub, or IDL4 must make upcalls to make sure the
relevant buffers are faulted in and if possible wired down.

> 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.

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/