I think I've come up to a way to, as the subject suggests, reconcile constructor and virtualization.
I'll use the game with competition and cheating again. Here is how it goes: The administrator sets up a hall of fame service, in it's own specific session. The service is not advertised to users. Instead, all games using this facility are installed with a constructor. When the administrator installs such a game, it creates a constructor, gives it a capability to the hall of fame and then seals the constructor. When a user plays the game, it has an encapsulated process with a capability to the hall of fame which he cannot grab. So the user won't be able to fake records in the hall of fame. When one wants to cheat, the game just drop the capability to the hall of fame. This creates two problems: 1) if a user wants to inspect the process created by the constructor, and if encapsulation is only here to protect the capability, it should be possible to start a process that is both not encapsulated and lacking the capability. 2) if a user wants to start a sub-hurd, starting the game in the sub-hurd will break virtualization, as it is a unproxied capability to the outside of the sub-hurd. But why couldn't the user install the game, in a constructor or not, in this sub-hurd, with a capability to the hall of fame in the sub-hurd? So the solution to those two problems could be to semantically add a disclose flag to the constructor. When the flag is set, a requestor, instead of requesting the default, encapsulated and extra-authority provided, process, could request an unencapsulated process, without any additional capability. When it comes to implementation, the disclose flag could in fact be a capability to another constructor, which provides with a standard constructor method, the unencapsulated process. If it is implemented in a separated constructor, it is vital that the administrator cannot set himself the disclose capability. In any way, the system shall guarantee that the disclosed process is exactly the same as the encapsulated one. The constructor could be added a method, makeDisclosedConstructor(), that creates that constructor and sets up the appropriate capability, which could be grabbed by getDiscloseConstructor(). Or just added the getDisclosedProcess() method. Also, such a constructor could make possible to disclose the process afterward. That may be needed to be another afterwardDisclose flag for some reasons. So let's get back to the problems: 1) if I play the game and wants to inspect it for debugging, either running or not, I just ask the constructor a unencapsulated process or use the disclose capability to disclose the running process 2) when making a sub-hurd, I ask the constructor for an unencapsulated process, and I can then install it in a constructor in my sub-hurd, or install it without constructor, as I want Could it be a problem to add those disclose features to the constructor, and does it solve the incompatibility between virtualization and constructor? Curiously, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
