At Sat, 6 Jan 2007 21:12:42 +0100, Pierre THIERRY <[EMAIL PROTECTED]> 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
