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, > <olafbuddenha...@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-
