Re: client-side memory buffers

[olafBuddenhagen]

Hi,

On Tue, Apr 01, 2008 at 10:48:02AM -0600, Joshua Stratton wrote:

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

The problem is that the client might unmap the memory while the server
is using it.

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

That's pretty much what Neal described: The buffer is sent between
server and client as out-of-band data in an IPC, meaning the memory is
unmapped from the sender and mapped to the receiver instead.

I don't know though whether the transfer of the mapping happens when
sending the IPC or when receiving it -- but I guess it's the latter,
which means the server is still responsible until the client actually
receives. So no, that wouldn't fix the denial of service.

But I realized now that even if it can be done, client vs. server held
buffers are totally meaningless in the context of the current Hurd/Mach
framework anyways, as the amount of memory a process can allocate is not
limited. It doesn't matter whether the server or the client holds the
excessive mappinging -- in either case, it's the whole system that runs
out of memory...

-antrik-