Scribit Bas Wijnen dies 29/05/2006 hora 11:16: > - 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.
I don't see why there should be an automatic distinction between data and capabilities pages. This breaks the Flexibility requirement. I'll suggest the following permissions, that could be applied to data or caps or both: - read/write - read - none I wonder if a write notice flag could be interesting. If that flag was activated, some process would be notified when the corresponding pages were written. That could allow a parent to write it's child's storage, but still enable the integrity verification of the child by another process (there would be a need for an integrity protocol, though). In the ping example, I think that data(read) and caps(none) permissions are enough to make it robust and secure. And not all capabiliy pages have to be unreadable. In fact, the whole storage of ping should just be read-only, with the exception of the page holding the network stack capability. In general, some capabilities typically given by the constructor need only to be read-only, for example the TCB ones, like to the meta-constructor and the constructor. Though in some virtualization cases, they also should be unreadable. (Jonathan, I think I'm starting to understand why you think that disclosure should not be the default) > - 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. Then again, this breaks Flexibility. This also breaks virtualization. I don't see why a sub-Hurd could not be a "real" Hurd, with all the possible features of Hurd. That is, a sub-Hurd would not only be used for debugging (which you seem to assume), but also for things like virtual dedicated servers. The only requirement of restricted storage about debugging is that a parent storage bank can deny to a storage bank allocated from it to reduce some of it's permissions. If P process spawns a C1 process in a translucent storage (that is, read/write), I obviously don't want C1 to be able to spawn a C2 process in storage that is opaque to P. But it should be possible for C1 to spawn C2 in an opaque storage for C1 that is translucent for P. The only question then is if it is desirable that C2's storage be translucent to someone. If P is a sub-Hurd where C2 is installed in a constructor that consider P part of it's TCB, that's fine. > - 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 agree. That just seems to me to be a fundamental axiom of software debugging. That's why we use debuggers instead of crippling the code with debugging instructions... But I think this makes the constructor unavoidable if you want restricted storage to be of any use, because the check that the storage is indeed restricted has to be made somewhere. > So Jonathan, I'm particularly interested in your answer to the > question: Do you agree that restricted storage (in the way I want it, > so non-recursive) How is your restricted storage non-recursive? Curiously, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
