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: Dan Bernstein <email@hidden>
- Date: Thu, 1 Jul 2004 18:31:57 +0300
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 <email@hidden> 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 | 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.