On Jul 1, 2004, at 11:31 AM, Dan Bernstein wrote:
When the client is not supposed to have access to the server's memory
any longer (and of course after we give it proper notification to the
effect), the server calls vm_deallocate, specifying the client task
and the address in client's space. This indeed prevents further access
by the client to that address (and should it attempt it, the client
would indeed crash with a memory access violation, but of course the
client was notified beforehand and only a malicious client would try
that. Still, I don't see how this comes close to crashing or otherwise
compromising the system. This is not different than the client doing
the same thing with an address which never was part of its address
space).
Now, lets assume that while the client DID have access, it sends some portion of that memory contents to some other server "copy-on-write." Or it makes twelve [shared] copies of it in his own address space. Or it requests some form of long-term IOKit UserClient direct I/O to the memory. You have no control over any of this - regardless of the design of your server.
Anyway, all of the above is exactly as I want it to be: access is
granted and later access is revoked. My only issue is that for the
call to vm_map I need to make that map entry, and while I realize this
is not the memory allocation itself, it is still a resource that
should be disposed of when no longer needed (in fact, I want to
dispose of it right after calling vm_map, I don't need to wait till
after vm_deallocate).
Given the examples I pointed out above, its probably more correct to say that "access is granted and later [you hope] access is revoked." But there are so many ways in which such attempts of revocation can be defeated (both malicious and accidental), you simply can't do it reliably. As I said before, your best bet is to abandon the memory in the server and start anew there - not try to revoke the memory from the client and all the possible copies, shares, etc... he arranged when you weren't looking. To voluntarily dispose of your [named entry] handle to the memory after the vm_map() call, simply call mach_port_deallocate() on it. --Jim [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.