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:55:23 -0400
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
[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.