Re: local vs global object IDs

[Espen Skoglund]

[Marcus Brinkmann]
> Espen Skoglund <address@hidden> schrieb:
>> [Marcus Brinkmann]
>>> 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.

Sure.  In the system I am talking about there exists only a handful of
system services that are transient.  These system services are started
upon bootup and must---since the persistent tasks rely upon
them---provide the same functionality each time.  The system services
also use the same thread number (but not necesarily the same version
ID).  Since the system services can not be stopped and started by
anyone there isn't really a problem with version ID overrun or
re-usage.  (As I said in my previous mail, there is only a problem if
the system reboots or restarts particular services exactly 2^14 times
in between two consecutive client requests.)

> [...] 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.

Not if the the thread number can not be used by any client (an
arbitrary client is usually not allowed to stop and restart a system
service).

        eSk