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

[olafBuddenhagen]

Hi Neal,

On Mon, May 18, 2009 at 05:35:00PM +0200, Neal H. Walfield wrote:
> At Mon, 18 May 2009 07:44:54 +0200, > <olafBuddenhagen@gmx.net> wrote:

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

Well, all these possibilities were explored in the original discussion
threads, which are linked from the task description (which I forgot to
mention in the pevious mail):

   http://savannah.gnu.org/task/?1018

Marcus' patch adds an interface that allows for all these possibilities,
but actually implements only a very tiny fraction of them. My changes
just make the fraction a bit larger...

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

Right.

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

I don't think that's what happens. Some remarks in the original
discussions, as well as my reading of the code (well, just a glance
really -- fully understanding it would take me days at least...), seem
to indicate that memory objects do not have any externally visible size
property. The user can map as much as he wants; it's up to the memory
object to supply pages for any particular region or not. It can leave
holes if it wants, and typical objects simply have a large hole at the
end...

A proxy object must ensure that only part of the real object is visible.
The rest of the VM mapping should *not* fail, but rather be replaced by
some mapping that creates a hole... However, really creating such a hole
mapping would be much more tricky, and I'm not sure it's really
necessary. What I did instead is simply not to create any VM mapping for
the denied region at all.

In my reading a client that works properly, should understand the layout
of the object, and never try to access a region that has a hole. (It
would segfault AIUI.) And if a client is broken and tries to access such
an invalid region, does it really matter whether the region is mapped
but faults, or isn't mapped to the expected object at all?

The handling of protection in Marcus' original patch works in a similar
way: It doesn't limit the permissions of the actual object; instead, it
creates a VM mapping with the reduced permissions -- again assuming that
clients won't notice the difference between the two kinds of faults.

The only difference is that with the mapping having reduced permissions,
a client trying to access it in the wrong way will always fault; while
with a reduced size of the mapping, something else might be mapped in a
region that the client (wrongly) assumes to be part of the object -- in
which case the client wouldn't fault, but malfunction in other ways...

I'm not sure I care. Again, I believe it should never happen, unless the
client is broken anyways. It certainly doesn't matter for my use case.

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

Well, the main reason for the split is that I'm less confident about the
length change than the offset one. It also makes a practical difference
to me: the offset patch is necessary for my use case to work at all; the
length is "only" necessary to make it secure... Applying only the first
would still help me.

-antrik-