Re: Restricted storage

[Pierre THIERRY]

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
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature