l4-hurd
[Top][All Lists]
Advanced

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

Re: Vulnerabilities in Synchronous IPC Designs


From: Espen Skoglund
Subject: Re: Vulnerabilities in Synchronous IPC Designs
Date: Mon, 2 Jun 2003 20:33:00 +0200

[Marcus Brinkmann]
> 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).

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

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.  As can be seen on the
L4Ka::Pistachio webpage, transferring 64 words takes ~150 cycles
longer than 1 word on an 800MHz PIII.  Of course, using message
registers might require a larger cache footprint due to copying
to/from the message registers.  On the other hand, string transfer
might cause an even larger cache footprint due to all the code needed
to set up temporary mappings.

        eSk





reply via email to

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