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.
Why?
===== 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 http://www.msn.nl/communicatie/smsdiensten/hotmailsmsv2/