On Mon, 2006-05-01 at 05:43 +0200, Marcus Brinkmann wrote: > At Sun, 30 Apr 2006 23:13:49 -0400, > "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > > 1. I create a new constructor, so I am the creator. I put stuff into the > > constructor. I instantiate programs. So far this is all just "trivial > > confinement" as you call it. > > In my current system design, there is no constructor. There is also > no meta-constructor, and the space bank will happily let you inspect > and alter the content of any memory that is taken from your reserve > (well, the last point may or may not be true, but for the purposes of > analysis, we can assume it to be true).
It follows immediately that the system administrator can inspect all storage, since all space banks are ultimately derived from the primary space bank, which is owned by the system administrator. So let us NOT assume this about the storage allocator for a moment. I want to establish that this assumption is actually essential in your proposal. Suppose that the storage allocator does not allow inspection of my reserve for page capabilities that I do not hold. In this case, I can fabricate a process, hand it to you, not tell you what it does, and you can use it (or not) as you wish. I can also fabricate a constructor, not tell you what it does, and you can instantiate copies of whatever it builds (or not) as you wish. There is ABSOLUTELY NO DIFFERENCE from the perspective of either disclosure or hiding. In the absence of such a difference, it is simply stupid to discard the mechanism. So we must now examine Marcus's *real* proposal, which is extremely radical: Marcus proposes that ownership of storage should imply the ability to read that storage. This proposal is consistent with the view that "I should control how the information flows in my computer" (i.e. in the storage that I own). It is consistent with the "no hidden bits" goal. But the really silly part is that this compromises the entire system architecture to no purpose, because it fundamentally does not solve the "no hidden bits" problem. I can still fabricate a process that runs completely out of *my* storage and hand it to you. You can run it or not, but you *still* can't know what it does. All that has actually been accomplished here is to guarantee that if you *do* talk to this process, you necessarily disclose information **to the creator of the process**. Remember those dialog boxes that let you say "I never want to send software registration information back to the vendor?" A naked storage allocator is a lot like removing that choice for the user. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
