At Fri, 10 Jun 2005 16:55:05 +0200, Bernhard Kauer kauer@os.inf.tu-dresden.de wrote:
Within this framework, the only directly supported operations on such capabilities are map, grant, unmap and IPC. The map operation can be used to delegate the capability, grant can be used to move the capability and unmap to revoke it. The IPC operation allows clients to send messages to an object, for example, to invoke operations on the object.
I think here is a difference to our view on capabilities: The IPC operation allows to send a message through an endpoint to a server. The server could somehow identify the sender of a message.
The question here is really if the L4 IPC "capabilities", ie communication end points, can be used to implement "capabilities" of a capability system. The answer of course differs, depending on which requirements you choose for the capability system. We are looking here specifically at a requirement for a certain form of rights amplification, or synergy in general.
You seem to say that this should not even be attempted. But that would be pretty sad, because L4 end points almost have all properties that are needed, and only little needs to be added. And from experience, capabilities without any kernel support just don't work.
By using the sender id as an reference for a user, this problem is gone.
The problem is not gone. Or rather, it is gone like a leg is gone if you amputate it because of a broken toe. Paul Watzlawick calls this "Patt-End" solutions. ;) [1]
This is because you still have to implement a capability system, but now without any kernel support whatsoever. That just doesn't work. It was a pain to do in L4 X.2, but in the upcoming L4 designs, it would be even harder because now you also have to reintroduce global IDs for tasks in userspace, and that is not easy. This would mean that instead of taking advantage of the upcoming security features, we would have to battle and overcome them. That makes little sense to me, in particular if alternatives are pretty attractive from our point of view.
To demonstrate the difference between these two attempts, look at a simple fileserver. If only read/write operations are needed the sender id could be the file number. But with an operation which needs multiple files like copying between two files, the sender id should identify only the user, but not the file anymore.
I am very aware of the differences. We have been there, done that, and it just doesn't lead to a feasible system. It's not that you can't do it at all. It just has all the wrong consequences: You keep compromising one thing over another (performance over security, code simplicity over performance, and so on) and once you look at end-to-end performance, you will actually find Mach interesting again. It's that bad.
Can you show me protected capability systems which are implemented on L4 that work the way you suggest? The "best" I can see is Mungi, and that uses random OIDs, and thus doesn't even enter the picture, because it is not a protected capability system at all. And from what you said, the upcoming L4 design won't change a thing, and just make it harder.
I think that there is an excellent chance that the upcoming security features can be used to build a fast and secure object/capability system. Solving the problem of multiple object references in messages is essential for that. However, I am even more sure that without any kernel support, implementing a competitive and secure capability system on top of L4 is nigh impossible.
I am not sure what further evidence I could give you that the suggestion you make just doesn't work. My own failed attempt and lack of any other attempts in that direction are the reasons I can bring forward. I have tried really, really hard to make it work. It could just be my personal failure. But it could also be a shortcoming of the L4 design.
Maybe L4 is not supposed to support protected capability systems of the type I imagine. But that is not what you are saying---you are saying I should pursue a path I have already walked and found to be miserable. I can only ask you to reconsider my argument, or to be much, much, much more specific about how to do it the way you suggest.
Thanks, Marcus
[1] Solutions which are so good that they not only remove the problem, but everything associated with it.