Re: Part 2: System Structure

[Jonathan S. Shapiro]

On Wed, 2006-05-17 at 11:32 +0200, Bas Wijnen wrote:

> > > Ok, this is a technical thing.  I'm assuming that the space bank can
> > > provide me a page of memory which I can use.  If it's hard, I'll use a
> > > library for it.  No problem.
> > 
> > It can. The difficulty is that the space bank has no idea how you glue
> > together the pieces that it hands you. The situation is similar to
> > having a disk driver that will give you back any block that you want.
> > You still need to know how the file system is structured to make this
> > useful.
> > 
> > Except that the process relationships are more complicated than the
> > relationships of data structures in the file system.
> 
> If the constructor can do it, then a library can as well.  I don't see how
> complexity can be an argument here.

The constructor cannot do it either. The constructor's job is to *build*
processes. It has no ability whatsoever to do forensics based on the
low-level object types.


> > This has nothing to do with the open/closed/transparent issue. It's a
> > simple matter of fault isolation. This is why I have stated my opinion
> > that Hurd should use the Constructor pattern for process creation even
> > if it does not impose the encapsulation and opaqueness properties.
> 
> While I think the problems you described may be solvable, I wasn't actually
> thinking about shared libraries.  I was thinking about static libraries.  The
> point is that if something requires complex code, that is no reason to move it
> into a separate process.  It's a reason to prepare the code in advance and use
> it when needed.  One way of "preparing" is to put it in a process of its own.
> A library (which can be static) is another way, and it's less complex IMO.

Making this a static library is infinitely worse than making it a
dynamic library. If you make it a static library, you can't (in
practice) fix it.

Your statement that "preparing" is sufficient is completely contrary to
the entire history of system building experience since the beginning of
computer science. The plain fact is that stray pointers exist, and there
is absolutely no amount of preparation that can protect you from this
error if you are in a single address space.

Even in "safe" languages there is a significant likelihood of error in
the runtime system, and in practice all safe languages have "escape
hatches" for plugable access to native libraries and such.

> > > Opaqueness is like virginity. Once you give it up, you can never get it
> > > > back. In consequence, if *any* process *ever* requires opaqueness, the
> > > > default must be to make storage opaque.
> > > 
> > > Nonsense.  If a process requires opaqueness, there must be a way to
> > > allocate opaque storage.  There's no reason at all that it must be the
> > > default.
> > 
> > The problem with your approach is that it only takes one omission by a
> > single programmer to expose a whole lot of stuff.
> 
> Not at all.  Consider the constructor-approach: every spawned process will be
> a sibling of every other one.  It's a flat structure, really.  Therefore,
> using a transparent space bank in that case doesn't change anything, because
> the parents (that's the constructors) aren't going to look at the memory
> anyway.

We are operating from fundamentally different assumptions. I do not
accept the assumption that a viable system can be built in which no
child program can every guard its runtime memory image from its parent.

> > If opaqueness is the default, and you leave out the "make it visible"
> > option, your program tends to break very quickly and you notice it.
> 
> Not at all.  In my use case above, it took 3 years (which obviously was an
> arbitrary "long time").

If you really managed to go 3 years without noticing that you weren't
transparent, then you didn't need to be transparent.

> > > > This is fundamental. There really *are* programs that need to manage
> > > > sensitive state, and you really *don't* want those programs (in most
> > > > cases) to have to run off of system-supplied storage.
> > > 
> > > Actually, I think in most cases we very much do want this.  Maybe even in
> > > all cases (but we're still discussing that).
> > 
> > In order for such a program to be correct, it must be designed in such a
> > way that all request messages to this services have payload sizes that
> > can be statically sized at IPC compile time.
> 
> Not at all.  We can let the user provide any storage we need, except for parts
> which must not be disclosed to them.  Obviously a buffer for an IPC transfer
> may be disclosed to the user.

No, you cannot. Any storage supplied by the user is destroyable by the
user, and the service must then guard itself against the possibility of
memory faults. From a strictly pragmatic perspective this is not really
feasible in the general case. There are a few restricted idioms where
this is survivable, but they are *very* restricted for reasons of
pragmatics.

> > > > The system design that Marcus proposes relies on a process hierarchy
> > > > with trusted system processes close to the top. A problem with this
> > > > design, which will become apparent to developers after 2-3 years of
> > > > coding,
> > > 
> > > If you see it coming already, then it should be easy for you to find an
> > > actual use-case where this problem shows up.  Please share this with us.
> > 
> > Bas: Marcus has made it clear that he wishes me to diminish my
> > participation, and I have a product to deliver. I simply do not have time to
> > devote to this activity when it is unlikely that my input will produce any
> > value.
> 
> I know, and I'm not happy at all with it.  But you sounded like you already
> had several examples ready.  If that is the case, I would like you to tell us.
> If it costs more time, then I can understand that you don't want to spend that
> on it.  But as I said, I'm not happy with that.

I have an enormous number of examples where private storage is
essential. All of them have been rejected here (without, so far as I can
tell, any semblance of serious consideration) on grounds of ideology.

Concerning the "trusted processes near the top", the most likely place
that a problem will appear is in the problem of dynamically-sized IPC
messages, which we are discussing above. I suggest that we put more
attention on that for the moment.

> > > > is that this design only works in a transparent storage design IF those
> > > > servers supply the storage for all of the operations that they perform
> > > > (i.e.  they never rely on user-supplied storage).
> > > 
> > > They shouldn't rely on user-supplied storage for things that they don't
> > > want to share with the user.  They can rely on user-supplied storage for
> > > all other things, which is a lot.  Actually, the non-sharable part would
> > > usually be constant size, I think, so in that case there is no problem.
> > 
> > It turns out to be surprisingly easy to have an IPC that has a
> > dynamically sized element. Anything that passes a string as an argument
> > is an example...
> 
> But those don't fall in the category "that they don't want to share with the
> user".

True, but they do fall into the category "memory that the server would
like to be able to read without risking an exception", and the server
cannot do this.

> > > > The problem with this is that there is a "free rider" problem that leads
> > > > directly to denial of resource.
> > > 
> > > It would if the size is not O(0).  Please give an example of a case where
> > > it isn't.
> > 
> > POSIX open(2).
> 
> You mean the pathname argument?  I thought you wanted that to have a real
> PATH_MAX. :-)  Anyway, it's not something that the user can't know.
> 
> > POSIX read(2).
> 
> This too, is not something that the user may not see.  Except of course if the
> server needs to read on request of the user from a protected file.  But in
> that case the server defines the buffer size, so it is O(0).

In both cases, the issue is exceptions, not disclosure.

> > > That's not what Marcus' proposal says either.  The only "new" thing
> > > (compared to EROS) is that it says "if you want me to run your code, you
> > > need to give it to me".
> > 
> > This also goes FAR beyond GPL.
> 
> The GPL is about other things, not about what users within one system do.  The
> GPL says things like "If you give me a CD with your program, you must provide
> the source code".  This is about users within one system, running each other's
> programs.  As I said, if I want you to run my program, I have to give you a CD
> with the program on it in normal life.  In this case, it is technically
> possible that I don't.  This is not something the GPL talks about.

That is one view. But the very fact that GPL does *not* regulate
interactions between users (in the absence of copy) appears to have been
an intentional decision.

It is legitimate for the Hurd project to introduce and entire new area
(inter-party interactions on a single machine) of "socially beneficial
restriction" as an experiment, and to lobby that this is the right thing
to do. However, it is important to recognize that this has HUGE
implications, and that FSF may or may not wish to be associated with
such a major change. At the very least, FSF input must be obtained
before adopting a policy of this level of intrusiveness in an
FSF-sponsored project.

> All you want is totally possible with a transparent space bank.  The only
> thing is that the one who wants to keep his program secret has to pay for the
> storage.  Ok, and encapsulation isn't guaranteed to the instantiator.

I have definitely got examples where this restriction makes certain
secure subsystems impossible to create. Once again, the examples that I
have put on this list have been dismissed without any serious
consideration, and I don't see any point wasting further time unless
they will be considered respectfully.

Legitimate disagreement is acceptable. Disrespectful dismissal is not.


shap