fork, trivial confinement, constructor

[Bas Wijnen]

Hi,

I just had a discussion with someone on IRC about why fork is bad.  He asked
me for some text about it, so I looked in the Hurd wiki, but there wasn't
really anything appropriate.  So I wrote a new page comparing trivial
confinement and constructors, and comparing them to fork as well.

The last part of it however, is comparing trivial confinement to the
constructor.  As it says, this list has not reached consensus about it.  It's
probably a good idea if that happens, which is why I'm bringing it up.  The
part I wrote can be used as a starting point.  For the lazy readers, I'll
quote it here (if you don't understand from the context what the letters mean,
go read the whole thing):

            The difference between trivial confinement and the constructor is
            one of control. With trivial confinement, P is in full control of
            the process. For example, if P is a debugger, it could choose to
            put some breakpoints into C before starting it. With the
            constructor, this control lies with P1. However, P2 is likely the
            one who will want to use the debugger. The constructor is
            explicitly designed to allow this type of control by the
            programmer (or system administrator) over the user.

            In the Hurd we want to enable the user to do these sort of things.
            We specifically don't want the administrator to use such control.
            So we do not need to provide the means for it in our system. (Note
            that not using a constructor doesn't actually guarantee that this
            kind of control is impossible.)

            Except for the control, there is really only one other difference,
            and that's address space separation. The constructor puts the code
            for process spawning into its own address space. This means that
            it cannot be corrupted by broken programs. Extending this
            principle would mean that every library call should be turned into
            a server which performs the operation for you. This is however
            also what trivial confinement does to a large extent anyway.

            What it doesn't do is protect the code image against bugs in P. In
            the constructor the trusted and well-tested constructor code is
            handling the image, for trivial confinement the (very possibly)
            buggy program P. In particular, when starting a program from a
            file system, with trivial confinement the operation is:

              * Ask the file system for the code, receive a capability to a
                space bank with a copy (on write) of it.
              * Make the system call to turn it into a program.

            Now this isn't much more complicated than the constructor which
            does:

              * Ask the filesystem (which the constructor is part of) to spawn
                a new process.

            Therefore I am not so convinced that we want a constructor. It
            gets in the way of debugging, for example, and it doesn't really
            give any gain.

Reactions?

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature