Hi, the clarity you bring into the discussion is delighting. So is the depth of analysis.
I did realize before that making a simulated copy from a revocable copy does defeat the revocation mechanism. In my recollection we even talked about this in Dijon, very briefly. I think you pointed out this defect, and I argued the following way how you can "repair" the ability to revoke: We can have a special bit in the capability, that works in the same way as access bits (rwx) (ie, can be cleared by the sender, but not set), which has the following semantics: If the bit is set, then revocation can be defeated by performing a simulated copy. If the bit is cleared, then the cap server will deny a request to make a simulated copy: The revocability property wins. At the time you pointed out that one should reconsider a design that requires adding more and more bits and features to make it work right, and that was of course spot on. Now you add another argument: That simulated copies only works at the "lowest level": As soon as a revocable copy is made that doesn't allow simulated copies, you can not make simulated copies of _that_ capability. And this is perfectly true. Is this a critical failure? If you are a purist, definitely. In practice, I am not so sure. So far, in our design, we only wanted to use simulated copies or revocable copies. I have not encountered a situation where I would want to make a simulated copy of an explicitely[1] revocable copy ([1]for lack of a better terminology). All this means is of course that either our hierarchies are, in fact, extremely flat, or we have just not foreseen all our requirements yet. Of course, this is just a playful way of saying the following: The _only_ system you can reasonably implement with such a cap server is one with a flat capability hierarchy. And in such type of systems, I guess, you really want the copy operation to be the primitive operation, and not revocable copy. And the other way round: In a system with deep hierarchies, simulated copy is not adequate enough. So, in either type of systems, you need the copy operation as a primitive operation (and I think you also need revocable copy, but we already knew that). So, yes, I think you hit the nail on the head and drove it home. What follows is just some further elaborations on the subject. Here is what you _could_ do, but let me point out that I am not saying that we should do it. The capability server could support a new object type, a "wrapper object" that does "transparent" forwarding. Originally, I was going to say that B should implement such a wrapper object, but of course it can't, as then it could not exit without destroying all copies derived from the wrapper object! The wrapper object would "swallow" the revocable copy from A and provide normal-looking capabilities from which simulated copies can be made. Hey, I have just reinvented EROS wrapper objects in the cap server, except that because this is a user space extension of the IPC system, it sucks! At the very least it requires additional IPCs for the forwarding. Also, it can not be made transparent given current L4 designs. At this point it seems useful to point out that EROS wrapper objects can't be nested either, or only in a limited fashion. However, there is an important difference: In the EROS case it is a kernel implementation detail, while in the presently discussed case it is mainly a kernel interface and feature issue. And of course the performance and security implications (DoS attacks) of both solutions are _vastly_ different. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
