rudykoot at hotmail.com
Thu Dec 25 00:44:04 CET 2003
Just to avoid any confusion. Can you tell me if I got this right:
There are three possible ways to restict/allow communication between
* 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
* 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
* 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,
Hotmail en Messenger on the move
More information about the l4-hackers