🚀 go-pugleaf

In article <1992Aug14.133748.29123@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes:
>I'm doing a different driver which needs similar functions, but am
>considering using Mach messaging rather than a character special
>device to do what I want.  Now, one thing which I'm trying to
>determine how to implement with the Mach messaging design is how to do
>access control and credentials checking.  With the tradional UNIX
>device driver, I can use suser() to protect access to certain
>protected functions.  How can I determine the identity, in some useful
>sense, of the sender in the Mach messaging case?

The easiest way to do the equiv. of suser() is to pass the host_priv_self()
port around:

For the calls that require super user privileges, add another parameter
to the RPC of type port_t.
In the kernel server, when those calls come in, compare the port_t to
host_priv_self(), the port passed from the client will either map correctly
into the same port # or won't, sorta like a ticket required to do things.
The client side is then required to pass host_priv_self() for those calls
or they'll fail (host_priv_self() requires you to be root).

If you want more granular crendential checking, best is to have the client
send it's own task_self() to the kernel server, then get the pointer
to kernel structures and deference them task->u_address->uu_cred.
I forget how one goes about turning ports into actual kernel structure pointers
but it is/should be possible (can't remember if I ever got it working)

>	* It doesn't seem like it will buy me anything.  I was excited
>	at the prospect of using out-of-line data to move moderately size
>	hunks of data between the kernel driver and user code using
>	the fancy Mach copy-on-write VM.  But it seems that since the
>	loadable kernel servers don't allow this to work, and I have to
>	copy the data anyway.

out-of-line data is only real efficient when your passing page aligned
page sized data, anything else turns into a copy of sorts anyways. If your
data blocks are under half a page size or so, then copy is fine.
But as you say, this is broken in 2.0, there was another poster who
had this problem and said it was fixed in 3.0, but that hasn't materialized
yet.

I personally prefer the Mach interface because you don't have to worry
about your server/handler getting reentered, everything is single threaded
off the queue of messages (unless you add more threads yourself) so
there is less locking/sleep paranoia type things.  I also like the
flexibilty of being able to design whatever kind of interface I see fit, not
tied to read/write/ioctl for ALL purposes.

<shrug> all depends on your needs.

la la la,
-- 
:: Christopher Lloyd :: a74k110@titan.ucc.umass.edu :: Yrrid, Inc. ::

louie@sayshell.umd.edu (Louis A. Mamakos) writes:
>I'm designing a loadable kernel server which needs to communicate with
>user level processes.  

I hope you like a real challenge... I'm also writing a kernel server, and it's
certianly lots of fun and games.

Some of the big suprises I found that weren't mentioned in the "Writing
Loadable Kernel Servers" manual were that (at least in 2.1) only the superuser
can send out-of-line messages to a kernel server%, and that the message-based
interface was _40 times_ slower than ioctl#.

NeXT's documentation in this area leaves a _great deal_ to be desired; the
manual refers you to Egan & Teixeira for Unix-style drivers - but their book
is about System V, not BSD, and of course doesn't mention NeXT's changes or
anything about Mach. I've had to disassemble parts of the kernel numerous
times; the latest real beauty was disassembling selwakeup() to find that it
takes a thread *, not a proc * like it does in other BSD Unix systems. This
one took a real long time and lots of stabs in the dark to find. Quite
logical once you know about it, but it's documented _nowhere_.

And kgdb is next to useless, because you can't depend on the info it gives
you. I used it to single step a simple 'if' condition on an int in an
interrupt routine and it stepped down the _wrong_ path, so I wasted a whole
day until one of the hardware guys here suggested I put a printf on the line
I _knew_ it wasn't getting to. I did so to prove he was wrong and found kgdb
had lied to me. It always prints the values of local variables wrong too;
although it seems to get parameters of a function and info registers right.
We call it the Intel now. NeXT could not possibly have used it without
noticing some ef these problems.

Anyone else want to share their experiences?.

regards,
Graham

%: The kernel server needs access to the kernel task port to vm_write the
   out-of-line data into its (the kernel server's) address space; and the
   only way it can get the kernel task port is if the user process sends it
   in; and the only way the user process can get it is via task_by_unix_pid
   with pid 0; and only the superuser can do that. Fixed in 3.0 though.

#: On my NeXTstation color. Your milage may vary.
-- 
Graham Stoney                    | "a Perl script is correct if it's halfway
Flip Dibner fan club, "Hi Flip!" |  readable and gets the job done before your
Ph: +61 2 805-2909  Fax: -2929   |  boss fires you." L. Wall & R. Schwartz