IPC/Capabilities Overview

[Rudy Koot]

Just to avoid any confusion. Can you tell me if I got this right:

There are three possible ways to restict/allow communication between 
threads, using

* Thread IDs (current L4 v4 implementation)
Any thread can communicate to any thread and send any message. Access checks 
need to be done by the server, that might need to verify some things using 
another 'security' server, requiring another IPC. The IPCs itself are very 
fast because no table lookups are necessary to verify if the communication 
is allows. However suity holes are much easier to created by buggy code that 
forgets to verify some accesses. Additionally the security checks are 
executed even slower than if they where done inside the kernel as in the 
other two methodes. These security checks can be done automatically using 
IPC redirection. This still requires an additional IPC, had some strange 
(unclean) quircks associated with it and I still doubt wether this methode 
is secure especially when used by buggy programs.


* Virtual Thread Objects (possible L4 v5 implementation)
Each thread has a kernel table attached to it (1) which lists the threads it 
can communicate to. These virtual thread objects can be grranted, mapped and 
unmapped just like flexpages. So when a message is received the server can 
be sure it is send by a thread that is mapped it's thread ID to.

(1) Threads in the same address space might share the same table.


* Capabilities (current EROS implementation)
Capabilities are similar to Virtual Thread Objects except that they have a 
server defined word attached to them.


I first want to make clear why the second and third methode are much better 
than the first:

* Methode 1 is insecured when used with buggy programs. The fact simply is 
that most, if not all, programs are buggy. I agree with shap that the cost 
of a program should be measured in total resources used (dollars or 
additional programming time for example) and not just computational 
resources.
* In a system that requires security the 2nd and 3rd methodes are actually 
faster because only a single, cimple kernel check needs to be made agisnt 
several complex user checks for methode 1 (is this realy true? comments 
please). L4 is designed to be secure anyway and is therefore already to slow 
for systems that don't require security, so the penalty the insecure systems 
woudl suffer does not apply.
* Additional security benefits are that the internal thread structure is not 
revealed to every program running on the system and some protection against 
DoS attacks is offered.


Now I want to make clear why capablities are much better than virtual thread 
objects:

* The extra word does not seem to decrease performance in any way (is this 
true?) so it a free feature, that can be used but doesn't have to.
* The server defined word will probably be used to store a pointer to some 
client specific data structure containing important information that needs 
to be access often. You might say, yeah well mbut you can calculate this 
address from the sender ID, but this no longer works when clients start to 
grant and map server objects/capabilites to eachother, because the server 
doesn't know about these actions, unless some complex, slow protocol is used 
to update the serves information.


My conclusion is that Virtual Thread Objects/Capabilities are far supiror 
than just using Thread IDs and that the server defined word of Capabilities 
are very important to manage information of a server. The size of the 
capability should be equal to the pointer/word size of the machine.


Constructive criticism is very much appreciated,

Rudy Koot

_________________________________________________________________
Hotmail en Messenger on the move 
http://www.msn.nl/communicatie/smsdiensten/hotmailsmsv2/