Re: Part 2: System Structure

[Marcus Brinkmann]

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.

So, the answer should be asked in reverse: Why should the constructor
mechanism be preserved?  Looking for reasons which are _not_ related
to DRM like applications, I found only one argument so far: Because it
is a non-trivial architecture dependent code.  Well, that doesn't cut
it for me, because the same is true for many other operations,
including spin locks and string operations.  And most support code is
already in libc anyway for dynamic loading at runtime.

Although you have argued before that the constructor provides other
benefits beside allowing to implement DRM, based on my analysis I
concluded that its inclusion in a system design can only be justified
if DRM-like mechanisms should be supported.  Or, as you said, the
design without the constructor is "elegant", just as the design with
constructor is elegant, assuming you want to support DRM-like
mechanisms.  A design with constructor mechanism, but without making
use of its true potential is not elegant.

> The *only* concern that I have with this is a concern about
> "positioning". It needs to be very clear that Hurd-OS is not Coyotos-OS,
> because I have customers who are relying on these features in Coyotos-OS
> and I do not want them to become confused.
> 
> On the other hand, it seems to me that the reverse is also true. Since
> part of the purpose of the Hurd design is to establish a visible
> position on the DRM issue, it is important for Hurd to distinguish
> itself visibly from other operating systems (including Coyotos, but also
> Linux and others).
>
> So I do not see any great problem here.
> 
> Marcus: what are your reactions on this technical option, and also on
> the need to be clear that the systems are different?

I agree that distinctions must be clear, by the name and description
and otherwise.  I also think that it is a useful exercise for people
who are contributors here and are thinking about preserving the
discussed Coyotos-OS features in the Hurd to pose themselves the
question what they think the difference is or should be.

The only possible point of confusion I can see is that the Coyotos
microkernel and the Coyotos OS are not easily distinguished.  That's
not a big issue, it just needs to be taken into account.

Thanks,
Marcus