Re: client-side memory buffers

[Joshua Stratton]

The problem you described was the client owning the memory object, sending it to the server, and the server having the ability to unmap the memory because it has ownership, if I understand correctly.  I assumed that a lock was built into the system to prevent this, but I was wondering if this weren't the case, the client could give the ownership to the server before the server does any operations so the client could not unmap the memory object.  The server would then give the ownership back to the client after the operation is complete such that the client couldn't unmap the memory while the server is using it, and in the default state the client would have the responsibility of the memory block (which would help the denial of service inside the network stack).  

Josh

On Tue, Apr 1, 2008 at 9:51 AM, Neal H. Walfield <neal@walfield.org> wrote:

At Tue, 1 Apr 2008 08:11:30 -0600,

Joshua Stratton wrote:
> On Tue, Apr 1, 2008 at 2:28 AM, Neal H. Walfield <neal@walfield.org> wrote:

> > The problem is exactly the same as that with L4's data spaces.  When
> > the server maps and accesses the memory object, the client can revoke
> > the mapping at any time (via memory_object_lock_request), causing the
> > server to fault.  If you manage to unmap the memory while the server
> > is blocked on it (waiting for it to be paged in) and has a lock,
> > you've successfully created a denial of service.
>
>
> Okay, so it's a bad idea, for example, to juggle ownership of the memory
> object so the client cannot unmap while the server is operating on it?

I don't understand your example.

Neal