Re: Restricted storage

[Jonathan S. Shapiro]

On Mon, 2006-05-29 at 11:16 +0200, Bas Wijnen wrote:
> There is one very important point though.  I think those restrictions can
> easily be implemented in the user session.  This means that we can just build
> a system with no support for restricted storage, and add it if we find that we
> did need it after all.  However, Jonathan doesn't seem to agree.  At the
> moment I still think he doesn't quite understand what I mean.  However, if he
> does and is correct that it cannot be added later, we would need to decide
> this before building the system.
> 
> 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) can
> be implemented later, in the user session, or do you still think this is very
> hard?  If you think it is very hard, why?  And related, do you think there is
> anything wrong with non-recursive restrictions (so that the process starting a
> sub-Hurd can always read and modify any storage inside it), in the sense that
> it makes things impossible which should be possible (considering our
> objectives)?

Bas:

I haven't followed your example closely enough to understand what you
mean by "non-recursive", and I don't have time to dig through the
archive. I am therefore unable to answer your question about the
non-recursive part. For the same reason, I don't have a counter-example
and I do not plan to take the time to come up with one.

I do not find the entire "private drivers" idea to be motivating. It
will be ten years before hardware that can support this in the general
cases is available. The special case of writing a user mode driver on
top of a generic layer (e.g. SCSI generics, or possibly a similar thing
for USB) really isn't a driver at all; it is simply a format converter.

Concerning restricted storage: I think it is *impossible* to add later,
and I have stated the reason many times already:

  Removing restricted storage is not simply a minor change in feature
  set. It is a major change in the entire philosophy of system design.
  If the initial system incorporates a "translucent storage" assumption,
  code will be written to assume this, and it will later become
  impossible to add opaque storage compatibly -- not because it is
  technically impossible, but because the changes required to fix hidden
  assumptions will be too large.

  The reverse is also true: the move to translucency cannot
  (pragmatically) be done later.

shap