On Mon, 2006-05-29 at 11:16 +0200, Bas Wijnen wrote: > Hello everyone, > > We've been discussing the options of restricted storage a bit. These > "restrictions" are from the supplier of the storage. It is possible that > there are different restrictions for different suppliers (that is, for the > parent, and for the parent's parent, etc). I'll say some things which I'm > pretty sure about first: > - There are two types of restricted storage: read-only, and no-access. Both > types do not provide access to the capabilities of the running program. > - When a user starts a sub-Hurd (or debugs a program in some other way), it > must be impossible for the program, or any of the programs it spawns on its > own storage, to become restricted. > - If a user debugs a program (in a sub-Hurd or otherwise), the program must > not be able to detect this (except through contact with other programs which > can see it, but they are not likely to have capabilities to them). A > program's behaviour must thus be completely orthogonal to the fact if it's > being debugged. > > I think Jonathan does not agree with the last two points. These are design > choices, and he makes different choices. That's fine. I'm just saying that > these are the choices I expect the Hurd to make.
Yes, but my reason on the last point may surprise you: I disagree about the "undetectable debugging" point because it is, in principle, impossible to achieve. I have no objection to the idea that debugging should be as non-intrusive as possible. It is also okay if the program has to go to extraordinary means to detect that it is actually being debugged. However, I do not know of any way (technically) to prevent detection by a program that is *willing* to go to extraordinary means. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
