At Tue, 23 May 2006 12:13:17 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> So: eliminating DRM does not require eliminating constructors. A
> translucent space bank design is entirely sufficient. All of the rest of
> the properties that you are worried to avoid are a consequence of
> opacity. [It is possible that I have failed to consider something, but I
> am fairly confident about this statement technically.]
Although this is true, I always found the constructor quite an "in the
way of doing things" mechanism, unrelated to the DRM discussion. The
reason is that the process composition happens too early for my taste.
You believe firmly that the constructed program embodies the
programmer's will, and you rely on this for various security
arguments. This is why the constructor mechanism is designed around
the assumption that constructing the process is a separate operation
from running an instance of the process. So, in the constructor
model, first all things are done to prepare a process image, or at
least to allow the process to prepare its own image, then the
requestor of the constructor instantiates it.
However, I believe that there are many good and interesting
applications where the instantiation operation influences heavily the
process composition operation. For example, in Unix, shared libraries
are frequently replaced dynamically with LD_LIBRARY_PRELOAD or
LD_LIBRARY_PATH, not only in development, to achieve various goals.
Programs are run in specially prepared sessions, like ltrace, strace
(Unix), rpctrace (Hurd), fakeroot, to observe or control their
behaviour. In the end, I want to make all types of virtualization and
debugging very easy. The constructor sometimes makes them harder, by
putting a piece of infrastructure in the way of achieving these goals.
I learned from you that when you find you keep fixing a design, it
probably is the wrong design to begin with. There have been many
proposals to fix the space bank + constructor design to allow it to
support virtualization and debugging. I think I do understand how,
technically, I can recover my system design from the constructor
mechanism by a couple of extensions. However, if the constructor
stands in the way of all the things I want to do, it seems opportune
to ask why it should remain central to the design.