rudykoot at hotmail.com
Thu Jan 1 08:54:37 CET 2004
Some comments and questions to about 5 different e-mails:
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.
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.
> 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.
>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
>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.
>- 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
>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