Re: Opencomm: proplib-based syscall

[Elad Efrat <elad%NetBSD.org@localhost>]

Antti Kantee wrote:
> 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's no "ioctl kludge" in it, the ioctl() call in the userland part
has been replaced with __syscall(), and the kernel only uses the ioctl
wrappers for their copyin()/copyout(). Extract these out of proplib, and
you won't see the word "ioctl" anywhere. :)

> >   - 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.

It really depends. The easiest case here is mount, as that's an example
for a program that really comes down to a syscall. Control its arguments
using dictionary internalizing from a file and you can always pass a
file with some XML in it instead of arguments.

> >   - 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.

Using syscall_establish() they're risking taking up a slot that is used
by someone else, no? they also require you to rebuild userland programs
and provide a library interface for the syscall to be useful.

I'd like a vendor to be able to register a "syscall" without all the
associated headache of trying to assign a syscall number (especially now
that we still have syscalls.master), writing a library interface for it,
etc.

> >   - 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.

What I have in mind is more than just that. To give you context, what I
thought about when writing it is how kauth(9) takes parameters, but
these might be structs familiar only to NetBSD. If it took parameters in
proplib-form, it would be much easier to write a policy engine that ran
on a different OS, and would be be too tightly coupled to a certain
NetBSD ABI version.

I think having a syscall that can provide interface to all syscalls,
including the versioned ones, using names (see separate discussion on
the dictionary format) can make automated testing a lot easier here --
to elaborate on the xmlif idea, you can also autogenerate dictionaries
that stress test syscalls using various argument combinations (once
you have a specification that says what type an argument is and an
interface to set values easily into an "argument package", you can
easily write value generators -- but you get the idea I guess. :)

> >   - 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?

Only in testing. I was thinking about the possibility of testing code
paths in the kernel without the need for a "setup" (that has bluetooth,
or an ISO network, or a certain device, or receives a certain packet,
etc.).

> > 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.

Userspace sees this interface:

        int opencomm(prop_dictionary_t in, prop_dictionary_t *out);

and until we agree on what format the dictionaries are in, I'm not sure
what else there's to cover...

> 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. 

Yep, but keep in mind I won't be keeping this on hold until the xmlif
project is ready. :)

> I'm not convinced that just providing
> opencomm buys us anything if we don't do the rest of the work.

Obviously.

-e.