At Tue, 23 May 2006 12:13:17 -0400, "Jonathan S. Shapiro" <[EMAIL PROTECTED]> 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
