Re: Opencomm: proplib-based syscall

[Antti Kantee <pooka%cs.hut.fi@localhost>]

The idea is good.  However ...

On Sun Apr 26 2009 at 03:10:20 +0300, Elad Efrat wrote:
> Hi,
> 
> For a long time I've been thinking about implementing a proplib-based
> syscall -- I call it "opencomm" -- and only now got around to it.
> 
> It's like prop_dictionary_sendrecv_ioctl(), only that:
>    - it doesn't require a file-descriptor/command
>    - it takes a syscall slot

It should be implemented as RPC by read/write on a file descriptor.  By
plugging it into a proplib ioctl kludge you just destroy the generality.

> There are really tons of stuff we can do with it, and I think it opens
> the door to a lot of experimenting (and perhaps even lowers the bar).
> Some uses that come to mind:
> 
>   - We can basically implement any syscall on top of it (with a
>     performance impact, yes)

We can already do that with syscall() ;)

>   - We can offer past and future ABI compatibility (think of
>     internalizing syscall arguments for mount() or whatever, so you
>     don't even have to rebuild the program)

Compatibility reduces to the same problem as with binary interfaces:
you still need to handle both cases, so you don't get any benefit here.
And if your old binary doesn't deliver the info that the new version of
the syscall wants, no amount of proplib can conjure up the missing data.

>   - Subsystems can register themselves with opencomm() instead of
>     adding a new syscall

.. or they can just use syscall_establish().  Otherwise we would divide
syscall provides into two camps.

>   - Data passed to the kernel is not just a "struct" that might be
>     internal to NetBSD, and can be [sent on the wire to and] inspected
>     by other systems

To be useful here, we basically need this:
http://www.netbsd.org/contrib/soc-projects.html#xmlif

Also, this point is a bit orthogonal to opencomm.

>   - We can invoke arbitrary kernel functions, maybe even sequences of
>     them, aggregate results, and return to userspace

My first reaction to this is that it's an extremely bad idea.  Can you
give an example of a case where it is useful and does not create a huge
security crisis?

> I'm sure others can think of much more exotic uses. :)
> 
> The changes required to implement it are very small (copy/paste of
> prop_dictionary_sendrecv_ioctl in prop_kern.c, one line change to
> syscalls.master, and (for now) a stub in kern_xxx.c).
> 
> Are there any objections for it being added?

You didn't discuss the userspace portion at all.

Apart from the above (especially my very strong objection to
implementation using ioctl), what Simon said: proof-of-concept use case
first, please.  So yes, I agree this is something we need, but you need
*much much* more specification before adding it.  Also, based on your
benefits list, I think you are proposing several things of which most
are only slightly related.  More focus would be good.


IMHO what think should happen is that every syscall should offer a binary
interface and a proplib RPC interface (both autogenerated) and then it
would just be business as usual.  I'm not convinced that just providing
opencomm buys us anything if we don't do the rest of the work.