Re: [Patch 0/2] Proxy memory objects revisited

[Neal H. Walfield]

This looks like a fine addition.  One could imagine more complex
schemes, which enable remapping (think scatter/gather type
mechanisms), however, I don't think that this is generally useful.
Further such additional functionality would significantly increase the
complexity whereas your proposal is a very simple addition, which adds
very useful functionality.

At Mon, 18 May 2009 07:44:54 +0200,
<olafBuddenhagen@gmx.net> wrote:
> I'm not entirely sure about the
> "size" one however: It works by mapping only as many pages as the proxy
> object allows, even if the client requested more. This does serve the
> purpose for me (prevent the client from getting access to regions it
> isn't allowed to access); and it is in a way equivalent to what the
> original patch does about prot: It provides a map trimmed to what the
> client is actually allowed. I wonder though whether creating a mapping
> with less pages than the client expected isn't problematic. What do you
> think?

A proxy object narrows a view (and thus access) of the object it
proxies.  If the underlying object consists of 100 pages and the proxy
object is set up to allow the user access to just 10, then a client
should only be able to access those 10.  Moreover, the client should
not be able to distinguish whether a proxy object is a normal memory
object or proxied (i.e., the proxying should be transparent).

Given this, if a client tries to map more pages than are accessible by
a proxy object, it should be equivalent to what happens when a client
tries to map more pages than are accessible by a memory object.  I'd
guess that the kernel would return KERN_INVALID_ARGUMENT but this
needs to be confirmed.


Also, I don't think that there is any need to split the offset and
length patches up.  Really, if one wants one addition, then the other
is likely also needed.

Neal