Re: Why isn't mach_destroy_memory_entry exported?
Re: Why isn't mach_destroy_memory_entry exported?
- Subject: Re: Why isn't mach_destroy_memory_entry exported?
- From: Jim Magee <email@hidden>
- Date: Thu, 1 Jul 2004 12:10:33 -0400
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 | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.