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 10:40:49 -0400
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.
The best way to do what [I think] you want is to map a private
copy-on-write copy of the original range into the original application
over top of itself so that your future modifications would not be seen
by any of the others sharing the (old) range represented by the
mach_make_memory_entry() handle. You can do this with either
vm_protect(VM_PROT_COPY) or vm_remap(). The former is a little more
efficient when all you want to do is get a private copy (with
everything else being the same). The latter is much more flexible in
what can be changed.
--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.