l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Restricted storage


From: Pierre THIERRY
Subject: Re: Restricted storage
Date: Mon, 29 May 2006 18:28:02 +0200
User-agent: Mutt/1.5.11+cvs20060403

Scribit Bas Wijnen dies 29/05/2006 hora 14:28:
> Theoretically I agree, but I don't see much use for anything other
> than "opaque", "readable data", and "unrestricted".  Anything other
> than "unrestricted" (to the user, I'm fine with "opaque" to the
> requestor) is very special.

Then you break the Flexibility requirement. I don't see a valid reason
to do so. If you want to break a requirement, you have to point out a
strong need for it.

> > I wonder if a write notice flag could be interesting.
> Perhaps.  I suspect that it will cost performance in situations where
> it isn't used though, which is unacceptable IMO (because it will
> hardly ever be used, I suppose).

I'm pretty sure it can be built so that when not used, it has no impact.
The notifier could be some sort of proxy, and it then it would just be
absent when not used. In most cases, write notification would only be
needed once (just to know when initial integrity is broken), and the
system could be made to remove that proxy then.

> > > - 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.
> It is.  And it behaves exactly the same.

Then please describe the properties of your system more carefully. You
didn't specify for which process the child in the sub-Hurd could not be
restricted any more.

> If P owns C1, then C1 automatically trusts P completely.

Then why would you need anything else than translucent storage?! You're
making an assumption here that makes the whole discussion obsolete...

> > 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.
> If you want to start a process in restricted storage, it must be
> started by a service which checks that the storage is restricted.  It
> doesn't have to be a constructor

Maybe it won't be a constructor exactly, but I think it will have many
properties of the constructor.

> > How is your restricted storage non-recursive?
> If C1 creates an opaque sub-space bank from its own (to run C2 on),
> then it doesn't become recursively opaque to C1's parents.

Then your proposal is absolutely of no use in the competition and ping
cases, IIUC.

Doubtfully,
Nowhere man
-- 
address@hidden
OpenPGP 0xD9D50D8A

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]