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.