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-
