[Top][All Lists]

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

Re: Vulnerabilities in Synchronous IPC Designs

From: Marcus Brinkmann
Subject: Re: Vulnerabilities in Synchronous IPC Designs
Date: Mon, 2 Jun 2003 19:07:04 +0200
User-agent: Mutt/1.5.4i

On Mon, Jun 02, 2003 at 06:42:17PM +0200, Espen Skoglund wrote:
> As I said in my original mail, this whole timeout problem would
> probably not apply to most servers anyway.  If you can construct your
> message in less than 64 words (message registers) you're fine.  If you
> construct your message using mappings you're also fine.

Note that it appears that IDL4 seems to happily use string buffers for any
variable length argument, irregardless of any length restriction (which
might even be so small as to guarantee that it always fits into the msg
registers) or actual length at runtime.

I think that passing variable length arrays is a very common thing to do. 
For example, if you want to pass a list of user IDs, or, well, strings.
A restriction to 64*4 = 256 bytes (less if you have other arguments) is not
quite acceptable.  Also, using string buffers might be faster than message
registers with, for example, more than 30 machine words.  However, having
the overhead of using mappings for any variable length data isn't appealing
to me (for example, one often used RPC might be dir_lookup that looks up a
file in a directory, and has to pass the filename - filenames over ~200
characters are not particularly unusual).

Using mappings is not better than just using a xfer timeout of 0 in the
first place.  The issue here is then to ensure in the client that no
pagefault arises during xfer by locking down the memory holding the string
buffer data.  However, I don't think IDL4 provides callbacks for that.
If this must be done in preparation to invoking an RPC, it breaks the


`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/

reply via email to

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