Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!IDA.ORG!wheeler
From: wheeler@IDA.ORG (David Wheeler)
Newsgroups: comp.os.minix
Subject: User Process Message-Passing in Minix
Message-ID: <1991May22.235824.6939@IDA.ORG>
Date: 22 May 91 23:58:24 GMT
Organization: IDA, Alexandria, VA
Lines: 138


The original version of Minix did not allow _User Processes_
to pass messages to OTHER user processes.


Two questions for the net:

1. Does the current version (or some modified version everyone uses)
allow this? (From all I can tell it doesn't).

2. If not, would someone who has the current version of Minix mind
trying out the following modification to allow it?  Please?
Or tell me a better way to do it?

------------------------------------------

Background:  all of Minix's implementation is based on send, receive,
and send_receive.  UNFORTUNATELY user processes are ONLY allowed to do
send_receive, and to only two OS processes, not to other user processes.
Lots of other OS's _DO_ provide this feature (Mach, System V, QNX, etc),
it's VERY useful.

Last year Mark Boyd posted the following:

mark@ccvr1.ncsu.edu (Mark Boyd):
> I'm trying to use messages for process syncronization.  I can
> find no way to use messages between user processes. Has anyone
> done this? I'm working on 68000 based systems ( ST and PT68k ),
> but I don't see where the problem would be any different on
> PCs. 
>                       Mark Boyd
>                       mark@ccvr1.ncsu.edu
 
I then replied a possible solution.  Has anyone tried this?  Does the
current version already include this?  Would anyone mind trying this
and telling me if things blow up?  I've incorporated a modified
(improved) version of my reply to him below:

-------------------------------------------------------------------

I looked into this problem once.. I think it can be done but haven't
tried it myself.  I'm not aware of this capability being in the latest
version of MINIX, so you'd have to modify the OS.  I don't have the
latest version of MINIX, so my info is based on the original code in
the book. See the MINIX code as published in "Operating Systems:
Design & Implementation", page 473.  Lines 1987-1988 and 1950-1953 mean
that user processes may only execute a sendreceive, and that user
processes may only send to FS or MM.

A quick & dirty solution would be to remove these two sections, then
recompile MINIX.  There may be other sections which make this
assumption, but those two sections are certainly a minimum.  This would
mean, unfortunately, that user programs could send to anybody,
including internal OS processes.

A much better approach would be to make it so that user programs can
only call other user programs OR FS OR MM.  For this, change
kernel/proc.c lines 1950-1953 and 1987-1988 (as numbered in the
original MINIX book) to what follows.  These lines are checks which
currently prohibit user-to-user calls; I replace them with checks that
allow users to either call FS & MM (only send_receive to these) *OR*
call other user processes any way they wish.

Since user processes MUST do a send_receive when they message to FS & MM,
FS & MM don't need to change (since they expect send_receive), and
other user processes can't spoof as FS & MM (since a process sending to
FS & MM will only listen to who it sent to).

Any process sending to another process is automatically trusting the sendee-
if the sendee never receives from ANY, the process stays blocked!
That's normal for this kind of IPC.  You can kill the sender, and Minix
will automatically clean up this queued request, so no harm done.

More interesting is killing a user process to which others are sending
(i.e. a user-level server).  I don't see any code in Minix to handle
this case (ie by restarting those processes waiting to send or receive
from this process), though I may have missed it.  You shouldn't be
killing server-type processes this way anyway; it's much safer to give
server processes a ``kill'' command so they can shut down gracefully.

FS & MM expect to be BOTH sent & received by users, so calling to
FS & MM by users MUST obey that restriction.
(Note: I forgot this check in my last post).
Lines 1950-1953 need to be changed to the following:
----------------------------------------
if (function != BOTH && caller>=LOW_USER &&
           ( src_dest == FS_PROC_NR || src_dest == MM_PROC_NR ) )
    {
     rp->p_reg[RET_REG] = E_NO_PERM; /* Users only do BOTH to MM & FS */
     return;
    }
----------------------------------------


The mini_send routine currently only allows users to send to MM & FS.
You want users to be able to send to MM, FS, or other users.
Calling a process greater than the # of possible processes was checked earlier.
Change lines 1987-1988 to the following:

----------------------------------------

/* Allow users to send to each other as well as MM and FS */
if (caller >= LOW_USER &&
    (dest != FS_PROC_NR && dest != MM_PROC_NR && dest < LOW_USER))
    return(E_BAD_DEST);

/* It is illegal to send to ``any'' - complain if it's attempted! */
/* NOTE: This check is new; my last post didn't check for this error. */
if (dest == ANY) return(E_BAD_DEST);

----------------------------------------


One problem is how to get the process id for the process to send to, since
unlike MM & FS there's no fixed process id for other processes.

In the short run, here's a simple technique:
Have your server (user program) store its process id when it starts up
in a file with an agreed-on filename.  Other programs can read the file
to get its name.  If there's a possibility that programs could try to
read the file while it's being written, have the server create a second
file that indicates ``I'm done writing'', and have all the clients
look for that file first.

A much better solution would be a name server process at a set
process id (as FS and MM are now).  Serving programs could ``register''
themselves with a short name, and clients could request a program by name
and receive its process id.

A better approach would be replacing those sections with something
more sophisticated, so that certain user processes can talk with
certain other processes given certain secure conditions.
Other OS's do allow user processes to send & receive messages and
have some security checks (perhaps the process sets certain permissions
to allow certain other user tasks to send to it, etc, etc).
 
--- David A. Wheeler
    wheeler@ida.org