Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack

[Marcus Brinkmann]

At Sat, 6 Jan 2007 21:12:42 +0100,
Pierre THIERRY <address@hidden> wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; us-ascii (quoted-printable)>]
> Scribit Marcus Brinkmann dies 06/01/2007 hora 20:38:
> > Or do you have something else in mind?  What prevents in your idea the
> > browser from simply allocating opaque memory?
> 
> Maybe we don't agree with what can be done with opaque memory. If the
> browser somehow ask some other process opaque memory in order to use it,
> that memory won't be globally opaque. It will only be opaque if you try
> to access it with a capability from the side from where memory came.
> 
> The way I see it, if process A gives opaque memory to process B (the
> rogue browser trying to hide something from me), that memory region will
> become unreadable if I try to see it in A's address space, or in any of
> A's parent address space.
> 
> But to process B, the memory is perfectly readable and writable. If my
> shell spawned A and B, now if it tries to read that memory in it's own
> original space bank, it would fail. If it tries to lurk in A's sub space
> bank, it'll fail also. But if it goes to B's sub space bank and there
> tries to see the memory, it will be able to read and write to it.

Although I find your terminology a bit confusing, you are quite right
about the effect.  If a child process is dominated by the parent, the
parent can make it execute code that reveals the opaque memory, for
example by giving it a capability for the memory pages.  I don't know
what I was thinking, I was very confused.

The whole issue of opaque memory only is relevant if you give a
capability to a non-transparent space bank to a process that you don't
dominate.  Please disregard my browser example, it was bogus.

Thanks,
Marcus