[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
abstraction.
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/
- Vulnerabilities in Synchronous IPC Designs, Jean-Charles Salzeber, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Espen Skoglund, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Jean-Charles Salzeber, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Niels Möller, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Espen Skoglund, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs,
Marcus Brinkmann <=
- Re: Vulnerabilities in Synchronous IPC Designs, Espen Skoglund, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Marcus Brinkmann, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Espen Skoglund, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Marcus Brinkmann, 2003/06/02
- Re: Vulnerabilities in Synchronous IPC Designs, Andreas Haeberlen, 2003/06/03
- Re: Vulnerabilities in Synchronous IPC Designs, Marcus Brinkmann, 2003/06/03
- Re: Vulnerabilities in Synchronous IPC Designs, Niels Möller, 2003/06/03
- Re: Vulnerabilities in Synchronous IPC Designs, Espen Skoglund, 2003/06/03
- Re: Vulnerabilities in Synchronous IPC Designs, Niels Möller, 2003/06/03
- Re: Vulnerabilities in Synchronous IPC Designs, Kip Macy, 2003/06/06