At Tue, 14 Jun 2005 11:10:22 +0200, Bernhard Kauer kauer@os.inf.tu-dresden.de wrote:
We are turning in circles. This is exactly the same model as you suggested in your first reply. And it is exactly the model I have already tried to implement, and that we rejected because of performance, wrong security properties, impossibility of transparent interposition, code complexity, etc.
I forgot to explain why I switched back to the initial model. We have here 2 models in our discussion:
Using a 1:1 mapping between objects and endpoints. This requires a cmp() function.
Using the features of L4.sec (local names, endpoints and badges) to implement a capability system in user-level.
I think that is a fair representation of the two branches of the discussion.
We all agree that the first one can be build, looking from a functional point of view. This does not mean that it is the best solution.
Or in other words some disadvantages (waste kernel memory, needs an additional kernel operation,...) leads to the question whether the second model could also be built.
It was my understanding that it is an essential part of the design roadmap for both of the two upcoming L4 designs that some kernel memory is managed in user space.
You already make the concession that users can allocate kernel memory by creating communication end points. It doesn't make much sense to me to now say that this should be restricted to a very small number of such allocations per task. In either case this is something that should be regulated by user space policy, and not by the kernel. Otherwise this indicates again a defect (of a different type) in your design.
L4 X.2 had only one way for a user to allocate kernel memory, by sending a mapping from one address space to another, and that could be restricted by using a redirector. So it was quite safe, although there was still a defect: There was no way for a memory manager to reliably know how much kernel memory was needed for a given users mappings. So, there is some argument to be made that even without L4.sec the memory management model of the L4 kernel is underdeveloped.
In fact, I think that to become a mature product, L4 must solve the kernel memory problem in a fundamental way, because in a production system having the kernel crash because it is out of memory is a major issue.
The need for an additional kernel operation should concern you. But it is my opinion that this is in fact a clue that there is a whole area of endovement in which L4 is underdesigned, and a great opportunity for the L4 group to explore. But of course I first need to convince you that the alternative is not an option ;)
Perhaps we should split the discussion here and try to answer in one thread the question of the first model (e.g. why cmp() and not map_lookup(),...) and in another one the problems with the second model you mention in your last mail.
I would be more than happy with that.
Thanks, Marcus