Re: Part 2: System Structure

[Bas Wijnen]

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.

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

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

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

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

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

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

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

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

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

> 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".  That has been the case forever when going outside the
single-computer situation.  It has been normal forever (as far as I know)
within the single-computer situation as well.  I understand that you consider
EROS "normal", because you've lived with it a lot longer than we have.  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.

> The "no encapsulation" or "transparent storage" policy is fundamentally
> a step that increases the users obligation to disclosure by reducing the
> conditions under which private execution can be accomplished.

Privacy is about what I do with my things.  Not about what you do with my
things.  Transparent storage doesn't invade my privacy, it only doesn't allow
you to let me execute a program on my own resources without seeing it.

> It is based on an assumption that the conditions under which privacy should
> hold should be narrowed greatly, and that users of GPL software should, by
> default, be required to publish their uses.

Not at all.  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.  So a user can choose to have his storage not inspected by
anyone (because he'd have to give it away for that to happen), but a program
cannot (because the user can look at it without permission from the program).

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature