diff options
Diffstat (limited to 'hurd/ng')
| -rw-r--r-- | hurd/ng/choiceofmicrokernel.mdwn | 4 | ||||
| -rw-r--r-- | hurd/ng/discussion.mdwn | 13 | ||||
| -rw-r--r-- | hurd/ng/history.mdwn | 50 | ||||
| -rw-r--r-- | hurd/ng/issues_with_mach.mdwn | 12 | ||||
| -rw-r--r-- | hurd/ng/limitations_of_the_original_hurd_design.mdwn | 6 | ||||
| -rw-r--r-- | hurd/ng/microkernelcoyotos.mdwn | 9 | ||||
| -rw-r--r-- | hurd/ng/part2systemstructure.mdwn | 15 | ||||
| -rw-r--r-- | hurd/ng/position_paper.mdwn | 15 | ||||
| -rw-r--r-- | hurd/ng/resource_management_problems.mdwn | 19 | ||||
| -rw-r--r-- | hurd/ng/trivialconfinementvsconstructorvsfork.mdwn | 24 | ||||
| -rw-r--r-- | hurd/ng/usecaseprivatekeys.mdwn | 6 | ||||
| -rw-r--r-- | hurd/ng/usecaseuserfilesystem.mdwn | 2 |
12 files changed, 62 insertions, 113 deletions
diff --git a/hurd/ng/choiceofmicrokernel.mdwn b/hurd/ng/choiceofmicrokernel.mdwn deleted file mode 100644 index 20ee6f05..00000000 --- a/hurd/ng/choiceofmicrokernel.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -TBD - -* [[MicrokernelL4]] -* [[MicrokernelCoyotos]] diff --git a/hurd/ng/discussion.mdwn b/hurd/ng/discussion.mdwn new file mode 100644 index 00000000..d4632bd5 --- /dev/null +++ b/hurd/ng/discussion.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +To go beyond research project Hurd have to support thousands of various programs running on GNU/Linux nowadays. +It looks like ExoKernel approach http://pdos.csail.mit.edu/exo.html might be useful here. +Does somebody tried to look into something like Hurd exokernel + liblinux? diff --git a/hurd/ng/history.mdwn b/hurd/ng/history.mdwn deleted file mode 100644 index 652bccf3..00000000 --- a/hurd/ng/history.mdwn +++ /dev/null @@ -1,50 +0,0 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] - -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU_Free_Documentation_License|/fdl]]."]]"""]] - -The idea of using [[microkernel/L4]] as a [[microkernel]] for a -[[Hurd_system|hurd]] was initially voiced in the [[Hurd_community|community]] -by Okuji Yoshinori. He created the [[mailing_lists/l4-hurd]] mailing list in -November 2000. It does not appear that he got any further than simply -suggesting it as an alternative to [[microkernel/Mach]] and doing some reading. - -Neal Walfield started the original Hurd/L4 port while at Karlsruhe in 2002. -He explains: - -> My intention was to adapt the Hurd to exploit L4's concepts and intended -> [[design_pattern]]s; it was not to simply provide a Mach -> [[compatibility_layer]] on top of L4. When I left Karlsruhe, I no longer had -> access to [[microkernel/l4/Pistachio]] as I was unwilling to sign an NDA. -> Although the specification was available, the Karlsruhe group only [released -> their code in May -> 2003](https://lists.ira.uni-karlsruhe.de/pipermail/l4ka/2003-May/000345.html). -> Around this time, Marcus began hacking on Pistachio. He created a relatively -> complete run-time. I didn't really become involved again until the second -> half of 2004, after I complete by Bachelors degree. - -> Before Marcus and I considered [[microkernel/Coyotos]], we had already -> rejected some parts of the Hurd's design. The [[resource_management_problems]] -> were what prompted me to look at L4. Also, some of the problems with -> [[translator]]s were already well-known to us. (For a more detailed -> description of the problems we have identified, see our [[critique]] in the -> 2007 July's SIGOPS OSR. We have also written a forward-looking -> [[position_paper]].) - -> We visited Jonathan Shapiro at Hopkins in January 2006. This resulted in a -> number of discussions, some quite influential, and not always in a way which -> aligned our position with that of Jonathan's. This was particularly true of -> a number of security issues. - -A lange number of discussion threads can be found in the archives of the -[[mailing_lists/l4-hurd]] mailing list. - -> Hurd-NG, as we originally called it, was an attempt to articulate the system -> that we had come to envision in terms of interfaces and description of the -> system's structure. The new name was selected, if I recall correctly, as it -> clearly wasn't the Hurd nor the Hurd based on L4. diff --git a/hurd/ng/issues_with_mach.mdwn b/hurd/ng/issues_with_mach.mdwn deleted file mode 100644 index cb4de906..00000000 --- a/hurd/ng/issues_with_mach.mdwn +++ /dev/null @@ -1,12 +0,0 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] - -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU_Free_Documentation_License|/fdl]]."]]"""]] - - * [[Resource_management_problems]] - * [[Critique]] diff --git a/hurd/ng/limitations_of_the_original_hurd_design.mdwn b/hurd/ng/limitations_of_the_original_hurd_design.mdwn index 25f03372..96d8912b 100644 --- a/hurd/ng/limitations_of_the_original_hurd_design.mdwn +++ b/hurd/ng/limitations_of_the_original_hurd_design.mdwn @@ -1,11 +1,11 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled -[[GNU_Free_Documentation_License|/fdl]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] * [[Critique]] diff --git a/hurd/ng/microkernelcoyotos.mdwn b/hurd/ng/microkernelcoyotos.mdwn deleted file mode 100644 index 40fd6e9d..00000000 --- a/hurd/ng/microkernelcoyotos.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -# <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/hurd/ng/part2systemstructure.mdwn b/hurd/ng/part2systemstructure.mdwn index 4ce8026f..0f94ff2a 100644 --- a/hurd/ng/part2systemstructure.mdwn +++ b/hurd/ng/part2systemstructure.mdwn @@ -38,7 +38,12 @@ It is clear from this description that the child's existance is completely deter ## <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. +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). @@ -84,7 +89,13 @@ I will now describe some common applications that need to be supported, and how ## <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. +[[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. diff --git a/hurd/ng/position_paper.mdwn b/hurd/ng/position_paper.mdwn index 3240a41d..abc781da 100644 --- a/hurd/ng/position_paper.mdwn +++ b/hurd/ng/position_paper.mdwn @@ -1,14 +1,15 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled -[[GNU_Free_Documentation_License|/fdl]]."]]"""]] +[[GNU Free Documentation License|/fdl]]."]]"""]] -[[NealWalfield]] and [[MarcusBrinkmann]] wrote a paper titled [*Improving -Usability via Access Decomposition and Policy -Refinement*](http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf). -This is sometimes referred to as *the position paper*. +Neal Walfield and Marcus Brinkmann wrote a paper titled [*Improving Usability +via Access Decomposition and Policy +Refinement*](http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf) +where they give an overview about how a future, subsequent system may be +architected. This is sometimes referred to as *the position paper*. diff --git a/hurd/ng/resource_management_problems.mdwn b/hurd/ng/resource_management_problems.mdwn deleted file mode 100644 index 856afb1a..00000000 --- a/hurd/ng/resource_management_problems.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] - -[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU_Free_Documentation_License|/fdl]]."]]"""]] - -[[microkernel/Mach]] interfaces do not allow for proper resource accounting, -when a server allocates resources on behalf of a client. - -Mach can't do a good job at resource management, as it doesn't have enough -information how resources are used: which data is important and which is -discardable, for example. - -These issues are what Neal Walfield is working on with his new kernel -[[microkernel/viengoos]]. diff --git a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn index 4eeef6ee..949895e7 100644 --- a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn +++ b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn @@ -6,10 +6,11 @@ This comparison is about a simple situation: there is a parent process P, which # <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: +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. +* 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. @@ -32,7 +33,16 @@ This mechanism is targeted at a specific use pattern, namely that a process is c # <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: +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 call]]s, fork +and exec. Fork will create a clone of the current process, including all the +capabilities (that is, [[unix/file_descriptor]]s) 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. @@ -52,7 +62,11 @@ In contrast, the other two options don't pass anything by default. If there is 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. +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 +[[unix/file_descriptor]]s 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> @@ -67,7 +81,7 @@ Except for the control, there is really only one other difference, and that's ad 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. +* Make the [[system call]] to turn it into a program. Now this isn't much more complicated than the constructor which does: diff --git a/hurd/ng/usecaseprivatekeys.mdwn b/hurd/ng/usecaseprivatekeys.mdwn index 612a8f25..3cb65af2 100644 --- a/hurd/ng/usecaseprivatekeys.mdwn +++ b/hurd/ng/usecaseprivatekeys.mdwn @@ -1,6 +1,10 @@ _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). +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: diff --git a/hurd/ng/usecaseuserfilesystem.mdwn b/hurd/ng/usecaseuserfilesystem.mdwn index 6dce5670..4e4fdf35 100644 --- a/hurd/ng/usecaseuserfilesystem.mdwn +++ b/hurd/ng/usecaseuserfilesystem.mdwn @@ -3,7 +3,7 @@ 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]]) +* 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 |