Message passing

[Bryan Ford]

>   You'll have to be more specific on the exact problems you expect to see.
>   For one thing, you keep referring to the ability to pass messages
>   "atomically", but you haven't defined what "atomic" means.
>
>   In more general terms, maybe you mean that a message transfer can't
>   be interrupted by a page fault - you seem to make the assumption that
>   all message resources must be pinned while they are being transferred.
>[...]
>Actually, I think that having more process states is more pernicious
>than that.  If a process is in mid-transfer, what exactly is it's
>state as seen by a debugger?  If a process is in mid-receive should a
>debugger be able to freeze it?  If so, what state is it then in?  What
>state does that put the sender in?  Should a debugger be able to see
>the intermediate stages of the message transfer if it happens to peek
>at the right moment?

I agree that creating externally visible "mid-message-transfer"
process states should be avoided if at all possible.  But the key
word here is "externally visible": it's OK for processes to be
interrupted in "funny" states, as long as those states aren't
visible to debuggers or to a checkpointing mechanism or whatever.
The direction I'm heading with pres/int IPC (and traditional Mach
IPC already sort of worked this way) is to create sort of a
"schroedinger's cat" situation: a process can be stopped for page
faults (or whatever) at various points during message transfer,
but if some other thread tries to examine or control the thread
performing the transfer, the transfer is aborted and the process
reverts to a well-defined state, restarting again from scratch later.

>   However, the real issue here is accountability: the appropriate
>   user-space process(es) must be "charged" appropriately for any kernel
>   memory that they use, including the kernel memory consumed by that
>   buffer.
>
>I agree with your view here, though in thinking about how to implement
>it I came to two places where I couldn't figure out who ought to be
>charged:
>
>1. The message copy buffer is in some sense owned by both parties; who
>   should be charged?
>
>   My ans.  Doesn't matter; the message buffer is too ephemeral to
>   care very much.

I agree.

>   If a single page pushes you over the limit you're
>   in deeper trouble than that.  In Mach it can be more than one page,
>   though, so it needs real thought.

For this I think we can fall back on a notion of "reasonable" message sizes:
the client and server presumably both know something about the kinds of
messages they pass, and they should both have enough of a kernel memory
"petty cash fund" to cover the kernel's needs during message transfer.
If a message transfer tries to use too much memory, then one side is
not being "reasonable" and so the transfer fails.

>2. COW pages; when I get a COW'd segment, who gets charged for the
>   frames allocated by writes?  It strikes me that the original holder
>   has already been charged for storage in this case.

That problem is just the tip of the iceberg.  A much more serious security
problem with Mach's COW-based message transfer is what happens if you
receive a COW region that was backed by an untrusted pager on the
sender's side - if you try to access it, and the untrusted pager
refuses to supply the "copied" data... BAM! :-)

I think that COW-based message transfer in Mach is currently sufficiently
screwed up as to be unusable in any high-security or strict-accountability
environment, so I recommend steering clear of it for now until we get some
of the more fundamental issues worked out.

				Bryan