[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Restricted storage
From: |
Jonathan S. Shapiro |
Subject: |
Re: Restricted storage |
Date: |
Mon, 29 May 2006 15:14:27 -0400 |
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
Re: Restricted storage,
Jonathan S. Shapiro <=
Re: Restricted storage, Jonathan S. Shapiro, 2006/05/30