Hi, I've gotten a basic implementation of server provided ioctl handlers working. In which I unconditionally load a server provided module containing the handlers on every call to ioctl, and then immediately unload the module. I would like to discuss some details of the current implementation.
Currently, attempts to handle a ioctl are done in the following order: * Use server ioctl handler * Look up a glibc ioctl handler * Translate ioctl into an RPC This allows the server ioctl handler to override glibc's ioctl handlers. The question is whether this functionality is useful, it could be potentially confusing if the well established ioctls defined by glibc are overridden. I tend to think that since the ioctl handler is provided by a trusted user, we can trust it to do the sane thing whatever that turns out to be. ;-) The server module provides a single handler, which has essentially the same signature as ioctl() itself, e.g it takes a file descriptor, a request number, and a void pointer as arguments and is expected to return -1 and set errno on error. This is the same as the glibc provided ioctl handlers. While a module can only provide a single handler, it is easy to see that it can forward the call to other handlers if necessary. But I'm going to try to handle it the same as glibc's handlers, so that the handlers also could be used by simply linking it to the application itself. I'm also considering allowing the server to specify several modules containing ioctl handlers. This would be useful if we decide to use code-blessers since in that case it would be impossible for an untrusted user to provide a trusted module that aggregates several trusted handlers. But then again a device that implements ioctls from several device classes are probably very exotic (at least when excluding those already defined by glibc). What do you think? Regards, Fredrik
