I think I didn't make myself clear enough. All my code is in user space. I have one task ("server") that wants to share a part of its address space with another (user-space) task ("client") for a *limited* amount of time. The way I do it right now is as follows: the server allocates the memory for itself. The client sends its task port to the server. Then the server calls mach_make_memory_entry for the memory it allocated, then the server calls vm_map, specifying the client task, in order to map the server's memory into the client's address space. This works fine and indeed the client gets access the server's memory (the server lets the client know where in the client's space it mapped the memory). 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). 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). On Thu, 1 Jul 2004 10:55:23 -0400, Jim Magee <jmagee@apple.com> wrote:
On Jul 1, 2004, at 10:40 AM, Jim Magee wrote:
On Jul 1, 2004, at 1:23 AM, Dan Bernstein wrote:
In case the answer is "don't call mach_make_memory_entry in the first
place", how else can one task grant access to a piece of memory to
another task, so that the first task can later revoke that access?
Currently, I use vm_map, and that seems to require a map entry.
Once access is granted to others, there is no mechanism to revoke it.
This makes sense, since the only mechanism the system would have to
implement a revocation would be to raise a bus error if anyone accessed
the revoked memory (or any copy-on-write of the revoked memory passed
on to other system servers, etc...). So, in effect, revocation could
easily be used to crash the whole system - not something we want in the
hands of a regular application.
I realize I wasn't very clear here. The mach_destroy_memory_entry()
call, even if it was exported, doesn't revoke the memory represented by
the handle. It simply deletes one reference to the handle. You get
the same effect at user-space by calling mach_port_deallocate() on the
handle. But neither has any effect on tasks that have already mapped
the memory represented by the handle. It just deals with the handle
itself.
--Jim
smime.p7s - 2K
_______________________________________________ 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.
participants (1)
-
Dan Bernstein