Re: proxy memory objects

[Marcus Brinkmann]

On Tue, Nov 19, 2002 at 09:46:21AM +0100, Marcus Brinkmann wrote:
> "The traditional version is trivial.  You implement a new kind of
>  kernel object, one which you can't actually send any messages to ever.
>  vm_map checks to see if the incoming object is one of these.  The
>  proxy objects are associated in the kernel with a real memory object
>  and a permissions description.  If it is, then you validate the
>  request, and install a normal mapping using the underlying object.
>  Range restrictions are trivially implemented.  Access restrictions are
>  implemented by setting the initial value of the maximum protection on
>  the region; vm_protect can only reduce access to that, never increase
>  it.

So is it correct to just mask off the unallowed protection bit and grant the
mapping silently, making it fail if the actual permissions the server gave
in the proxy memory object are violated?  Or should vm_map already do some
initial permission check and return an error?  I take it that the following
pseudo code is correct:

if is_proxy_object (object)
  {
    prot = get_max_protection (object);
    max_protection &= prot;
    cur_protection &= prot;
  }

and that it should not be like the following

if is_proxy_object (object)
  {
    prot = get_max_protection (object);
    if (cur_protection & ~prot)
      return KERN_PROTECTION_FAILURE
    max_protection &= prot;
  }

or even:

if is_proxy_object (object)
  {
    prot = get_max_protection (object);
    if ((max_protection | cur_protection) & ~prot)
      return KERN_PROTECTION_FAILURE
  }

The reason being that cur and max protection in vm_map specify the
protection of the virtual pages in the task address space, rather than the
actual permissions of the memory object (which are validated with fetching
and unlocking pages), and they are up to the user.  The hack to reduce the
maximum and current protection silently in the user mapping for proxy memory
objects makes it so that the kernel never really tries to unlock pages and
just "assumes that they are not writable by default" (we exploit the fact
here that a user can not see a difference between a failure because of a
failed unlock request and a failure because of mapping protection, unless
the user actually bothers and tries things like calling vm_protect).

The fact that mmap always uses VM_PROT_ALL for the max protection supports
the first version of the code above.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/