Re: local vs global object IDs

[Marcus Brinkmann]

Espen Skoglund <address@hidden> schrieb:
> [Marcus Brinkmann]
> >> One thing a persistent communication client library could do is add
> >> information in this data structure on whether the thread ID refers
> >> to a persistent task and what its PID or path is.  In case an IPC
> >> fails because the thread ID is invalid, it could use this
> >> information to try to get the new thread ID for this task (by
> >> asking the relevant server).

> > In Espen's model, you would use the version ID of a thread to notice
> > if the old thread died.  I believe this to be dangerous on 32 bit
> > architectures, as 14 bits are very easily overrun, and more complex
> > strategies (not reusing thread numbers for a while if all version
> > IDs have been used) are just that: more complex and probably a huge
> > performance issue (you want to keep thread numbers low and
> > unfragmented to preserve kernel memory).

> In the model I suppose you are referring to, more or less the whole
> system would be perstistent.

However, even in such a system you need IPC security.  My basic assumption
is always that direct thread to thread communication is allowed (no
redirector is forced upon clients), and that communication partners are not
necessarily trusted.  The problem is making sure that a message is sent to
the same thread as it was sent to previously (using the same thread id),
and this seems to be independent of persistence.

Using version IDs is fine, as long as you can guarantee that the version IDs
are not reused.  This means that if a malicious client creates and destroys a
thread a couple of hundred thousand times (which, thanks to L4, is rocking
fast :), you either need to detect that and somehow throttle or stop the
client from burning version IDs like that, or somehow else make sure you
don't reuse thread ids (including the version part).

Or, to word it differently: How can the system make a guarantee to all tasks
that they don't get confused by reused thread IDs and sent the message with
the important password to a malicious task that disguises as a trusted task
that used to exist.  If version IDs are a (virtually) infinite resource, this
is easy.  However, 2^14 (16384) is far, far away from being infinite and
easily exhausted.  Setting limits on thread creation on clients doesn't seem
to be affective, as then any number of N clients can collaborate in an attack.

For a generic capabilities based system, this is a fundamental bootstrap
issue.

Thanks,
Marcus