From 0f98bd853e71466b60189d18148d2b4b66c5d238 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 14 Sep 2007 15:31:38 +0200 Subject: Add some more wiki links. --- destructive_interference.mdwn | 39 +++++++++++++++++++++++++++++++++++++++ destructiveinterference.mdwn | 39 --------------------------------------- ipc.mdwn | 8 ++++---- 3 files changed, 43 insertions(+), 43 deletions(-) create mode 100644 destructive_interference.mdwn delete mode 100644 destructiveinterference.mdwn diff --git a/destructive_interference.mdwn b/destructive_interference.mdwn new file mode 100644 index 00000000..941da8a4 --- /dev/null +++ b/destructive_interference.mdwn @@ -0,0 +1,39 @@ +[[license text=""" +Copyright © 2007 Free Software Foundation, Inc. + +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.txt]]. + +By contributing to this page, you agree to assign copyright for your +contribution to the Free Software Foundation. The Free Software Foundation +promises to always use either a verbatim copying license or a free +documentation license when publishing your contribution. We grant you back all +your rights under copyright, including the rights to copy, modify, and +redistribute your contributions. +"""]] + +Interference can be destructive or non-destructive. When a [[principal]] +invokes an object (thereby requesting a service) and the implementation +carries out the principal's intent, the interference was non-destructive +in the sense that the interference was desired. + +In invoking the object, the principal may make itself vulnerable to +destructive interference. When a user runs Solitaire on Windows, +the Solitaire program is instantiated and given all of the user's +authority. The program may delete all of the users files after +publishing credit card and other sensitive information on the Internet. +This type of interference is undesirable, however, generally practically +unavoidable due to the way programs work on Windows (and Unix, for that +matter). + +The problem is that the callee has induced negative consequence for caller +due to actions of the former. To not have to depend on another program (and +thereby not have to add it to its [[tcb]]), it is necessary that the +caller only make itself vulnerable to destructive inference in ways that +can be detected and from which it can recover. + +Mark Miller examines the idea of destructive interference in his PhD thesis +[Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control](http://www.erights.org/talks/thesis/). diff --git a/destructiveinterference.mdwn b/destructiveinterference.mdwn deleted file mode 100644 index 227710a7..00000000 --- a/destructiveinterference.mdwn +++ /dev/null @@ -1,39 +0,0 @@ -[[license text=""" -Copyright © 2007 Free Software Foundation, Inc. - -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.txt]]. - -By contributing to this page, you agree to assign copyright for your -contribution to the Free Software Foundation. The Free Software Foundation -promises to always use either a verbatim copying license or a free -documentation license when publishing your contribution. We grant you back all -your rights under copyright, including the rights to copy, modify, and -redistribute your contributions. -"""]] - -Interference can be destructive or non-destructive. When a principal -invokes an object (thereby requesting a service) and the implementation -carries out the principal's intent, the interference was non-destructive -in the sense that the interference was desired. - -In invoking the object, the principal may make itself vulnerable to -destructive interference. When a user runs Solitaire on Windows, -the Solitaire program is instantiated and given all of the user's -authority. The program may delete all of the users files after -publishing credit card and other sensitive information on the Internet. -This type of interference is undesirable, however, generally practically -unavoidable due to the way programs work on Windows (and Unix, for that -matter). - -The problem is that the callee has induced negative consequence for caller -due to actions of the former. To not have to depend on another program (and -thereby not have to add it to its [[tcb]]), it is necessary that the -caller only make itself vulnerable to destructive inference in ways that -can be detected and from which it can recover. - -Mark Miller examines the idea of destructive interference in his PhD thesis -[Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control](http://www.erights.org/talks/thesis/). diff --git a/ipc.mdwn b/ipc.mdwn index a3dda6b3..78d74f33 100644 --- a/ipc.mdwn +++ b/ipc.mdwn @@ -25,12 +25,12 @@ provided by the Unix kernel and Unix is not designed to be [[Microkernel]] systems, on the other hand, are generally composed of many components. As components are separated by their respective -address space boundaries, unlike the kernel, they cannot arbitrarily +[[address_space]] boundaries, unlike the kernel, they cannot arbitrarily examine and modify the caller's state. The advantage is that if the protocol is carefully designed, the callee cannot cause the caller -any [[destructive interference]] thereby removing the need for the +any [[destructive_interference]] thereby removing the need for the caller to [[trust]] the callee thus reducing the former's [[tcb]]. When done systematically, this can increase the system's [[robustness]]. To this end, microkernels provide richer IPC semantics that include -the ability to transfer [[capabilities]] and to use virtual memory -mechanisms to copy data. +the ability to transfer [[capabilities]] and to use [[virtual_memory]] +[[mechanism]]s to copy data. -- cgit v1.3.1