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 | 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.