How to reconcile constructor and virtualization

[Pierre THIERRY]

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
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature