[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: client-side memory buffers
From: |
olafBuddenhagen |
Subject: |
Re: client-side memory buffers |
Date: |
Wed, 2 Apr 2008 02:47:55 +0200 |
User-agent: |
Mutt/1.5.17+20080114 (2008-01-14) |
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-
- Re: client-side memory buffers, (continued)
- Re: client-side memory buffers, Neal H. Walfield, 2008/04/01
- Re: client-side memory buffers, Joshua Stratton, 2008/04/01
- Re: client-side memory buffers, Neal H. Walfield, 2008/04/02
- Re: client-side memory buffers, Joshua Stratton, 2008/04/02
- Viengoos (was: client-side memory buffers), olafBuddenhagen, 2008/04/05
- Re: client-side memory buffers, Joshua Stratton, 2008/04/03
- Re: client-side memory buffers,
olafBuddenhagen <=