Re: [PATCH 5/7] FUSE: implement ioctl support

[ebiederm@xmission.com (Eric W. Biederman)]

Tejun Heo <tj@kernel.org> writes:

> Eric W. Biederman wrote:
>> I really think that if an ioctl is passing through the kernel we
>> should know how to parse and understand it's options.  Otherwise
>> we won't have the option of doing backwards compatibility when something
>> changes, like we can with the 32->64bit ioctls.
>
> There's no reason 32->64bit can't be handled in userland?  What's the
> difference?

Maintenance.  What happens if I go 128bit, if I have some processes
that are big endian and some that are little endian.  Or if I have
some processes that are running a completely different instruction
set with a completely different ABI than other processes.  Or
perhaps different perhaps the processes is in a different network
namespace than your filesystem and so it's arguments refer
to something different entirely.  Is it a userspace bug if userspace
does not anticipate how the kernel will change in the future?

If we don't look at ioctl as a set of system calls that should
be put into an appropriate format for a filesystem we have
a maintenance problem.

If we don't have an interface clean enough we can push data
out to a server on a remote machine have it processes the
arguments and send the data back.  We actually have failed
to properly abstract the interface.

>> That seems to imply that you need a stub in the kernel to handle 
>> really weird ioctls.
>> 
>> The upside is that because you know what the inputs and outputs are
>> and where the inputs and output are you can support that ioctl well
>> into the future, and you can do it with an unprivileged file
>> system server.
>
> Well, kernel stub kind of beats a lot of benefits of FUSE - no
> specific kernel dependencies, easy development and distribution,
> etc...

Of course FUSE has specific kernel dependencies.  It depends
on the implementation of fusefs in the kernel to talk to it.
The reason you don't need a specific kernel today is that
the kernel dependencies are well defined.  You are talking
about using a very poorly defined interface to talk to the
filesystem.  At which point it would be better to open
a separate channel and talk to the filsystem directly.

Being able to add a kernel system call (ioctl) with no review is a
total maintenance disaster.  It is impossible to maintain because
there is not a process to even discover what is going on.

We have to have a kernel stub to support other system calls
and I don't see why individual ioctls should be different.

If you want to support forwards compatibility reserving
some ioctl numbers and saying these numbers will always
be parsed this way.  Which would allow you to write
a common stub that can be implemented before the ioctls
are implemented.

If you really don't want new kernel dependencies you can hook up to
the process via ptrace and intercept the ioctls before they even get
to the kernel.  If you can open /proc/<pid>/mem you have the rights
to ptrace the process.

Eric