Design principles

[Pierre THIERRY]

With the recent discussions, and because, beyond the fruitful technical
discussions about use cases, I probably disagree with Marcus on some of
his critical goals for the HURD, I'd like to try to come up with an
alternative design.

Because I'm all but experienced in OS design, I'll do it carefully step
by step. If I don't feel able to complete any step, I'll probably stop
trying and go back reading about OS design and studying CS until either
I'm more confident about my abilities or I don't want to design an OS
anymore...


WARNING: this document is tentative. All correct statements are probably
those inspired by others and obvious contradictions my proud work...


As I'm pretty much seduced by the concept of principle driven design,
I'll start with design principles. I should note that from my point of
view, these principles should not be seen as some sort of absolute
predicates that could be used to irrefutably reject a design. They have
to be interpreted to be useful and interpretation will necessarily
differ from one person to another. They are probably more of a very
strict framework to make design decisions.

I've given them abbreviations to facilitate further discussion:

- Principle of least authority (POLA)
- Principle of least surprise (POLS)
- Extensibility and expressiveness (EE)
- Efficient use of resources (EUR)
- Keep It Simple, Stupid! (KISS)
- Fault Isolation (FI)


POLA
====

means that no subject in the system should have more authority than
needed to complete his task.

It induces the principles of explicit authority designation (or a
subject would have to get authority from a larger pool of authority than
strictly needed) and relinquishable authority (subjects with authority
no more needed and well-behaved should be able diminish their
authority).

Examples
--------

A program to create a copy of an existing image from a file in another
format should not be given the same permissions on the FS than the user
running it, but only a read-only capability to the source file and a
write-only capability to the target file.

Not any kind of check should ever be needed on scripts included in a
document: script execution should be made as a separate subject with
only a capability to a temporary copy of the document (or even only a
part, if application has enough metadata on the script).

POLS
====

means that a subject should be able to know the outcome of an operation
it has explicitly triggered.

EE
==

means that the design should include points where user can select the
service to implement an interface and also provide means of composition
to easily build services on top of the existing ones.

Examples
--------

Extensibility: the TCP/IP stack need not be a mandatory system
component, even if a default one is provided for convenience.

Expressiveness: the system should provide complete objects or stub code
to make it easy for the user to create capabilities to facets of objects
that do not explicitly provide facets.

KISS
====

means that the design should be kept easy to understand and implement.
It makes it less likely that bugs creep in the system, as it is easier
to verify specification and implementation.

EUR
===

means that requirements of the system should be kept as small as
possible, to keep resources available to user applications and enable
use in limited environents (e.g. great number of users, high workload or
embedded hardware).

FI
==

means that fault in a component should not propagate to other components
(though information about fault could propagate widely if useful).

FI induces the principle of least common mechanism.

Examples
--------

Many subjects using network should be able to instanciate their own
TCP/IP stack, so that even a corruption at the process level would only
alter network connectivity of one subject. Such division could be made
the default policy between users.


---


Relationships between principes

These principles are neither independant nor of identical importance.

Relative importance can be classified as:
- A dominates B: obeying A is a valid reason to disobey B, and obeying B
  is not a valid reason to disobey A,
- A is balanced with B: only the context and tradeoffs can tell if A or
  B should be obeyed if both can't,
- A is imbalanced with B: in the general case, A dominates B, but in
  some limited cases, they are balanced.

POLA dominates all principles: POLA is a fundamental basis for security,
and a insecure system is quickly made unusable by it's threats.
Moreover, adhering to many of the other principles is made dramatically
easier when adhering to POLA.

FI dominates EE: extensibility should not be made by coupling existing
services to their extensions so tightly that they become vulnerable to
their errors.

EE is imbalanced with KISS: extensible and higly expressive systems are
necessarily complex systems, but complexity should remain in reasonable
limits.

KISS is balanced with EUR: optimization are only sometimes simpler
designs, and a compromise between simplicity and optimization has to be
found. Beware that premature optimization is the root of all evil.

FI is imbalanced with EUR: only in rare cases should optimization lead
to vulnerability to fault propagation (notably in cases where lack of
optimization would really impedes system usability).

POLS seems not really related to any principle, in that it is probably
as important as POLA is, but adherence to no other principle should make
adherence to POLS more difficult.


---


Where design principles are more or less criteria to reject designs,
their positive counterpart are probably design goals. I'll state them
pretty quickly:

- User freedom: user on the system should not be rsetrained to do
  antyhing that the system could be brought to do. This only fully
  applies to the machine owner, and to other users only within the
  limits of system policies as set by the machine owner.
- Security: no external agent should be able to gain authority within
  the system forcibly, and no subject in the system without proper
  authority should be able to undermine any other subject's use of it's
  own resources.
- Correctness: system should be designed with the most care to eradicate
  bugs and be resilient to errors. As an obvious requirement, the system
  should have a definite specification. As an obvious ideal, the system
  should be proved to implement a formal specification.


It is probably worth noting that a point where I feel to strongly
disagree with Marcus is that I think the system should not undermine
people's ability to implement usage patterns we consider baneful to
society in it's whole, like proprietary software or DRM. I personnaly
came to that for psychological and theological reasons, but it is really
a matter of convinction, not of facts.


---

Any comments, especially criticism, would be highly appreciated.

Tentatively,
Pierre
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature