"Towards a New Strategy of OS Design" revisited

[Marcus Brinkmann]

Hi,

This is an experiment: to revisit our founding father's position
paper, "Towards a New Strategy of OS Design" by Thomas Bushnell, and
see what has become of it.  Let's see if it is in conflict with some
of the things that have been contemplated here this month, or if it
supports some of these ideas.

You can find the whole text at
http://www.gnu.org/software/hurd/hurd-paper.html

I will not do an extensive review.  Also, I will limit myself to Part
1: A More Usable Approach to OS Design.  My goal is here to find out
the original motivation behind the Hurd design.

The beginning of the paper just reiterates how monolithical kernel
designs are bad, and how even multi-server systems fail to bring the
user the flexibility to extend the system.  One specific idea he names
is the ability by unprivileged users to extend the VFS, iow: Provide
open/read/write interfaces for arbitrary objects.

After this review of existing designs, he comes up with the following
statements.  I consider this to be the core of his paper.

+----------------------------------------------------------------------+
|  The GNU Hurd, by contrast, is designed to make the area of system   |
|  code as limited as possible.  Programs are required to communicate  |
|  only with a few essential parts of the kernel; the rest of the      |
|  system is replaceable dynamically.  Users can use whatever parts of |
|  the remainder of the system they want, and                          |
+----------------------------------------------------------------------+

+----------------------------------------------------------------------+
|  [Users] can easily add components                                   |
|  themselves for other users to take advantage of. No mutual trust    |
|  need exist in advance for users to use each other's services, nor   |
|  does the system become vulnerable by trusting the services of       |
|  arbitrary users.                                                    |
+----------------------------------------------------------------------+

These are the original two core objectives.  System code should be as
limited as possible; users should be able to replace it dynamically
with their own implementation.  And users should be able to share some
of their resources or services without requiring mutual trust.

This is what should be _different_ between the Hurd and all the other
systems at that time.  Note that this has nothing to do with POSIX.
POSIX only enters the picture in Part 2, where Thomas looks at _some_
of the Hurd's beasts, and where he explains how we can make it "Look
Like Unix".

In a very narrow sense, these objectives have been achieved.  Note
that to make this statement right we have to cut the Hurd a lot of
slack here.  First, we have to understand what Thomas meant by mutual
trust between two users.  What he meant is that a user with user ID
"id1" can prove to a server running under user ID "id2" that it has a
capability for user ID "id1", without actually copying this capability
into the untrusted server task.  Ie, authentication is possible even
between untrusting tasks.  Second, we have to ignore the last part of
the above paragraph, because it doesn't make any sense.  In the Hurd,
the system does not trust the services of arbitrary users.  Third, we
have to ignore a lot of details in the implementation of the Hurd that
actually make it vulnerable to all sorts of attacks.  I am very
liberal here and include even vulnerabilities that can be considered
design flaws, under the assumption that all of these can be fixed by
doing only local changes to the overall design.  I am also excluding a
whole range of attacks that can not be fixed without structural
changes in the microkernel and the operating system (like, the
apparent lack of proper resource control in Mach).

So, let's say all of these objectives have been achieved, or can be
achieved, as intended.  Are we happy then?  Maybe you are.  But let me
suggest some additional goals that Thomas left out.  We could ask him
why (he is still around), but we can also just ignore that question
and jump to the question: Do these additional goals make sense and do
they fit well into the set of original goals stated above.

Additional goals for the Hurd:

* Resource accountability and control.

  This goal actually implements one of the fundamental requirements of
  an operating system, that users can share the hardware without
  harming each other.  As such, it seems to be rather a requirement
  than a goal.

* Provide a native OS that really supports fine-grained selection of
  servers to use.  The POSIX personality is not really suited for this
  goal.  It's quite astonishing how well the Hurd has separated POSIX
  into components, but it's a matter of fact that this separation is
  not very well leveraged in practice.  Basically, just about all Hurd
  processes have capabilities to all servers (or can get them).

  This would realize the first design goal as stated by Thomas, in a
  _meaningful_ way.  The isolated components should be individually
  usable, not just in theory, but in actual programming practice.  The
  principle of least authority should actually be followed strictly.

  In short, it's not enough if a system "allows" an operation.  It
  must support it well enough to make it actually feasible.

  It is here where persistence comes into play, because the state of
  such a highly dynamic server configuration should be preserved
  across system shutdowns.

* Allow users to run arbitrary code without prior trust.

  In terms of mechanism: Add confinement and constructors.  If done
  properly, this goal _fully_ realizes the suggestion:

  "No mutual trust need exist in advance for users to use each other's
  services."

  This goal is achieved in the Hurd currently only with a lot of
  qualifiers, and a very narrow understanding of the term "mutual
  trust".  With constructors and confinement, however, this goal is
  fully realized.  A user can run _any_ untrusted code in a safe
  environment.

I said that these can be "additional goals" for the Hurd, but really,
I think they are just an update on the original goals as stated.

To conclude: I think that what has been discussed is not only in
agreement with Thomas' list of _defining_ goals, it is one possible
logical conclusion of them, by merely expanding the applicability (and
thus usefulness) of his ideas.

Thanks,
Marcus