Re: mapping pages into new address spaces

[Joshua Haberman]
> Let's start from scratch and forget what I suggested.  There is
> still what I would consider a small but important gap in the current
> API.  There is no way for a pager to proactively (ie. not in
> response to a page fault) map pages into the address space of one of
> its threads in a way that:

> 1. is not subject to the thread's acceptor

> 2. can complete even if the thread is not waiting for an IPC

> Compare this with unmapping.  A thread can unmap at any time using
> the Unmap system call.  The target threads are not involved.  Why
> shouldn't there be a similar system call for mapping?

There is one major difference between map and unmap.  A mapping is a
transfer of rights to access an object (as well as the information in
the object itself).  Unmapping is revokation of these rights.  For all
non-trivial security policies it is important to be able to control
this flow of rights and information.

Currently, mappings can only be performed during IPC, and by
controlling IPC we can therefore control the flow of rights throughout
the system.

Now, let's for a moment follow your line of thoughts:

Imagine a pager mapping some pages to a client.  The client could be
either 1) running user code, 2) waiting for a reply from the pager, or
3) waiting for a reply from anyone.  Clearly, if you want to go
through with mapping even if the client is not waiting for the IPC,
the only reasonable way is for the IPC from the pager not to modify
the IPC state of the client---any other solution would mean that you
have to potentially handle special cases each time a client receives
an IPC.  So, what you basically get is that you need to implement a
special new IPC operation that pretty much works as a non-IPC map
syscall.

We could of course have this new syscall be subject to the same
security policies as regular IPC operations.  However, what if the
mapping from the pager is redirected to some mediator?  Should the
mediator (redirector) also have the same privileges as the pager of
the client, allowing it to bypass the IPC mechanism altogehter?  And
should the redirector be aware that it has such special rights?

As you can hopefully see, changing the mapping scheme as you suggest
raises a number of questions that previously did not exist.  And once
you try to answer those questions, new questions will pop up.

You say that there is a "small but important gap" in the current API.
While I agree with you on the "small" part I can not agree with it
being important.  No, you can not proactively populate address spaces
without the consent of the client space.  You can, however,
proactively populate spaces if the client has initiated a receive
operation.

> There may be cases where it is important to prevent page faults by
> mapping memory in advance.  Performance is one reason, but there
> could be other scenarios as well.  Imagine that you want a pager to
> manage its own memory space.  It could obtain memory by commanding
> the thread that actually has the memory to map pages.  This pager
> must never fault, because its pager (the dumb program that maps on
> command) doesn't have the page tables.

You seem to be disregarding that in a pager hierarchy there must exist
some sort of contract between the pagers.  As Kevin was saying in
another mail, a pager higher up in the hierarchy might unmap a page
needed further down the line.  This might happen just after a pager
down in the hierarchy has successfully mapped the page, but before the
page was even accessed, effectively rendering the map operation void.
If a pager does not have a guarantee from its own pager that memory
will not be revoked, it must have a means to ensure that memory is
mapped into its address space prior to serving its clients (e.g., by
touching the memory before mapping).

	eSk