On Mon, Aug 29, 2016 at 11:15:48AM +0200, Richard Braun wrote:
> OK, this comes from the fact that io_map directly provides memory
> objects indeed... Do we actually want to pass them around ? How
> come calls like memory_object_init (specifically meant to be used
> between the kernel and the pager) can be made from any client ?
> If we consider Unix as a reference, then the map call uses a file
> descriptor. It's equivalent to a memory object because the translation
> is done privately in the kernel, but we could also change the
> mapping interface to provide some proxy object to the client,
> which could be thought of as an unprivileged memory object.
> The changes involved here are heavy, which is one reason we'd want
> to avoid them.
Note that we already have proxy memory objects is gnumach. (At least the
Debian variant -- don't know whether this ever went upstream.) It
currently only implements restrictions on write access (with Marcus'
original patch), and for offset/size (with my additions); but I suspect
it should be easy to also add restrictions on the management RPCs?
Note though that I never fully understood how the memory object
management protocol works and is used -- so no idea how that would
affect the Hurd as a whole...