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: Niels Möller
Subject: Re: Vulnerabilities in Synchronous IPC Designs
Date: 03 Jun 2003 14:47:44 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Espen Skoglund <address@hidden> writes:

> Consider the following considerations that the IDL compiler must make
> in order to generate fully optimized IPC operations:

Perhaps I'm naive, but to me it seems like most of the differences can
be parametrized. Like "arrays of a max length less than
ARRAY_WORDS_THRESHOLD are always passed in the MR registers. For the
value of ARRAY_WORDS_THRESHOLD on your system, refer to
../include/idl4-machine.h."

>   o The CPU to optimize for (PentiumIII vs. Pentium4 vs. Athlon,
>     Itanium vs. Itanium2, etc.)

Do you really want use different protocols (as opposed to different
code implementing a single protocol) for different cpu:s? I think I'd
prefer to be able to use a client compiled on a PentiumIII to talk to
a server compiled for an Athlon. About the same applies to
kernel-version specific tweaks.

The way the L4 ipc primitive are used to implement "system calls" to
various servers is really a part of the system ABI. And I think we
want to stay with a small number of ABI:s, preferably only one per cpu
family. Defining the system ABI used to access, say, a filesystem
server, or the task server, as "whatever was implemented in version
1.17 of idl4" is not quite satisfactory.

(If you really want per cpu optimizations, you could use explicitly
parameterized protocols. For example, to pass a variable length array,
you could let the caller split it into two pieces in any way it likes,
and specify the call as

  MR1 is the number of message registers (starting from MR2) used for
  the initial part of array. The tail of the array, if any, is passed
  using a buffer register.

But that also adds complexity).

/Niels




reply via email to

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