IPC/Capabilities Overview

Rudy Koot rudykoot at hotmail.com
Thu Jan 1 08:54:37 CET 2004

Some comments and questions to about 5 different e-mails:

===== Rudy

Some of Volkmar's arguments are based on the fact that L4 is a general 
purpose microkernel, I think the discussion would be more useful if we look 
at how a microkernel with the purpose of running a capability based system 
on top, should be design. Leaving the question wheter those capabilities 
should be implemented at kernel-level or user-level open.

===== Rudy

Any form of IPC in which the decission to allow or disallow a thread to send 
a message to another thread is vulnerable to a DoS attack. If the decission 
is mad by the kernel the IPC can be canceled immediately, but if it is made 
at user level another thread is blocked for a small amount of time.

=====  Shap

>   b) For some types of systems (capability systems), disclosure of
>      the sender id is an absolute violation of design requirements,
>      so any microkernel that relies exclusively on server-side
>      security checks based on sender-id is not a universal microkernel.

Sorry, but you still owe me an example of a situation in which revealing the 
sender-id actually breaks the security of the system. The only thing I could 
think of was that it might reveal some details about the internal structure 
of an application, but if the system is secure that information hasn't got 
much use to a malicious program or user.

I really think this is an important point. If revealing the sender-id is 
indeed a violation of security, there wouldn't be a need to discuss wheter 
or not thread-spaces need to be implemented. They just have to.

>   c) More specifically, any microkernel that requires checks based
>      on sender-id is entirely unsuitable as a platform for EROS-NG.


===== Volkmar

>Assume you add 2 more TLB entries and 5 more L2 cache lines--your
>aftercosts for IPC go up by 2*80 + 5*80 = 560 cycles.
>Considering overall IPC costs of 1000 cycles on a P4 with all those
>nasty cache and TLB flushes you add an overhead of >50%.

I believe these costs are exagerated. To convert a capability into sender-id 
a simple table lookup can be used. This requires a single TLB entry and a 
single L2 cache line (worst case). If IPC is frequent, which is the case in 
which you want high performance, the TLB entry is very likely to be present 
and probably even the L2 cache line.

This is supported by your own description how access checks are done at user 
level (although this is actually the reverse as you point out, the methode 
stays the same):

>In our case we use an object identifier in the message, which is a
>handle to an object descriptor and do a reverse check (i.e. if the
>thread is allowed to invoke that object).  Costs: boundary check (can be
>a simple AND) one MOV and a CMP.  The permissions can go into the same
>cache line.

===== Volkmar

>A possibility you did not mention is a hybrid thread id which has an
>thread and a descriptor part.  The descriptor is kernel enforced.  That
>is what we currently have in V4 (please not that V2 and X.0 are
>completely outdated!!!)--the version part of the thread id.

Sorry, but I do not see how the version part could be used as the server 
defined word. You can't have multiple versions (read server defined words) 
of the same thread-id at the same time.

===== Volkmar

>- local data structures--or do you want to share your cap-tables on NUMA
>systems between processors?  How do you plan to memory-manage those?

I generaly don't worry too much about performance as long as it scales wth 
processor speed/count. This argument is indeed a sane one. However I do 
believe it is possible to use the techiques to gain better performance used 
at user-level can also be applied to a kernel-level methode.

This does bring up another question. How do you memory manage TCBs in L4 on 
NUMA systems?

===== Volkmar

>That is exactly the point.  If you add that feature to the kernel you
>pay on _every_ system, even if it does not need any security mechansims
>at all (or only very rudimentary).  Hence, moving it to user land
>eliminates it from the critical path and makes other scenarios faster
>(without, from my perspective, massively hurting systems which need and
>want such security models).

Whoch person with a sane mind would want to implement an unsecure operating 
system on top of a microkernel? That's just not a smart thing to do. The 
only reason microkernels still exists is because they offermore security and 
are more flexible. And unsecure systems are also systems that wnat maximum 
performance (so they don't want to run on top of a microkernel) and for that 
same reson don't need the flexibility. Unsecure operating systems no longer 
run on servers, workstations and dektops. They are only used for embedded 
systems, and those are unlikely to run ontop of L4.

-- Rudy Koot

Hotmail en Messenger on the move 

More information about the l4-hackers mailing list