Move the NextHurd files to where they belong.

28 files changed, 849 insertions, 0 deletions

diff --git a/NextHurd/CancellationForwarding.mdwn b/NextHurd/CancellationForwarding.mdwn
new file mode 100644
index 00000000..1b7776f2
--- /dev/null
+++ b/NextHurd/CancellationForwarding.mdwn
@@ -0,0 +1,56 @@
+# <a name="Cancellation_forwarding"> Cancellation forwarding </a>
+
+## <a name="Rationale"> Rationale </a>
+
+When a request to one or more servers is needed from a server to process a request from it's client, and the client cancels it's request, there will be at least temporary resource leakage in the chain of servers.
+
+If the last server in the chain completes processing and gives a response to it's client, there will be unnecessary CPU and memory usage from all the servers. And if one of the servers never completes, there will be permanent memory leakage.
+
+Timeouts are a way to avoid the permament memory leakage, at the cost of rendering the whole communication impossible above some system load. They also only bring the duration of the memory leakage from infinite to some time.
+
+Cancellation forwarding is a mechanism that can be used to propagate, without additional overt communication, the information that initial request has been cancelled.
+
+## <a name="Protocol"> Protocol </a>
+
+* Each client that want to forward cancellation to it's server increment the protected payload of the FCRB for which a sender's capability has been given to the server, thus invalidating the capability.
+* Each server that wants to notice cancellation forwarding will set up a watchdog, and ask the kernel to send heartbeats. At each heartbeat, the watchdog check that the reply capability to the FCRB of the client is not invalid, with a Discrim capability.
+
+## <a name="Example"> Example </a>
+
+Communication is described between 3 processes, client C and servers S and T.
+
+Notation:
+
+* FCRB-&gt;A means a FCRB whose receiver process is A
+
+### <a name="Successful_operation_"> Successful operation: </a>
+
+* C invokes a capability to S, giving S a capability c1 to a FCRB-&gt;C
+* S sets up a watchdog that check that discrim.classify(c1) != clVoid
+* S invokes a cap to T, giving T a cap c2 to a FCRB-&gt;S
+* T sets up a watchdog that check that discrim.classify(c2) != clVoid
+
+( T successfully treat the request, now goes completion )
+
+* T invokes c2
+* S reads the answer, and increment the PP of the FCRB-&gt;S
+* S invokes c1
+* C reads the answer, and increment the PP of the FCRB-&gt;C
+
+### <a name="Uncomplete_operation_"> Uncomplete operation: </a>
+
+* C invokes a cap to S, giving S a cap c1 to a FCRB-&gt;C
+* S sets up a watchdog that check that discrim.classify(c1) != clVoid
+* S invokes a cap to T, giving T a cap c2 to a FCRB-&gt;S
+* T sets up a watchdog that check that discrim.classify(c2) != clVoid
+
+( for any reason, C decides to stop, now goes cancellation )
+
+* C increments the PP of the FCRB-&gt;C
+* S watchdog notifies S of cancellation
+* S increments the PP of the FCRB-&gt;S
+* T watchdog notifies T of cancellation
+
+----
+
+-- [[Main/NowhereMan]] - 28 Apr 2006
diff --git a/NextHurd/ChoiceOfMicrokernel.mdwn b/NextHurd/ChoiceOfMicrokernel.mdwn
new file mode 100644
index 00000000..20ee6f05
--- /dev/null
+++ b/NextHurd/ChoiceOfMicrokernel.mdwn
@@ -0,0 +1,4 @@
+TBD
+
+* [[MicrokernelL4]]
+* [[MicrokernelCoyotos]]
diff --git a/NextHurd/CopyVsRevocableCopyVsMap.mdwn b/NextHurd/CopyVsRevocableCopyVsMap.mdwn
new file mode 100644
index 00000000..9c99c0a1
--- /dev/null
+++ b/NextHurd/CopyVsRevocableCopyVsMap.mdwn
@@ -0,0 +1,6 @@
+TBD, see:
+
+* <http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00274.html>
+* <http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00023.html>
+
+-- [[Main/TomBachmann]] - 20 Jun 2006
diff --git a/NextHurd/DesignGoals.mdwn b/NextHurd/DesignGoals.mdwn
new file mode 100644
index 00000000..5dbd7018
--- /dev/null
+++ b/NextHurd/DesignGoals.mdwn
@@ -0,0 +1,53 @@
+# <a name="Design_Goals"> Design Goals </a>
+
+## <a name="The_Position_Paper"> The Position Paper </a>
+
+_Improving Usability via Access Decomposition and Policy Refinement_ tries to capture technical objectives. As has been stated by Neal in [2], these are a number of scenarios we are interested in addressing:
+
+* security: programs are not users; they should be constrained according to the user's intents
+* resource management
+  * efficiency: facilitate use of local knowledge
+  * soft real-time: expose virtualized resources with useful access case characteristics
+* integration: safe extension of the system
+
+## <a name="The_original_list"> The original list </a>
+
+These goals have been initially proposed by Bas Wijnen [1]. The list here is a slightly modified form, I tried to incorporate the content of the mailing list discussion. It has to be noted that there is no consensus about this list. There have been objections about both the number of goals stated and specific goals themselves.
+
+## <a name="Essential_Goals"> Essential Goals </a>
+
+* stability
+* robustness
+* resource accountability
+* confinement
+* support for most legacy applications
+* extensibility
+* no ACLs
+
+### <a name="On_Extensibility"> On Extensibility </a>
+
+Extensibility has often been a strong argument to support the multiserver approach. Therefore, I think, it has been rated to be an essential goal in our (preliminary) list, too. However, it has been [suggested](http://citeseer.ist.psu.edu/druschel97extensible.html) that this argument is of few or no interest for a general purpose OSes: it is argued that the benefits of extensible kernels can be migrated to conventional ones by defining exactly what the extension requires. "Conventional kernel" is here probably to be interpreted as "monolithic kernel". From the above, I think the first (naive) conclusion that could be drawn would be to abandon the multiserver approach and extensibility goal.
+
+However, I do believe there are benefits in multiserver environments you cannot get in a monolithic one, namely enhanced security and stability through protection boundaries. Also, whilst wanting to become adopted as general purpose OS, ngHurd still strives to allow for research also, so even according to the above-referenced paper extensibility is to be one of its goals.
+
+Therefore, I'd want to propose to weaken the impact of extensibility on the design, by lowering it to the category "Regular Goals". -- [[Main/TomBachmann]] - 13 Dec 2006
+
+## <a name="Regular_Goals"> Regular Goals </a>
+
+* confinement with endogenous verification
+* soft real time
+* setting diverse resource distribution policies
+* persistent sessions for users
+
+## <a name="Optional_Goals"> Optional Goals </a>
+
+* small memory footprint
+* support for all POSIX applications
+* persistence
+
+----
+
+* [1] <http://lists.gnu.org/archive/html/l4-hurd/2005-11/msg00037.html>
+* [2] <http://lists.gnu.org/archive/html/l4-hurd/2007-01/msg00122.html>
+
+-- [[Main/TomBachmann]] - 29 Apr 2006
diff --git a/NextHurd/DesignPrinciples.mdwn b/NextHurd/DesignPrinciples.mdwn
new file mode 100644
index 00000000..42faa52f
--- /dev/null
+++ b/NextHurd/DesignPrinciples.mdwn
@@ -0,0 +1,39 @@
+# <a name="Design_Principles"> Design Principles </a>
+
+A design principle is a test that lets us **reject** things. Hopefully, when combined with other design principles, it forms a basis for making coherent and consistent decisions about design goals and system features. [1]
+
+## <a name="Stated_design_principles"> Stated design principles </a>
+
+None defined yet, but there seems to be consensus that ngHurd should be a principle-driven design.
+
+## <a name="Potential_design_principles"> Potential design principles </a>
+
+Here is an incomplete list of potential design principles for the ngHurd. It is taken from [2]. I left out some principles I think do not apply or are not in question. Feel free to add more.
+
+### <a name="Principles_from_the_Multics_Proj"> Principles from the Multics Project </a>
+
+* _Economy of mechanism_: Keep the design as simple as possible.
+* _Fail-safe defaults_: Base access decisions on permission rather than exclusion.
+* _Least priviledge_: Components should have no more authority than they require.
+* _Least common mechanism_: Minimize the amount of shared instances in the system.
+
+### <a name="Commonly_accepted_principles"> Commonly accepted principles </a>
+
+* _Separation of policy and mechanism_
+* _Least astonishment (also known as principle of least surprise):_ The system�s behavior should match what is naively expected.
+* _Complete accountability_: All real resources held by an application must come from some accounted pool.
+* _Safe restart_: On restart, the system must either already have, or be able to rapidly establish, a consistent and secure execution state.
+* _Reproducibility_: Correct operations should produce identical results regardless of workload.
+
+### <a name="Principles_specific_to_EROS"> </a> Principles specific to EROS
+
+* _Credible policy_: If a security policy cannot be implemented by correct application of the system�s protection mechanisms, do not claim to enforce it.
+* _Explicit authority designation_: Every operation that uses authority should explicitely designate the source of the authority it is using.
+* _Relinquishable authority_: If an application holds some authority, it should be able to voluntarily reduce this authority.
+
+----
+
+See also:
+
+* [1] <http://lists.gnu.org/archive/html/l4-hurd/2005-11/msg00120.html>
+* [2] EROS: A Principle-Driven Operating System from the Ground Up
diff --git a/NextHurd/FirstClassReceiveBuffer.mdwn b/NextHurd/FirstClassReceiveBuffer.mdwn
new file mode 100644
index 00000000..c3cc3142
--- /dev/null
+++ b/NextHurd/FirstClassReceiveBuffer.mdwn
@@ -0,0 +1,3 @@
+TBD, see e.g. <http://coyotos.org/docs/ukernel/spec.html> and <http://www.coyotos.org/pipermail/coyotos-dev/2006-January/000391.html>
+
+-- [[Main/TomBachmann]] - 31 Aug 2006
diff --git a/NextHurd/HowMuchConfinementDoWeWant.mdwn b/NextHurd/HowMuchConfinementDoWeWant.mdwn
new file mode 100644
index 00000000..663e5bbb
--- /dev/null
+++ b/NextHurd/HowMuchConfinementDoWeWant.mdwn
@@ -0,0 +1,93 @@
+# <a name="How_Much_Confinement_Do_We_Want_"> How Much Confinement Do We Want? </a>
+
+**_NOTE:_** **I am absolutely sure this is incredibely incomplete and/or wrong.** **_This is not up to date!_**
+
+## <a name="Introduction"> Introduction </a>
+
+There has been a lot of traffic on the l4-hurd list lately. A good bit of this is related to the question this entry is about: How much confinement do we want? The idea not to implement the full confinement was (accidently?) raised by marcus, who planned to raise it _somewhen_, but not yet.
+
+## <a name="Terminology"> Terminology </a>
+
+In this section I try to sketch some terminology that came up _during_ the discussion.
+
+### <a name="Creator"> Creator </a>
+
+Creator we call the creator of the confined (constructor) object.[2]
+
+### <a name="Instantiator"> Instantiator </a>
+
+Instantiator we call the user of the confined (constructor) object. [2]
+
+### <a name="Encapsulation"> Encapsulation </a>
+
+Encapsulation means that information (including authority) cannot be extracted from a program without its consent. This is a restriction on "read in" behavior. [3]
+
+### <a name="Confinement"> Confinement </a>
+
+Confinement means that a program cannot communicate outward through unauthorized channels. This is a restriction on "write out" behavior. [3]
+
+### <a name="non_trivial_confinement"> non-trivial confinement </a>
+
+Marcus: \`\`[non-trivial confinement] is the confined constructor design pattern.'' [1]
+
+We speak about non-trivial confinement when creator != instantiator. [2]
+
+### <a name="trivial_confinement"> trivial confinement </a>
+
+Marcus: \`\`[trivial confinement] is what the Hurd will do'' [1]
+
+We speak about trivial confinement when creator == instantiator [2]
+
+### <a name="principle_of_user_freedom_autono"> principle of user freedom/autonomity </a>
+
+The principle of user freedom and autonomity means the right to use, inspect, alter and copy all resources attributed to/owned by the user.[4]
+
+### <a name="freedom_of_digital_information"> freedom of digital information </a>
+
+TBD
+
+## <a name="The_Positions"> The Positions </a>
+
+Here I try to sketch the different positions.
+
+### <a name="Use_and_Implement_Only_Trivial_C"> Use and Implement Only Trivial Confinement by Default </a>
+
+#### <a name="Pros"> Pros </a>
+
+* Follows the principle of user freedom
+* **add more here**
+
+#### <a name="Cons"> Cons </a>
+
+* Possibly use cases for non-trivial confinement exist we cannot yet think of.
+* **add more here**
+
+### <a name="Implement_Full_Confinement_and_U"> Implement Full Confinement and Utilize It </a>
+
+#### <a name="Pros"> Pros </a>
+
+* There are many years of experience with confinement.
+* **add more here**
+
+#### <a name="Cons"> Cons </a>
+
+* It does not follow the principle of user freedom.
+* **add more here**
+
+## <a name="Preliminary_Summary_Statements"> Preliminary Summary Statements </a>
+
+* [Jonathan](http://lists.gnu.org/archive/html/l4-hurd/2006-05/msg00018.html)
+
+## <a name="A_Try_to_Push_the_Discussion_int"> A Try to Push the Discussion into a Constructive Direction </a>
+
+Marcus started a challenge [5] to find a use case for non-trivial confinement that is interesting for the Hurd and cannot be implemented otherwise. The exact challenge definition can be found in the mail.
+
+----
+
+* [1] <http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00339.html>
+* [2] <http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00383.html>
+* [3] <http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00415.html>
+* [4] <http://lists.gnu.org/archive/html/l4-hurd/2006-05/msg00012.html>
+* [5] <http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00407.html>
+
+-- [[Main/TomBachmann]] - 01 May 2006
diff --git a/NextHurd/HurdishApplicationsForPersistence.mdwn b/NextHurd/HurdishApplicationsForPersistence.mdwn
new file mode 100644
index 00000000..12861ecb
--- /dev/null
+++ b/NextHurd/HurdishApplicationsForPersistence.mdwn
@@ -0,0 +1,5 @@
+TBD, see:
+
+* <http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00081.html>; summary: passive translators started by the filesystem cannot be done right and persistence makes passive translators unnecessary
+
+-- [[Main/TomBachmann]] - 20 Jun 2006
diff --git a/NextHurd/MicrokernelCoyotos.mdwn b/NextHurd/MicrokernelCoyotos.mdwn
new file mode 100644
index 00000000..40fd6e9d
--- /dev/null
+++ b/NextHurd/MicrokernelCoyotos.mdwn
@@ -0,0 +1,9 @@
+# <a name="The_Coyotos_microkernel"> The Coyotos microkernel </a>
+
+[Coyotos](http://www.coyotos.org/index.html) is a microkernel and OS and the successor of EROS, that itself is the successor of KeyKOS. A more complete history can be found [here](http://www.coyotos.org/history.html). It's main objectives are to correcte some shortcomings of EROS, demonstrate that an atomic kernel design scales well and to completely formally verify both the kernel and critical system components by writing them in a new language called bitc.
+
+Coyotos is an orthogonally persistent pure capability system. It uses continuation based unbuffered asynchronous IPC (actually it's synchronous IPC whith asynchronous syscalls).
+
+TODO: explain these terms and (more important) their consequences on system design.
+
+The coyotos microkernel specification can be found [here](http://www.coyotos.org/docs/ukernel/spec.html)
diff --git a/NextHurd/Part1OwnershipAndContracts.mdwn b/NextHurd/Part1OwnershipAndContracts.mdwn
new file mode 100644
index 00000000..a5260bc6
--- /dev/null
+++ b/NextHurd/Part1OwnershipAndContracts.mdwn
@@ -0,0 +1,163 @@
+# <a name="Part_1_Ownership_And_Contracts"> Part 1: Ownership And Contracts </a>
+
+This is the first in a series of notes that will serve to formulate my position from ground-up. The way will not be straight-forward. I can not give you one particular, technical argument that addresses all my concerns. Instead, the evaluation involves a step of personal judgement (but only one). In this note, I will explain why I believe that this is necessarily the case, what this step is and what my stance on it is.
+
+This mail took me 5 hours to write, which means 1.5 lines per minute. It contains only a tiny part of my argument. I hope that this removes any doubts about my sincerity to address all issues, but also makes apparent the technical constraints in doing so "immediately", as has been requested from me several times. I have to ask for patience. As everybody else, I am doing this in my spare time.
+
+Let me jump right in at the technical level: I claim that every relationship between two processes falls into one of four categories. These four coarse categories provide a differentiation that is sufficient for my argument:
+
+## <a name="Process_Relationship_Categories"> Process Relationship Categories </a>
+
+0. It is not possible for the processes to communicate via direct IPC.
+
+In all other categories, it is possible for the processes to communicate via direct IPC, because one of the processes, let me call it process A, has a capability to the other process, let me call it B.
+
+1. The collective authority of process B, immediately[1] after the time it was instantiated, is necessarily a strict subset of the collective authority hold by process A at that time.
+
+[1] See my challenge-email to find a definition of the window of time that gives meaning to the word "immediately" in the case where process B is instantiated indirectly or directly because of an action in process A. If process B is instantiated independent of process A, just assume that the collective authority hold by process A is the empty set.
+
+2. The set of collective authority of process B, immediately after the time it was instantiated, minus the collective authority of process A (if it existed), is necessarily not empty. Some of the capabilities in this non-empty set provide the ability to write-out.
+
+3. The set of collective authority of process B, immediately after the time it was instantiated, minus the collective authority of process A (if it existed), is necessarily not empty. None of the capabilities in this non-empty set provide the ability to write-out.
+
+This categorization does not say anything about encapsulation. However, it is to be understood from the description that in category 0, 2 and 3, process B is encapsulated. If it were not, the collective authority that is hold by A would include the authority of B by transition. In category 1, it is to be understood that process B, in principle, can not be successfully encapsulated (to see this, pay attention to the fact that process A could pre-arrange its authority so that no capability it has provides the possibility for encapsulation).
+
+This categories provide a complete categorization for two important system structures: The EROS/Coyotos model, which relies on categories 0, 2 and 3, while making category 1 possible. And my recursive system structure model, which relies on categories 0, 1, and 2, but rejects 3.
+
+## <a name="Agenda"> Agenda </a>
+
+This provides the basis for a goal-based analysis. The agenda can be:
+
+1) It has to be demonstrated that the goals of the Hurd can be met by relying on the process relationships described by 0, 1 and 2. This of course must include an analysis of the goals of the Hurd.
+
+2) It is useful to reason about the rejection of category 3. What do we lose by omitting it? What goals can not be achieved by the Hurd if it rejects category 3?
+
+This sets the background. I will start with the second item on the list, and then work my way up. It would not be unreasonable to do it the other way around: I could state the goals of the Hurd, then demonstrate that we can achieve them by using the model I described earlier, and then look at the interaction with category 3 relationships. This would be the straighter way. However, a discussion of the goals of the Hurd can be easier followed if the background is set. So, let me finish this note with some general arguments about the properties of category 3, and what the factors can be that determine how you think about it.
+
+## <a name="Encapsulation_and_Confinement"> Encapsulation and Confinement </a>
+
+What is the exact nature of the relationship between process A and process B, where communication can (and does) occur, but process B is both encapsulated and confined? To discuss this, we have to define what we mean by the nature of process relationships. Two concepts come into my mind: Ownership and contracts. What do these words mean?
+
+In the course of the discussion, I will make use of citations from Hegel's Philosophy of Right. I am not relying on his argumentation, it is just a convenient source for some definitions, from which I want to work.
+
+## <a name="Ownership"> Ownership </a>
+
+Ownership is not a complicated concept. You can look it up in encyclopedias or dictionaries, or you can study philosophy. Hegel defines ownership this way (Paragraph 61):
+
+"Since the substance of the thing which is my property is, if we take the thing by itself, its externality, i.e. its non-substantiality --- in contrast with me it is not an end in itself (see � 42) and since in my use or employment of it this externality is realised, it follows that my full use or employment of a thing is the thing in its entirety, so that if I have the full use of the thing I am its owner. Over and above the entirety of its use, there is nothing left of the thing which could be the property of another."
+
+A shorter definition is that ownership is the exclusive right of a person to possess, use and dispose of a thing. Note that the right must be exclusive. It must also be complete. Also note that ownership refers to human beings, not things. Things can not own other things. Paragraph 42 in Hegel's work defines:
+
+"What is immediately different from free mind is that which, both for mind and in itself, is the external pure and simple, a thing, something not free, not personal, without rights."
+
+## <a name="Contracts"> Contracts </a>
+
+Hegel describes the transition from ownership to contracts in paragraph 71 this way:
+
+"One aspect of property is that it is an existent as an external thing, and in this respect property exists for other external things and is connected with their necessity and contingency. But it is also an existent as an embodiment of the will, and from this point of view the 'other' for which it exists can only be the will of another person. This relation of will to will is the true and proper ground in which freedom is existent. --- The sphere of contract is made up of this mediation whereby I hold property not merely by means of a thing and my subjective will, but by means of another person's will as well and so hold it in virtue of my participation in a common will."
+
+A contract is thus an agreement among agents to hold a property by means of a common will.
+
+## <a name="Mediating_Actors"> Mediating Actors </a>
+
+In the case of confinement and encapsulation, there are not just two agents engaging in a contract, there are three (at least). There must be three, because encapsulation and confinement means that neither the party that is encapsulated, nor the party that is confined comes to hold the other parties property. So, there must be a third agent which does hold both parties property, and which implements the common will of the participants.
+
+To find this agent, we just have to look for somebody who comes to hold the other parties property. In computer systems without "trusted computing" components, this is the owner of the machine (and/or the system administrator). In computer systems with "trusted computing" components, the mediating agent are the people or companies designing and building the "trusted computing" hardware.
+
+In either case, the mediating agent uses tools to implement the common will. In either case, the mediating agent has, not exclusive, but still quite complete ownership over the property that is part of the contract (possession, use and disposal). In either case, implementation of the common will depends on the well-behaviour of the mediating agent.
+
+## <a name="Contract_Requires_Consent"> Contract Requires Consent </a>
+
+If the mediating agent is supposed to implement the common will of the participants in a contract, it needs to know what the common will is. If a participant wants to engage in a contract, it needs to know what the contract means before the participant can make a proper judgement about participation.
+
+In the process of entering a contract, you are giving up, at least temporarily, possession of a thing you own. This is why entering a contract requires careful consideration and explicit consent.
+
+## <a name="Contracts_Are_Not_Private"> Contracts Are Not Private </a>
+
+I can not make the transition here from the rights of individuals to the structure and legitimation of civil societies. This is the subject matter of state philosophy. However, it suffices to say that the universal rights of individuals find (often, not always) expression in the laws of the civil society, and that it is civil society which is bestowed to resolve conflicts between the perceived particular rights of individuals.
+
+Because civil societies exist, and we live in them, and contracts are fundamental to the function of a society, every society has extensive and complex laws about how contracts are made, and what they can entail, and what their limitations are. The German Civil Code contains 2385 articles on 433 pages, and this is only one of the many laws that has something to say about the matter. There are other laws specific to contractual labor, anti-trust, publicly traded companies, publications, etc etc.
+
+## <a name="A_Matter_Of_Judgement"> A Matter Of Judgement </a>
+
+It is now appropriate to look again at the proposed system structures in their extremes (there are shades of gray, but they have not been seriously discussed so far).
+
+In my model, the computer remains the property of its owner. This property right is strongly protected. The system will not allow, by default, operations that let the owner unintentionally enter into a contract between two parties. Any such contract requires explicit consent. It also requires, every time that a contract is made, to explicitly choose the mediator and scope of the contract. In other words, the owner must be explicit about his particular will that should be part of the common will of the contract.
+
+In the EROS/Coyotos model employing "trusted computing", only part of the computer is the property of the owner. Another part of the computer is owned by the manufacturer of the "trusted computing" component. The system will, by design, perpetually give away possession of parts of the computer to other agents, by engaging constantly in contracts with them. The nature of these contracts is built firmly into the system structure: The mediator is always the agent that designed and implemented the "trusted computing" component. The default "common will" is to alienate all rights to the property, except the right to destroy it.
+
+These seem to me the only serious proposals. I recognize that my model makes it harder for people to engage into contracts when they want to. In my opinion, this is justified: Negotiating and implementing a contract is a fundamental process that can not be overly simplified. In fact, in any serious business, developing the contracts between collaborating agents is a very serious and essential part of the process. Business holders are acutely aware of the risks involved in engaging into a contract, and spent significant personnel and financial resources to limit their risks.
+
+There may be, in principle, a system that makes it convenient for users to engage in standard contracts selectively, explicitely and safely. For this, however, the mechanisms involved must allow for a broad range of expressions that reflects the structure of the existing society, and the user must be able to decide if the contract actually reflects the common will of the involved agents. This is far beyond what we can technically achieve, at least today, maybe forever.
+
+## <a name="On_The_Non_Technicality_Of_The_C"> On The Non-Technicality Of The Choice </a>
+
+Currently, we only know about the two possible extreme positions described above. There is an outstanding description of the properties of my model, and how they can be achieved. However, my claim is that the choice between these two options can not be made on technical grounds. Each system is self-consistent and provides an adequate solution to the task that it tries to solve.
+
+The choice therefore comes down to a personal preference, which may either be based on personal needs, or on a speculation on the future.
+
+However, let me raise some cautions that illustrate why I have made my choice the way I did. These cautions do not constitute an exhaustive list of my arguments. It is not necessary for me to give an exhaustive list. In the end, what system one would prefer to use is a personal decision that everybody has to make on their own grounds.
+
+## <a name="On_The_Effect_Of_Perpetual_Alien"> On The Effect Of Perpetual Alienation </a>
+
+Hegel remarks on the effect of perpetual alienation (my terminology) (paragraph 67):
+
+"Single products of my particular physical and mental skill and of my power to act I can alienate to someone else and I can give him the use of my abilities for a restricted period, because, on the strength of this restriction, my abilities acquire an external relation to the totality and universality of my being. By alienating the whole of my time, as crystallised in my work, and everything I produced, I would be making into another's property the substance of my being, my universal activity and actuality, my personality."
+
+He then continues to add a comparison to the nature of being a slave:
+
+"The distinction here explained is that between a slave and a modern domestic servant or day-labourer. The Athenian slave perhaps had an easier occupation and more intellectual work than is usually the case with our servants, but he was still a slave, because he bad alienated to his master the whole range of his activity."
+
+It is undisputed (I hope) that computers occupy more and more of our personal life. By doing so, they start to embody significant parts of our personality. We, as domain experts, are miles ahead of the general public in this regard, and it is our obligation to foresee such developments. By losing control over our computers, we risk losing the ability to act universally. This finds correspondence in the risk of losing general-purpose computers to [[TiVo]]-ized locked down embedded systems.
+
+## <a name="Passive_Defense_Is_Not_Sufficien"> Passive Defense Is Not Sufficient </a>
+
+The passive defense against this risk is not sufficient. You may hold the opinion that the "trusted computing" component is optional. The machine owner can switch it off, and ignore it. This is true, but it is true in the same way that people are free not to click on email attachments if they do not want to risk getting a virus. Security threats, and the risk of losing the substance of one's being is probably the biggest security threat of them all, requires active defense at all levels of the computer system.
+
+There have already been proposals for US law to require all computers to support "trusted computing", and to enforce its use when connecting to the internet. There are other methods of coercion as well. One method is to introduce a less harmful variant of control, and then change the conditions after it is widely established. Another method is the exploitation of a monopoly, or conspirations among large companies to ensure that there is no feasible alternative. Yet another method is to spread false information on how the technique will be used. All of these techniques and more have already been used, so these are not speculations, they are facts.
+
+Once you accept the loss of the substance of one's being as a security threat (I am not saying you need to accept that, but if you do, you will be able to follow my argument), all the same techniques and considerations apply to this security threat as to other security threats. And it is universally recognized (I hope) that passive defense is not sufficient in the context of active security threats.
+
+## <a name="Radical_Paradigm_Shifts"> Radical Paradigm Shifts </a>
+
+The "trusted computing" model embodies radical paradigm shifts in how some people think about ownership and contracts. Richard Stallman remarks (<http://www.gnu.org/philosophy/can-you-trust.html>):
+
+"A previous statement by the palladium developers stated the basic premise that whoever developed or collected information should have total control of how you use it. This would represent a revolutionary overturn of past ideas of ethics and of the legal system, and create an unprecedented system of control. The specific problems of these systems are no accident; they result from the basic goal. It is the goal we must reject."
+
+The idea that the agent who developed or collected information should be the sole arbitrator of how the information is used by other agents is in direct conflict with several social contracts on fair use, temporal boundaries on copyright protection, obligation to preserve information (for example audits, or evidence of a crime), and more.
+
+In short, the mediating agent (the implementors of the "trusted computing" component) is overreaching, in direct conflict to established laws. At the same time, for most people, organizations, businesses and in fact, quite a number of governments as well, the mediating agent will be unaccountable, because not only it will be represented by large companies that have assets at their disposal comparable to some of the smaller nations on the globe, but also, because the way the technology is implemented, it will be able to convincingly deny its own involvement (also, nominally, it is the only party which could have been involved in the matter at all).
+
+## <a name="On_The_Imbalance_Of_Defaults"> On The Imbalance Of Defaults </a>
+
+In the encapsulated, confined example, the confined party risks, by default, nothing, and the encapsulated party risks, by default, all the resources that is giving up temporarily, for the whole time of the contract, without any guarantee for a result.
+
+This is an imbalance of defaults from which a balanced, negotiated contract is difficult to achieve. I see no reason why it should be easier or harder to achieve a balanced, negotiated contract in either system. They start from two extremes, and the right solution is somewhere in the middle. However, my system does not contain a comparable mechanism which is imbalanced by default. Instead, every agent is in the same situation. Practically, I think that a balanced contract is more likely to be the result of equal starting conditions than from unequal starting positions.
+
+## <a name="Conservative_Choices"> Conservative Choices </a>
+
+In the above sense, my model is really ultra-conservative. The only assumption is that it is the owner of the computer who should be in control over it. This is in fact, a logical tautology. I do not make any further assumptions about what should be imposed.
+
+## <a name="The_Choice_Of_A_GNU_Generation"> </a> The Choice Of A GNU Generation
+
+If you read carefully the text by RMS on <http://www.gnu.org/philosophy/can-you-trust.html> you will find out that, although the text focusses on DRM, it really anticipates a much broader class of problems. The free software movement depends on the free software philosophy, it is its heart and soul. Even if you do not subscribe to the free software philosophy, you should be able to agree with the following statement:
+
+Every person on earth should be able to write useful computer programs and share them with their friends without fees.
+
+For this, several things are required: We must have access to hardware that obeys our command. If it doesn't, or even if it only makes it very hard, we can not write programs for it. We must have access to information about how to write useful programs. For this, we must learn, and one way to learn is to observe how the programs that our friends wrote work. Also, to write programs that are useful in the real world, we must be able to reverse-engineer other proprietary programs. We must be able to publish our own, original work unencumbered by legal problems like patents.
+
+All of these things must be easy, or otherwise our ability to do our work is in danger. In the context of this discussion, my model supports these operations easily. The "trusted computing" model puts them at such a high risk that it threatens the mere survival of free software.
+
+This is something that is very important to understand. It is highly unlikely that the GNU project would accept a technology that threatens its own survival. So, if you want to propose a use case for this technology for a GNU project, you have to demonstrate more than just that there are people who want to do this. You would have to demonstrate that the benefits compensate the risk. Because the risk is very serious and very great, the compensating benefit would have to be equally big. Because this is a GNU mailing list spawned off a GNU project with the intent to write an operating system for the GNU project, I think it is appropriate to point this out.
+
+This does not mean that I am not, personally, interested in hearing your ideas. Furthermore, and this is also important to understand, I do not believe anymore that there is a conflict between the free software philosophy and the goal of writing a secure and useful operating system. The possibility that there might be such a conflict has been a great concern of mine in the last half year. However, once I had resolved two important use cases (suid programs and cut&amp;paste), I was able to see what parts of the security infrastructure were actually important to me, and which parts I think are a separable concern. From there, it was not difficult to generalize to the above analysis of ownership and contracts.
+
+## <a name="Outlook"> Outlook </a>
+
+This then, is my motivation for closely examining how (1) my model can be technically described, and (2) what its properties are, and (3) what its justifying design principles are. This sets the agenda for upcoming mails, so let me insert a breaking point here.
+
+Thanks, Marcus
+
+----
+
+Note: this document has an [[Part1OwnershipAndContractsAddendum]].
diff --git a/NextHurd/Part1OwnershipAndContractsAddendum.mdwn b/NextHurd/Part1OwnershipAndContractsAddendum.mdwn
new file mode 100644
index 00000000..d64d9179
--- /dev/null
+++ b/NextHurd/Part1OwnershipAndContractsAddendum.mdwn
@@ -0,0 +1,31 @@
+this is an addendum to my first note. It provides one more concern about the "trusted computing" model, an important clarification of the nature of my objection, and a retraction on the need for a new design principle.
+
+## <a name="Monoculture_Of_Service"> Monoculture Of Service </a>
+
+In the "trusted computing" model, it is suggested that all contracts, by default, use the same mediating agent. This introduces a single point of failure into the system architecture. It also concentrates social and political power into the hands of the mediating agent, which can (and will) be abused.
+
+In my model, all contracts have to be established explicitely, and there is no default mechanism. This will naturally cause people to choose a variety of contracts. For example, many contracts do not require a mediating agent at all, but the common will can be implemented by either of the involved parties. Often, there already is a suitable, local mediating agent available.
+
+## <a name="Quantitative_Differences_Cause_Q"> Quantitative Differences Cause Qualitative Differences </a>
+
+My main objection is thus that the pervasive use of the confined+encapsulated design pattern in the system architecture leads to a new qualitative difference between the systems. Every single contract in isolation may appear innocent. Their sum creates emerging behaviour that I consider a threat.
+
+It is an open question to me if the individual contracts indeed are innocent. In every civil society, there are some contracts that are invalid, even if you sign on to them. Some rights are well-recognized as inalienable. If such an inalienable right is contained in the confined+encapsulated design pattern or not is a difficult question that requires a much more careful analysis than I have attempted so far.
+
+However, even if every such individual contract is innocent, my objection still stands, because it is grounded not in the nature of the individual contract, but in the cummulative effect if it is used pervasively in the system architecture.
+
+In fact, it is not hard to see that if we take an individual contract of the confined+encapsulated sort, it can be straightforwardly implemented in my model with only one requirement beyond what I have already planned for: The user would need to be able to create a space bank that provides encapsulation. (Some more features are required to make it possible to create such services automatically without human inspection, but that is a minor point). However, the presence of this feature is a local property of the system architecture, not a global property.
+
+It is thus difficult for me to understand why it has been argued that not using this form of contract in the system architecture constitutes a de-facto ban of the ability to engage in such a contract. Quite the opposite, I think that engaging in such a contract is very well possible with only local, non-intrusive changes to the operating system to support some very specific functions. Maybe (I have not analyzed this) it does not make sense to engage in only one such contract with limited scope, maybe the very nature of the contract requires its pervasive use in the system architecture. If this is true (again, I do not know if this is true or not), this could be a first indication that this particular form of contract is not as innocent as it appears.
+
+## <a name="A_New_Design_Principle_"> A New Design Principle? </a>
+
+I have suggested before that I have formed a new design principle that provides a taxometer for the use of the confined+encapsulated design pattern. However, after having written my note I do not think that a new design principle is necessary.
+
+The only decision that has to be made is if the risk of losing the "substance of ones being", as it applies to the realm of one's computers, is a security threat or not. The rest follows quite logically from standard principles on how to design secure operating systems.
+
+The substance of my argument can thus be summarized in four simple words:
+
+**Ownership must be secured**.
+
+Thanks, Marcus
diff --git a/NextHurd/Part2SystemStructure.mdwn b/NextHurd/Part2SystemStructure.mdwn
new file mode 100644
index 00000000..4ce8026f
--- /dev/null
+++ b/NextHurd/Part2SystemStructure.mdwn
@@ -0,0 +1,111 @@
+This is part 2 in a small series of notes explaining my opinion on what is a good system structure for the Hurd. While the ideas in part 1 motivate the system structure presented here, the feasibility of this system structure in turn justifies my opinion as presented in part 1. However, either part can also be taken individually. There will probably not be a third part.
+
+# <a name="Part_2_System_Structure"> Part 2: System Structure </a>
+
+I will start with presenting the process hierarchy, explain some abstract design patterns, and then show some specific applications.
+
+Note that within this document, I will limit myself to certain types of operations and features. This does not mean that the system itself, by design, contains any measures to forbid or ban other types of operations.
+
+## <a name="Process_Hierachy"> Process Hierachy </a>
+
+A process is a protection domain. The initial configuration of the machine contains one or more processes with specific, but unspecified, relationships. These processes are called the "root processes". From the initial configuration, processes can be created and destroyed.
+
+## <a name="Resource_Management"> Resource Management </a>
+
+I do not make a disctinction between data and capability pages. Both are, for the course of this discussion, memory pages.
+
+Processes require at the very least some memory resources to keep the process state. Memory is allocated from containers, which therefore provide an abstraction for memory reserves. It is required that one of the root processes is a server implementing container objects.
+
+A container provides an interface that allows to allocate and return memory frames, and to create new containers with a new reserve limit (thus, containers form a hierarchy). Any successful allocation and deallocation from such a derived container will also be accounted for in all containers from which it is derived. A container can be destroyed, which will return all memory frames allocated from it, and thus recursively destroy all containers derived from it as well.
+
+## <a name="Process_Creation_And_Destruction"> Process Creation And Destruction </a>
+
+Any process which has access to a container from which a sufficient amount of memory can be allocated, can convert this memory into a process. The process is destroyed by deallocating the memory from which it was created.
+
+## <a name="Filling_In_the_Gaps"> Filling In the Gaps </a>
+
+The above description is actually mostly complete. What is missing is the description of a somewhat unrelated feature which allows process identification, a description of what the default mechanisms are in the system to support common design patterns, and an illustration that these design patterns are sufficient.
+
+## <a name="Canonical_Invariances"> Canonical Invariances </a>
+
+By default, every process is associated with one memory container, the primary container of the process. This is the container from which the process is allocated, and from which the process does all allocations for its own needs. Primary containers are by default not shared.
+
+## <a name="Canonical_Process_Creation"> Canonical Process Creation </a>
+
+To create a new process, by default, a process, the parent, creates a new container from its primary container, allocates some memory from it and converts it into a new process, the child. It then prepares the process to get it into a runnable state. This includes the following steps: First, a special executable image (allocated from the primary container of the child) is installed into the child's address space, which runs a cooperative protocol with the parent. Then, the parent provides the primary container of the child, and any other initial state that the child should receive, to the startup code. The startup code finally installs this initial state and starts to execute it.
+
+It is clear from this description that the child's existance is completely determined by the parent.
+
+## <a name="Canonical_Process_Destruction"> Canonical Process Destruction </a>
+
+Process destruction can be done either cooperatively, or forcibly. The difference corresponds approximately to the difference between SIGTERM and SIGKILL in Unix. To destroy a process cooperatively, a request message is sent to a special capability implemented by the child process. The child can then begin to tear down the program, and at some time send a request back to the parent process to ask for forced process destruction.
+
+Forced process destruction can be done by the parent process without any cooperation by the child process. The parent process simply destroys the primary container of the child (this means that the parent process should retain the primary container capability).
+
+Because container destruction works recursively, forced process destruction works recursively as well.
+
+## <a name="Process_Hierarchy"> Process Hierarchy </a>
+
+From the above description it should be clear that containers and processes are organized in the same hierarchical tree structure, where every node corresponds to a process and its primary container, and every edge corresponds to a parent-child relationship.
+
+## <a name="Isolation"> Isolation </a>
+
+The ability to subdivide the container's resource reserves provides the ability to completely isolate sibling processes in the process hierarchy. By default, two processes, where neither is an ancestor of the other process, are completely isolated. Also, an ancestor is partially isolated from its child. To overcome this isolation, the two processes need the cooperation of at least all their respective ancestors up to the first common ancestor in the tree. An example should illustrate that:
+
+                    A
+                   / \
+                  B   C
+                     / \
+                    D   E
+
+In this picture, A is the direct parent of B and C, and C is the direct parent of D and E. A is a common ancestor of B, C, D and E. C is a comon ancestor of D and E. The isolation is by default complete between (B C), (B D), (B E), and (D E). There is partial isolation between (A B), (A C), (A D), (A E), (C D) and (C E). The isolation properties of A are, if it is a root node, defined by the initial configuration.
+
+If, for example, B and D should be able to communicate, the explicit or implicit permission needs to be provided by both A and C.
+
+## <a name="Confinement"> Confinement </a>
+
+Because of the recursive nature of the process hierarchy, and because the existance of a child is completely determined by its direct parent (which existance is completely determined by _its_ direct parent, etc), processes can be confined, and the confinement extends to all their child processes as well.
+
+In the above example, A confines B, C, D and E. C confined D and E. Thus, B and C are only confined by A, whereas D and E are confined by A and C.
+
+## <a name="Meaning_Of_Words_Such_As_Secure_"> Meaning Of Words Such As Secure, Want, External, etc </a>
+
+Because the existance of a child process is completely defined by its parent, its understanding of what is secure, what its needs are, what is "external" to itself and what is internal, etc, is completely defined by the parent as well. It therefore does not make sense to object to the above model by claiming that the child can not do what it wants to do, because what the child wants to do is completely defined by the parent, as are its abilities to do it. It also does not make sense to object that the child can not determine if a capability it got from the parent is safe to use, because it is the parent which defines for the child if a capability is safe to use or not.
+
+Any such objection has, at its root, some assumption that is different from the assumptions made in this model, and thus needs to be analysed and reasoned about outside of the model.
+
+## <a name="Identify_Operation"> Identify Operation </a>
+
+An branding operation exists which, at the micro-level, allows a server process to check if a certain capability is implemented by itself. The server can then provide an identify operation to its clients, which allow the clients to check with the server if a certain capability is implemented by it. The client can then refuse to use the capability if it is not authentic.
+
+## <a name="Applications"> Applications </a>
+
+I will now describe some common applications that need to be supported, and how they can be supported in the above system structure. To make this brief, I only include applications that have any significance in the confined+isolated discussion. There are other applications (pipes, daemonization, process management), which are important to discuss, but can be solved in identical ways in both types of system structures, so I am excluding them here.
+
+## <a name="System_Services"> System Services </a>
+
+Unix-style suid applications have been proposed as one application for alternative process construction mechanisms. However, suid applications in Unix are, from the perspective of the parent, not confined, only isolated. Thus, they are readily replaced by a system service that is created by the system software, and that runs as a sibling to any user process. Only the ability to invoke the system service needs to be given to the user, not the ability to instantiate it.
+
+In fact, no gain can derived from letting the user instantiate system services. In Unix, system services run on durable resources, which the user can not revoke. Thus, the system service needs to acquire its resources from a container that is not derived from the user's primary container.
+
+## <a name="Cut_amp_Paste"> Cut &amp; Paste </a>
+
+In "[Design of the EROS Trusted Window System](http://www.eros-os.org/papers/usenix-sec2004.ps)", Shap et al describe a uni-directional communication mechanism that can be used for a cut&amp;paste operation in a window manager, that is guaranteed to not allow backflow of information. The main challenge to do this is format conversion, which traditionally requires negotiation between the two parties. In the mechanism proposed, confined constructors are used to allow the sending party to provide format converters that can be used by the receiving party to convert into a format it understands.
+
+I think that in the context of a free software operating system, and considering the threat caused by proprietary document formats, it is fully sufficient and in fact appropriate for our needs to replace this mechanism with one in which the format converters are not provided as isolated programs, but where instead at least the binary image of the format converter is provided in read-only fasion to the receiver.
+
+Accepting this means, in practice, that in the proposed protocol, the format converter constructor capability can be replaced by the vector of capabilities, which must be transitive read-only, which is put into the constructor by the sending party before sealing. The sending party then can instantiate these programs itself.
+
+This alternative mechanism breaks with the principle of least authority, because it values other principles with a higher priority.
+
+## <a name="Suspicious_Collaboration"> Suspicious Collaboration </a>
+
+Two agents in the system can collaborate suspiciously by means of a third agent. In the process, they rely on the third agent to implement the common will. This third agent can even be a constructor-like service. The validity of the service can either be established by the abovely described "Identify" operation, or, in principle, if the underlying operating system exposes the functionality of a "trusted computing" component, the two agents can even get all the guarantees and restrictions imposed by such a component. There is nothing in the system structure above that can prevent this[1]. The changes needed in the underlying operating system are purely local changes with no effect on the overall system structure.
+
+[1] I should add here that my analysis is limited to technical constraints. There may be further legal constraints imposed by software licenses such as the upcoming GPL v3, which draft has an anti-DRM provision.
+
+I said earlier that this makes it hard for me to understand why it has been said that the above system structure constitutes a "ban" on this mechanism. I believe, without having inquired further, that the reason must be that the suspicious collaboration in the above sense is a contract with limited scope. Any information that is passed from the mediating agent to either of the two parties will subsequently not be controlled further. This is in fact always true. The only difference is what the scope of the mediating agent is.
+
+In "locked down" computer systems, the mediating agent has a scope that extends to all of the operating system. For example, the window manager would be part of the mediating agent, and conspire with other components to not allow some information displayed to be read out or modified. Or it could reduce the quality of the information if such a read out occurs (as is required by HDCP licenses, for example). In the danger of repeating myself here, the differences that surfaced in the discussion are probably rooted in the issue of scope. The scope problem is not visible under a microsope, but is only revealed as emergent behaviour by a macroscopic analysis of the resulting system.
+
+Thanks, Marcus
diff --git a/NextHurd/PathMax.mdwn b/NextHurd/PathMax.mdwn
new file mode 100644
index 00000000..1c792937
--- /dev/null
+++ b/NextHurd/PathMax.mdwn
@@ -0,0 +1,3 @@
+TBD, see <http://lists.gnu.org/archive/html/l4-hurd/2005-11/msg00038.html> and [Vulnerabilities in Synchronous IPC Designs](http://citeseer.ist.psu.edu/shapiro03vulnerabilities.html)
+
+-- [[Main/TomBachmann]] - 20 Jun 2006
diff --git a/NextHurd/PermissionBits.mdwn b/NextHurd/PermissionBits.mdwn
new file mode 100644
index 00000000..1e1493df
--- /dev/null
+++ b/NextHurd/PermissionBits.mdwn
@@ -0,0 +1,3 @@
+TBD, see: <http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00231.html>
+
+-- [[Main/TomBachmann]] - 20 Jun 2006
diff --git a/NextHurd/Philosophy.mdwn b/NextHurd/Philosophy.mdwn
new file mode 100644
index 00000000..1f952017
--- /dev/null
+++ b/NextHurd/Philosophy.mdwn
@@ -0,0 +1,8 @@
+Markus Brinkmann made the effort to sketch precisely the principles that motivate his choices about the design of the new Hurd, and particularily those affecting user freedom.
+
+This effort has led to a text in two parts:
+
+* [[Part1OwnershipAndContracts]] ([[Part1OwnershipAndContractsAddendum]])
+* [[Part2SystemStructure]]
+
+See also further commentary made on the l4-hurd list: <http://lists.gnu.org/archive/html/l4-hurd/2006-08/msg00123.html>
diff --git a/NextHurd/PowerBox.mdwn b/NextHurd/PowerBox.mdwn
new file mode 100644
index 00000000..412d16d3
--- /dev/null
+++ b/NextHurd/PowerBox.mdwn
@@ -0,0 +1,19 @@
+# <a name="The_Powerbox"> The Powerbox </a>
+
+## <a name="Rationale"> Rationale </a>
+
+In a [[CapabilityBasedMicrokernel]], an application might be used with the very minimal set of capabilities that is needed to execute it, that is read-only access to it's libraries and files, plus maybe access to a specific IP connection or configuration directory.
+
+Thus when the user asks to open or save a file, the dialog used to choose the file could also serve the purpose of granting the appropriate capabilities to the application.
+
+This dialog is named the powerbox.
+
+## <a name="Links"> Links </a>
+
+* [Plash powerbox](http://plash.beasts.org/powerbox.html)
+* [E and Cap Desk](http://www.combex.com/tech/edesk.html)
+* [Polaris: Toward Virus Safe Computing for Windows XP](http://www.hpl.hp.com/personal/Alan_Karp/polaris.pdf)
+* [The E Language in a Walnut](http://www.skyhunter.com/marcs/ewalnut.html#SEC45) - search for "Powerbox Capability Manager"
+* [The Darpa Browser](http://www.combex.com/papers/darpa-report/html/index.html) - see Appendix 5
+
+-- [[Main/NowhereMan]] - 28 Apr 2006
diff --git a/NextHurd/RequirementsForUser.mdwn b/NextHurd/RequirementsForUser.mdwn
new file mode 100644
index 00000000..d23221c3
--- /dev/null
+++ b/NextHurd/RequirementsForUser.mdwn
@@ -0,0 +1,59 @@
+Requirements for the user tell what a computer system should look like from a user's perspective. Here are three of such requirements:
+
+* Awareness
+* Security
+* Flexibility
+
+# <a name="Requirements"> Requirements </a>
+
+<a name="AwarenessRequirement"></a>
+
+## <a name="Awareness"> Awareness </a>
+
+The user must know what the operations are he can perform in the operating system. He must also know about their consequences and relevant side effects, and what the possible results are. At any point where the system can not make the right decision automatically, the user must have the ability to influence the path chosen.
+
+----
+
+**Awareness means that the user knows what happens.**
+
+----
+
+<a name="SecurityRequirement"></a>
+
+## <a name="Security"> Security </a>
+
+The user must be sure that his actions have predictable consequences, even in the presence of actively hostile influence. If there is a component in the system that the user can not control, the user must be able to contain its impact, either by simply ignoring it (shielding), or by imposing restrictions (confinement).
+
+----
+
+**Security means that the user controls what can happen _to_ his resources.**
+
+----
+
+<a name="FlexibilityRequirement"></a>
+
+## <a name="Flexibility"> Flexibility </a>
+
+The user must have a range of options available that support him to achieve an arbitrary but well-defined goal that can be stated within the legitimate resources the user controls.
+
+----
+
+**Flexibility means that the user controls what can happen _with_ his resources.**
+
+----
+
+# <a name="Relationships"> Relationships </a>
+
+For me, Awareness is a requirement for both, security and flexibility. The options that are presented to the user must be meaningful and clear to him. Otherwise, how is he in a position to make a decision where the system can't? This does not mean that the user must be aware of every detail that goes on, but he must be aware of the higher-level consequences of all actions (and non-actions) that he performs.
+
+I don't know about you, but everytime some dialog box in an application I use for the first time asks me if I want to babble-gabble the froob through the bibskadenga, I just click on the biggest of the buttons presented, or the one with the nicest color, and hope for the best. So, "Awareness" is just a basic usability requirement.
+
+Security ensures that the action the user can undertake never have so dramatic consequences that the user loses control over his session and associated resources, at least not without explicitely and consciously requesting it (note that Awareness is required here).
+
+A flexible system will not achieve these goals simply by restricting the users ability to perform his tasks. It will offer the broadest range of alternatives possible, without compromising the other goals.
+
+----
+
+Adapted from:
+
+* <http://lists.gnu.org/archive/html/l4-hurd/2005-11/msg00242.html>
diff --git a/NextHurd/SetuidVsConstructor.mdwn b/NextHurd/SetuidVsConstructor.mdwn
new file mode 100644
index 00000000..44c5f7fa
--- /dev/null
+++ b/NextHurd/SetuidVsConstructor.mdwn
@@ -0,0 +1,6 @@
+TBD, see e.g.:
+
+* <http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00167.html>
+* <http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00203.html>
+
+-- [[Main/TomBachmann]] - 20 Jun 2006
diff --git a/NextHurd/SharedLibraries.mdwn b/NextHurd/SharedLibraries.mdwn
new file mode 100644
index 00000000..01b85df8
--- /dev/null
+++ b/NextHurd/SharedLibraries.mdwn
@@ -0,0 +1,3 @@
+TBD, see <http://lists.gnu.org/archive/html/l4-hurd/2005-12/msg00034.html>
+
+-- [[Main/TomBachmann]] - 20 Jun 2006
diff --git a/NextHurd/SystemStructure.mdwn b/NextHurd/SystemStructure.mdwn
new file mode 100644
index 00000000..8a9bdbe8
--- /dev/null
+++ b/NextHurd/SystemStructure.mdwn
@@ -0,0 +1,3 @@
+TBD, see: <http://lists.gnu.org/archive/html/l4-hurd/2006-05/msg00324.html> (thread). Also, note that this is derived from [[Philosophy]]. See the interface spec and the position paper as well.
+
+-- [[Main/TomBachmann]] - 31 Aug 2006
diff --git a/NextHurd/ThePolycastInterface.mdwn b/NextHurd/ThePolycastInterface.mdwn
new file mode 100644
index 00000000..5d1fb8dc
--- /dev/null
+++ b/NextHurd/ThePolycastInterface.mdwn
@@ -0,0 +1,52 @@
+# <a name="The_Polycast_Interface"> The Polycast Interface </a>
+
+## <a name="Introduction"> Introduction </a>
+
+In the current Hurd, all fs objects implement both directory and file methods. This means every program that accesses a file object has to decide whether to treat it as a file or a directory. This is no problem for programs that only know about files or directories, but there is a wide range of programs that understand both files and directories simultaneously (e.g. rm -R), and they are confused when they see objects that are files as well as directories. This causes erratic behaviour. For example, "grep \*" will search through the binary content of directories (because it treats them as files).
+
+Sometimes, the file and directory interface are refered to as \`\`facets'' of the object.
+
+## <a name="The_Problem"> The Problem </a>
+
+The problem is **much** worse than it might look like. Consider the case where one translator might reasonably implement two or more file interfaces, like a translator that simultaneously presents a .tar.bz2 file view, a .tar.gz file view and a directory view. Then you have a fundamental semantic issue:
+
+_A method call in isolation has no meaning. It can only be interpreted in the context of a particular interface._
+
+## <a name="A_Solution"> A Solution </a>
+
+The solution is simple: whenever a method is invoked, the interface has to be known. This implies two things: a) we do not use multiple inheritance and b) support for some sort of \`\`casting'' is needed. For illustration, look at the inheritence graph for an object that provides both directory and file methods:
+
+    file dir
+     \   /
+    dir_file
+
+This graph can be converted into one using only single inheritence:
+
+      poly_type
+      \    /
+    file  dir
+
+Where **poly\_type provides the methods get\_supported\_types() and get\_facet(type) for casting: get\_supported\_types returns a list of types which this object can be viewed as. get\_facet returns a new object with a new type, but the object is, at the server side, intimately related to the original object with the original type**.
+
+To give another example: the translator that provides .tar.bz2, .tar.gz and dir views would use the following inheritance graph:
+
+         poly_type
+           /    \
+         file   dir
+          /   \
+    tbz_file tgz_file
+
+tbz\_file and tgz\_file do not provide new methods, they exist only to distinct interfaces.
+
+## <a name="Usability_Considerations"> Usability Considerations </a>
+
+In order for the polycast interface to be useful, it has to work together with legacy applications (that are unaware of it). As either the [[PowerBox]] or the shell grant authority to applications, there can be some private agreement between the user and these components on how to express different interfaces of objects. For example foo:as\_dir could designate the directory facet of objecte foo. Also, different interfaces could be bound to different different names (either automatically or explicitely)
+
+----
+
+see also:
+
+* <http://lists.gnu.org/archive/html/l4-hurd/2006-02/msg00002.html>
+* <http://lists.gnu.org/archive/html/l4-hurd/2006-02/msg00003.html>
+
+-- [[Main/TomBachmann]] - 30 Apr 2006
diff --git a/NextHurd/TrivialConfinementVsConstructorVsFork.mdwn b/NextHurd/TrivialConfinementVsConstructorVsFork.mdwn
new file mode 100644
index 00000000..4d221a8e
--- /dev/null
+++ b/NextHurd/TrivialConfinementVsConstructorVsFork.mdwn
@@ -0,0 +1,78 @@
+# <a name="About_this_page"> About this page </a>
+
+This page compares trivial confinement, the constructor mechanism, and POSIX fork(). First there is a short description of the process, then there is a discussion about the differences.
+
+This comparison is about a simple situation: there is a parent process P, which wants to spawn a child process C. We assume that P holds capabilities A and B. The end result should be that C holds a copy of A, but not of B.
+
+# <a name="Trivial_Confinement"> Trivial Confinement </a>
+
+For trivial confinement, there is a system call to create a process from some memory pages. P performs the following steps:
+
+* Allocate some memory and put the code image of the child into that memory. This can be done by P, or for example by the file system which then gives the resulting memory (space bank) to P.
+* Perform the system call on that memory. The result is a capability to C.
+* Send A to C using the returned capability.
+
+Note that it is up to the implementation of the system what happens with P's access to the memory which holds the child. For example, it is probably a good idea if it is at least unmapped, so it cannot accidentily write things in it. It could even be revoked, so that it can't write things in it, even if it wants to.
+
+# <a name="Constructor"> Constructor </a>
+
+With the constructor mechanism, there are programs running on the system for the purpose of starting new programs. This means that the process is split in two steps. They need not be performed by the same party, in fact they often aren't. So there are two parents, P1 and P2. The first step:
+
+* P1 sends a message to the meta-constructor M (a constructor to create new constructors) sending it the code image for the child (and due to the limitation of this discussion, no initial capabilities).
+* In respose, M creates a C-constructor and passes a capability to it to P1.
+
+The second step:
+
+* P2 somehow receives a copy of the capability to the C-constructor.
+* P2 uses the capability to tell the C-constructor it should build a new process. It provides memory and processor time for the purpose.
+* The C-constructor uses a method similar to Trivial Confinement to actually create C. It passes the capability C back to P2 as a reply to the capability invocation.
+* P2 passes A throught the returned capability to C.
+
+This mechanism is targeted at a specific use pattern, namely that a process is created once, and then spawned many times.
+
+# <a name="POSIX_Fork"> </a> POSIX Fork
+
+POSIX fork, or rather fork+exec, is how things are done on many current systems. It may be insightful to see it included in the comparison, especially for people who are new to the subject. There are two system calls, fork and exec. Fork will create a clone of the current process, including all the capabilities (that is, file descriptors) of the parent (except the ones which have explicitly been excluded). Exec is a system call which really goes to the filesystem, not the kernel (although on systems which use it, the filesystem usually resides in the kernel), and asks it to spawn a new process from the contents of a certain path in place of the caller. This passes all capabilities to the new process. The procedure is:
+
+* P calls fork(), creating P'.
+* P' drops B.
+* P' calls exec(), turning P' into C.
+
+# <a name="Fork_vs_the_others"> Fork vs the others </a>
+
+Fork is bad. The following text should convince the reader that we do not want to use fork. If it fails to do so, please write your reply to <l4-hurd@gnuNOSPAM.org>. We can then improve this text, either by using better arguments, or by saying that fork is acceptable after all. :-)
+
+First of all, it must be clear that we are using a capability-based system. This offers a lot of security that POSIX doesn't have. The actual solution presented below doesn really work on POSIX, because C can simply reopen all the files. After all, it is running as the same user, with all the same rights, as P. This is not the case in a capability based system. Every process needs a capability to do things. The closest to the POSIX concept of a "user" is a bunch of capabilities to all objects that the user is allowed to handle. However, even if P has all those capabilities, that doesn't mean C does as well. So for example, if P doesn't give a capability to the user's home directory (and it probably will not do that indeed, but it'll give a private part instead which C can use for files), then C cannot get access to the files in there. And so in particular, if P has a capability to ~/.ssh/id\_dsa, and it doesn't give it to C, then C cannot simply call open and get the capability from there, because the file isn't in its file system.
+
+The big difference between fork and the other options is capability B. B is a private capability of P. P does not want it to be passed anywhere. In all cases this is achieved. However, fork needs to be explicit about this. If P (or actually P') forgets to drop B, everything will still work (C didn't use B anyway). However, if C contains a security bug and is taken over by a cracker, then that cracker has access to B. This means that due to a simple mistake, the concequences of a compromised C are bigger than they need to be. This problem is of course even bigger if C is untrusted code in the first place, because it doesn't even need to be "taken over" then, it may simply be malicious.
+
+In contrast, the other two options don't pass anything by default. If there is a similar mistake there, they would forget to pass A to C. That will soon be noticed, because C actually needs A (otherwise it shouldn't receive it). So C will fail to work. This will quickly be fixed, resulting in a better program.
+
+## <a name="Solving_the_problem"> Solving the problem </a>
+
+The problem of fork+exec can be solved. It is if the default would be to not pass capabilities to the new process, but specify a list of capabilities that it should keep, or (like in the other cases) pass them over a new channel which is implicitly created during the fork. However, in that case the only difference with trivial confinement is that P' dies in the process (and thus must be created to prevent P from dying). Almost any use of exec is in practice preceded by a fork for this purpose. It would be easier to make trivial confinement the default operation and let P die directly after it in the rare case that it should.
+
+The only reason for continuing to use fork+exec would be that it is what existing programs do. However, they break anyway if they need to specify which file descriptors to pass. So they need to be adapted. Therefore, it's better to make the usual spawning method the primitive one, and emulate the other.
+
+# <a name="Trivial_Confinement_vs_Construct"> Trivial Confinement vs Constructor </a>
+
+Note: the following has not been extensively discussed on the mailing list, and no consensus has been reached AFAIK. This is the personal opinion of Bas Wijnen.
+
+The difference between trivial confinement and the constructor is one of control. With trivial confinement, P is in full control of the process (and since P is under full control of its own parent, that parent also fully controls C, and the parent's parent as well, etc. Note that the chain of parents is usually short). 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.
+
+-- [[Main/BasWijnen]] - 13 Jun 2006
diff --git a/NextHurd/UseCasePrivateKeys.mdwn b/NextHurd/UseCasePrivateKeys.mdwn
new file mode 100644
index 00000000..612a8f25
--- /dev/null
+++ b/NextHurd/UseCasePrivateKeys.mdwn
@@ -0,0 +1,13 @@
+_Private Keys_ as used by SSH servers, clients and generally by any cryptographic software need to be stored and manipulated securely. These may get replaced with smartcards soon, but in the mean time it appears to be an interesting use case.
+
+All Unix systems that I am aware of do not allow secrets to be protected in a manner that I would feel is appropiate. A users compromised web browser could either read your private key file or talk to the very popular ssh-agent program and get your secrets out (not sure how popular distributions are configured, but it can be done).
+
+The requirements so far are:
+
+* The secrets should not be available to general programs
+* The ability to use secrets for their intended purpose (signing/encryption/decryption/ssl streams)
+* Programs using decrypted data should be, by default, confined so that the data can't escape
+* Must be able to backupand restore secrets securely
+* Upgrading the agent software must be possible! using the backup/restore mechanism?
+
+-- [[Main/SamMason]] - 11 Jan 2007
diff --git a/NextHurd/UseCaseUserFileSystem.mdwn b/NextHurd/UseCaseUserFileSystem.mdwn
new file mode 100644
index 00000000..6dce5670
--- /dev/null
+++ b/NextHurd/UseCaseUserFileSystem.mdwn
@@ -0,0 +1,14 @@
+### <a name="User_Loadable_Filesystems"> User Loadable Filesystems </a>
+
+These appear as _translators_ in the current Hurd and something similar needs to appear in the next hurd.
+
+* The user should be able to dynamically add and remove translators
+* For some reason it seems appropiate to have seperate namespaces (VFS's) for each user (this is quite a departure from Unix. [[SamMason]])
+* translators can be used to expose the structure of an archive file
+* translators can be provide access to remote file systems
+
+Anything else?
+
+Probably not something we want to worry about now; but I'm guessing that the semantics of the new kernel will be sufficently different from Mach that some rewriting of the existing translators will be needed. From a pragmatic point of view it would be _nice_ if there wasn't too much change.
+
+-- [[Main/SamMason]] - 11 Jan 2007
diff --git a/NextHurd/WhatIsACapability.mdwn b/NextHurd/WhatIsACapability.mdwn
new file mode 100644
index 00000000..a4ed5ed8
--- /dev/null
+++ b/NextHurd/WhatIsACapability.mdwn
@@ -0,0 +1,3 @@
+TBD, see e.g.: <http://www.eros-os.org/essays/capintro.html>
+
+-- [[Main/TomBachmann]] - 20 Jun 2006
diff --git a/NextHurd/WhatIsAConstructor.mdwn b/NextHurd/WhatIsAConstructor.mdwn
new file mode 100644
index 00000000..3f05a37a
--- /dev/null
+++ b/NextHurd/WhatIsAConstructor.mdwn
@@ -0,0 +1,6 @@
+TBD, see:
+
+* <http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00157.html>
+* <http://lists.gnu.org/archive/html/l4-hurd/2006-05/msg00056.html>
+
+-- [[Main/TomBachmann]] - 16 May 2006
diff --git a/NextHurd/WhatIsASpacebank.mdwn b/NextHurd/WhatIsASpacebank.mdwn
new file mode 100644
index 00000000..d7961210
--- /dev/null
+++ b/NextHurd/WhatIsASpacebank.mdwn
@@ -0,0 +1,3 @@
+TBD, see e.g. <http://eros-os.org/design-notes/SpaceBank.html> or <http://eros-os.org/papers/shap-thesis.ps>
+
+-- [[Main/TomBachmann]] - 31 Aug 2006
diff --git a/NextHurd/WhatsInAGroup.mdwn b/NextHurd/WhatsInAGroup.mdwn
new file mode 100644
index 00000000..122f2012
--- /dev/null
+++ b/NextHurd/WhatsInAGroup.mdwn
@@ -0,0 +1,3 @@
+TBD, see <http://lists.gnu.org/archive/html/l4-hurd/2006-03/msg00001.html>
+
+-- [[Main/TomBachmann]] - 20 Jun 2006