Re: Part 2: System Structure

[Jonathan S. Shapiro]

On Tue, 2006-05-16 at 17:12 +0200, Bas Wijnen wrote:
> On Tue, May 16, 2006 at 10:16:47AM -0400, Jonathan S. Shapiro wrote:
> > What Bas is saying is complete bullshit.
> 
> Thanks. :-)  You may want to relax a bit. ;-)
> 
> > EROS doesn't do this "because it is EROS".
> 
> I didn't say that.  I said I was assuming this was how the constructor would
> be implemented in the Hurd if it would be implemented, because this is how
> EROS did it, and I had no further information about changes to the design (as
> it would be implemented in the Hurd).
> 
> I had no idea why EROS did it like this, and so I didn't make any statements
> about that.

My apologies. The last few days have been stressful for reasons that
have absolutely nothing to do with Hurd or the current discussion.

> > EROS does this because 40 years of experience says that the default has to
> > be opaque or security fails.
> 
> That sounds reasonable.  It also sounds incorrect. :-)

Then I don't think you understand security yet. :-)

Seriously: it is a long-standing principle of secure and robust design
that things should default closed and programmers should have to make
conscious, intentional decisions to open them; never the other way
around.

> > Pragmatics first:
> > 
> > Making the space bank transparent won't really help. The space bank does
> > allocate address spaces. It allocates pages and nodes. In order to get
> > useful information out of that, you would need to know how the pages and
> > nodes are arranged, which is very hard.
> 
> 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 you really want to make constructors transparent, there is a MUCH
> > easier solution: add a new "create" call to the constructor that returns
> > a process capability to the requestor (the process capability names the
> > new yield). This gives the requestor all of the same authority that the
> > process itself has.
> 
> You are assuming that there is a constructor, and you add something to it to
> make it "simpler".  I am removing the constructor (moving part of its
> functionality, creating a new process, into a library) and claim that that
> really makes things simpler.  It removes a step of indirection.  Instead of
> asking a server (the constructor) to create a process, I can just do it
> myself.

This is a VERY bad idea, for reasons that have nothing to do with
encapsulation or transparency.

Creating a process wants to be separately testable, and it wants to work
even if your application screws up completely with a wild pointer error.
It also wants to be a globally replaceable function if there is a bug.
Therefore, it should not be done in a library.

More generally: shared libraries are a *complete disaster* for
robustness. Putting any critical piece of code into a shared library
means that absolutely any other piece of code in your program can cause
that shared library function to break. Shared libraries do not respect
modularity boundaries with names, and there is no way to protect their
data from program errors.

One very important difference between the EROS/KeyKOS philosophy and the
UNIX philosophy:

  EROS: If it possible to do something in a separate process without
  completely destroying performance, do it. If you think that it will
  completely destroy performance, find a way to fix the performance
  problem without putting the function into a library. Only use a
  library when all attempts to deal with the performance issue have
  turned out to be impossible.

  UNIX: If it is possible to do something in the same address space,
  do it.

The UNIX approach gains a (mostly imaginary) performance gain at the
cost of a total loss of robustness. The ability to test things
independently, and to know that the final execution environment
preserves the isolation characteristics of the test environment, is why
KeyKOS had a 25+ year MTBF and UNIX still doesn't after 35 years of
development.

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.

> > Rationale:
> > 
> > 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. 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. If opaqueness is an
option and you leave it out, it is very easy to ship the program to the
field without ever noticing.

> > 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.

> > 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.

> > 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...

> > 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).
POSIX read(2).

> > Policy:
> > 
> > I am very very concerned about the extremist ideology of transparency
> > here. This goes ORDERS OF MAGNITUDE beyond what is required by GPL or
> > FSF.
> 
> Does it?  The only new part is that --x permission cannot be given.  That is,
> x implies r (and r implies x).  I don't think I've ever seen a situation where
> users were not given read-permission to a binary that they could execute, that
> was actually useful.  The only reason I know for its use is to make it harder
> for crackers to find bugs in it.  That is security through obscurity.  It
> doesn't work.

This is such complete nonsense that I don't quite know where to begin to
explain how wrong it is. I will try to respond to this tomorrow, when I
am not up against a critical deadline.

> > GPL does not say "if you run my program, you must disclose all of
> > your data". It does not even say "if you modify my program, you must
> > give away the modifications". It says: if you *redistribute* the
> > modifications *then* you must disclose. It notably does NOT say that if
> > you connect two programs that you run with an IPC pipe then you must
> > disclose.
> 
> 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.

> But for us, "I want to run your code, but you don't need to give it to
> me" is something new.  And we don't see the usefulness of it as
> automatically as you do.

Obviously it is not new to the GPL community, because this question
precisely was a long part of the discussions of GPL3, and the outcome
was MUCH less strict than the outcome that you are contemplating.

> The storage is transparent to the user himself, not to the rest
> of the world.  It is based on the assumption that only users have rights, and
> programs don't.

Actually, I think that this statement is a very good summary of the
essential assumption. I think that this essential assumption is going to
be a problem, and I will try to explain why tomorrow or the next day.