On Sun, 2007-01-07 at 03:02 +0100, Pierre THIERRY wrote: > Scribit Marcus Brinkmann dies 07/01/2007 hora 02:35: > > The right question to ask is if there is a significant difference in > > the harm that can result from such an arrangement if I am out of > > control compared to when I retain control. I believe that to be the > > case.
PLEASE be SPECIFIC! Control over *what*!? > I may not remember well the past debate, but did you already give facts > supporting that belief? I'm not sure that opaque memory as we discussed > it now can do any harm per se. So far as I can tell, there is harm in both cases. The harm of the "opaque memory" design is the possibility of non-transitive copy and non-inspectable code. The immediate harms of the "transparent memory" proposal are (1) a requirement for hierarchy, which has been found in other systems to inhibit or defeat the Principle of Least Authority (POLA). POLA has been found to be a very effective architectural tool in achieving robust system designs. (2) The apparent need to introduce a significantly more complicated and more vulnerable resource management model (partitioned resource types, a.k.a. network space banks) to handle as a special case those places where opaque memory was desirable. The larger harm of the "transparent memory" proposal is that we do not (yet) have any comprehensive description of an overall system design based on this model, and we certainly have no security design for it (yet). I completely support Marcus in his view that the "transparent memory" proposal is worth exploring, but in my opinion it would be irresponsible to design this assumption into a widely deployed system until its implications are more fully understood. My concern is that I do not see the necessary design work occurring that would determine that. This may be simply because that discussion is not occurring here. shap -- Jonathan S. Shapiro, Ph.D. Managing Director The EROS Group, LLC +1 443 927 1719 x5100 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
